Uma leitura anotada, em português, do ensaio Building Effective Agents — o guia de referência da Anthropic sobre quando (e quando não) construir sistemas agentivos com modelos de linguagem.
Ao longo do último ano, a Anthropic trabalhou com dezenas de times construindo agentes de LLM em indústrias distintas. A conclusão que se repete é uma só: as implementações mais bem-sucedidas não usavam frameworks complexos nem bibliotecas especializadas. Usavam padrões simples e componíveis. Esta apresentação reorganiza o texto original em formato de estudo de caso — cobrindo, sem omissões, todos os workflows, o modelo de agent autônomo, os princípios de design e os apêndices sobre aplicações e engenharia de ferramentas.
Siga a ordem do ensaio, ou salte direto para o padrão que interessa.
Nos últimos doze meses, a Anthropic trabalhou com dezenas de times construindo agentes com LLMs em setores distintos. O padrão que se repete é consistente: as implementações mais bem-sucedidas não usavam frameworks complexos nem bibliotecas especializadas. Usavam blocos simples e componíveis.
Este ensaio condensa aprendizados do trabalho com clientes e das construções internas da própria Anthropic, e oferece conselho prático para desenvolvedores que pretendem construir agentes que funcionem em produção.
workflow × agent
A palavra “agent” carrega leituras diferentes. Alguns clientes chamam de agente um sistema totalmente autônomo que opera por períodos longos, usando ferramentas para cumprir tarefas complexas. Outros usam o termo para implementações mais prescritivas, que seguem workflows predefinidos. Na Anthropic, tudo isso é categorizado como sistema agentivo (agentic system), mas existe uma distinção arquitetural importante entre workflows e agents:
Sistemas em que LLMs e ferramentas são orquestrados através de caminhos de código pré-definidos. A lógica de controle é do desenvolvedor; o LLM executa passos programados.
Sistemas em que os LLMs direcionam dinamicamente seus próprios processos e o uso de ferramentas, mantendo controle sobre como as tarefas são cumpridas.
A recomendação da Anthropic ao construir aplicações com LLMs é sempre a mesma: encontre a solução mais simples possível, e só aumente a complexidade quando for necessário. Isso pode significar não construir um sistema agentivo.
Sistemas agentivos costumam trocar latência e custo por performance — e você precisa avaliar quando essa troca faz sentido. Quando mais complexidade se justifica, a escolha é:
Oferecem previsibilidade e consistência para tarefas bem-definidas.
Melhor opção quando precisamos de flexibilidade e decisão guiada pelo modelo em escala.
Existem muitos frameworks que tornam mais fácil implementar sistemas agentivos. A Anthropic cita expressamente quatro:
Esses frameworks facilitam o início: chamar LLMs, definir e parsear ferramentas, encadear chamadas. Mas frequentemente criam camadas extras de abstração que escondem o prompt real e a resposta real, dificultando o debug. Também convidam a adicionar complexidade quando o setup mais simples bastaria.
Comece usando a API do LLM diretamente — muitos padrões podem ser implementados em poucas linhas de código. Se usar framework, garanta que entende o código por baixo. Assunções incorretas sobre o que está por baixo são uma fonte comum de erro dos clientes.
augmented LLM
O bloco básico de qualquer sistema agentivo é um LLM enriquecido com aumentos como retrieval, ferramentas (tools) e memória. Os modelos atuais conseguem usar ativamente essas capacidades: geram suas próprias queries de busca, escolhem ferramentas apropriadas, decidem o que reter de memória.
Pense no LLM aumentado como um cozinheiro numa cozinha equipada: a geladeira cheia (retrieval) pra ir buscar ingrediente quando precisar, o fogão, a panela de pressão e o liquidificador (tools) em cima da bancada, e o celular pra olhar a receita que ele anotou semana passada (memory). Sozinho num quarto vazio, o cozinheiro é só um cara com fome. Com cozinha montada, ele faz o jantar.
A recomendação da Anthropic é focar em dois aspectos-chave da implementação: adaptar essas capacidades ao caso de uso específico e garantir uma interface clara e bem documentada para o LLM. Uma das formas de implementar — e que a própria Anthropic destaca — é o Model Context Protocol (MCP), que permite integrar com um ecossistema crescente de ferramentas de terceiros via um cliente simples.
Daqui em diante, todas as figuras assumem que cada chamada de LLM tem acesso a essas capacidades aumentadas.
Cinco workflows + o agent
Nesta seção, a Anthropic apresenta os padrões comuns que observou em produção. A progressão é deliberada: começa com o bloco fundamental (o augmented LLM), avança por workflows de composição simples, e termina nos agentes autônomos. Cada padrão a seguir recebe, nesta leitura, uma seção dedicada com analogia própria, diagrama e recomendações de uso.
Encadeamento de prompts
O prompt chaining decompõe a tarefa numa sequência de passos: cada chamada de LLM processa a saída da anterior. Você pode adicionar checagens programáticas (os gates do diagrama) em qualquer passo intermediário para garantir que o processo continua no trilho.
Prompt chaining é fazer feijoada: primeiro o feijão demolha, depois a linguiça frita, depois tudo junto apura com o caldo. Cada fase só começa quando a anterior terminou — se misturar tudo de uma vez, vira caldo ruim. E entre uma fase e outra, você prova a colher (o gate): se o feijão não tá macio, não adianta botar a linguiça ainda. Volta o relógio, deixa apurar mais um pouco.
Ideal quando a tarefa pode ser limpa e claramente decomposta em subtarefas fixas. O objetivo principal é trocar latência por acurácia: cada chamada de LLM vira uma tarefa mais fácil.
Se a tarefa não tem decomposição estável, ou se cada passo depende de descobertas feitas no anterior, o chaining vira uma camisa de força. Nesses casos, pense em orchestrator-workers ou agent.
Roteamento
Routing classifica um input e o direciona a uma tarefa-especialista apropriada. Esse workflow permite separação de responsabilidades e a construção de prompts mais especializados — sem ele, otimizar para um tipo de input pode degradar o desempenho em outros.
Routing é a atendente do drive-thru: ela pergunta “vai querer lanche, bebida ou sobremesa?” e, dependendo da resposta, passa o pedido pro caixa certo. Se você diz “quero reclamar do último pedido”, ela chama o gerente, não o cozinheiro. Ninguém tenta fazer tudo — cada pessoa cuida do que sabe, e é essa divisão que faz a fila andar.
Tarefas complexas que têm categorias distintas melhor tratadas separadamente, e quando a classificação pode ser feita com acurácia — seja por um LLM, seja por um classificador tradicional.
Quando as categorias se sobrepõem demais, ou quando uma só resposta genérica basta. Se o classificador erra muito, o roteamento vira gargalo de qualidade.
Sectioning · Voting
LLMs às vezes conseguem trabalhar simultaneamente numa tarefa e ter as saídas agregadas programaticamente. A parallelization aparece em duas variações principais:
Quebrar uma tarefa em subtarefas independentes executadas em paralelo.
Executar a mesma tarefa várias vezes para obter saídas diversas e combinar/votar.
Sectioning é dividir as tarefas de uma festa: um amigo compra a bebida, outro traz o salgado, outro faz a playlist. Em paralelo, a festa fica pronta em uma hora em vez de quatro. Voting é perguntar pra três amigos se o restaurante é bom antes de ir: se os três concordam, você vai tranquilo; se discordam, você pensa melhor. Duas formas diferentes de usar o paralelismo: uma soma perspectivas, a outra reduz o risco de cair numa furada.
Quando as subtarefas podem ser paralelizadas por velocidade, ou quando várias perspectivas/tentativas aumentam a confiança do resultado. Em tarefas complexas com múltiplos aspectos, LLMs geralmente performam melhor quando cada aspecto é tratado por uma chamada própria, com atenção focada.
Quando as subtarefas têm dependência sequencial (o passo 2 precisa do passo 1), ou quando o custo de múltiplas chamadas supera o ganho de velocidade/confiança.
Orquestrador com trabalhadores
No orchestrator-workers, um LLM central (orchestrator) decompõe tarefas dinamicamente, delega aos LLMs worker, e sintetiza os resultados.
Orchestrator-workers é o chefe do caminhão de mudança parado na porta do apartamento. Ele olha o que tem pra carregar e decide na hora: “você pega o sofá, você as caixas leves, você ajuda com a geladeira”. Ele não sabia antes quem ia pegar o quê — depende do que apareceu, de quem está mais forte, de quem chegou primeiro. No fim, é ele quem confere se tudo cabe e fecha a porta.
Tarefas complexas em que não dá para prever as subtarefas necessárias. Em coding, por exemplo, o número de arquivos a alterar e a natureza de cada alteração dependem da tarefa. A diferença crítica em relação à parallelization é a flexibilidade: subtarefas não são pré-definidas — são determinadas pelo orchestrator com base no input específico.
Quando a decomposição é estável e previsível — use parallelization ou prompt chaining, mais simples e baratos.
Avaliador + refinador
No evaluator-optimizer, uma chamada de LLM gera a resposta enquanto outra oferece avaliação e feedback — em loop.
Evaluator-optimizer é a redação da escola com professor corrigindo. Você entrega um rascunho (optimizer). O professor (evaluator) marca em vermelho onde travou a frase, onde faltou argumento, onde fugiu do tema — e devolve pra reescrever. Você arruma, entrega de novo, ele relê. Roda até o texto ficar redondo. Parece redundante, mas é o que separa rascunho de redação nota mil.
Particularmente eficaz quando temos critérios de avaliação claros e quando refinamento iterativo produz valor mensurável. Dois sinais de bom ajuste: (1) as respostas do LLM melhoram demonstravelmente quando um humano articula o feedback, e (2) o próprio LLM é capaz de fornecer tal feedback. É análogo ao processo iterativo de escrita que um autor humano faz para produzir um documento polido.
Quando não há critério de avaliação claro, ou quando a primeira tentativa normalmente já é boa o suficiente — o loop só acrescenta custo e latência.
autonomous agent
Agentes estão emergindo em produção à medida que os LLMs amadurecem em capacidades-chave: entender inputs complexos, raciocinar e planejar, usar ferramentas de forma confiável e recuperar-se de erros. Um agente começa com um comando (ou uma conversa interativa) com o usuário humano. Uma vez que a tarefa está clara, ele planeja e opera de forma independente, potencialmente retornando ao humano para mais informação ou julgamento.
Durante a execução, é crucial o agente obter ground truth do ambiente a cada passo — resultados de tool call, saídas de execução de código — para avaliar progresso. O agente pode pausar para feedback humano em checkpoints ou quando encontra bloqueios. A tarefa normalmente termina ao ser concluída, mas é comum incluir condições de parada (como número máximo de iterações) para manter controle.
Um agente é um motoboy de aplicativo com rota livre. Você pede a entrega e pronto — ele escolhe o caminho, desvia de trânsito, sobe ladeira diferente, entra numa rua que você nem conhece. Só manda mensagem (humano no loop) quando o interfone não responde ou quando bate num portão trancado. No fim, ou chega com a encomenda, ou volta avisando por que não deu.
Agentes podem lidar com tarefas sofisticadas, mas sua implementação costuma ser bem direta: tipicamente são só LLMs usando ferramentas com base em feedback do ambiente, num loop. Por isso é crucial desenhar conjuntos de ferramentas e suas documentações com clareza e cuidado (tema expandido no Apêndice 2).
Problemas abertos (open-ended), em que é difícil ou impossível prever o número de passos necessários, e em que não dá para hardcodar um caminho fixo. O LLM potencialmente opera por muitas turns, e é preciso haver algum nível de confiança na sua tomada de decisão. A autonomia dos agentes os torna ideais para escalar tarefas em ambientes confiáveis.
A natureza autônoma dos agentes implica custos maiores e potencial de erros compostos. Recomenda-se teste extenso em ambientes sandboxados e guardrails apropriados. Em ambientes que não admitem guardrails ou sandbox, prefira um workflow determinístico.
Os blocos acima não são prescritivos. São padrões comuns que os desenvolvedores podem moldar e combinar para caber em casos de uso diferentes. A chave do sucesso, como em qualquer feature que use LLMs, é medir performance e iterar nas implementações.
Sucesso no espaço de LLMs não é construir o sistema mais sofisticado. É construir o sistema certo para a necessidade. Comece com prompts simples, otimize com avaliação abrangente, e adicione sistemas agentivos multi-step só quando soluções mais simples falharem.
Ao implementar agentes, a Anthropic tenta seguir três princípios centrais:
Prefira sempre o menor conjunto de componentes que resolve o problema. Adicione camadas apenas quando a métrica obriga.
Mostre explicitamente os passos de planejamento do agente. Um agente opaco é um agente que você não consegue depurar nem confiar.
Elabore com cuidado a ACI — documentação e testes das ferramentas. A mesma atenção que se dá a HCI deve ir para ACI.
Frameworks ajudam a começar rápido, mas não hesite em reduzir camadas de abstração e construir com componentes básicos quando for para produção. Seguindo esses princípios, você cria agentes não apenas poderosos, mas também confiáveis, manuteníveis e dignos da confiança dos seus usuários.
Onde agentes agregam mais valor
O trabalho com clientes revelou duas aplicações particularmente promissoras para agentes de IA, que demonstram o valor prático dos padrões discutidos acima. Ambas ilustram como agentes agregam mais valor em tarefas que exigem conversa e ação simultaneamente, têm critérios claros de sucesso, permitem loops de feedback, e integram supervisão humana significativa.
O suporte a cliente combina interface de chatbot já conhecida com capacidades aumentadas via integração com ferramentas. É um encaixe natural para agentes mais abertos porque:
Várias empresas já demonstraram a viabilidade com modelos de cobrança por resolução bem-sucedida — mostrando confiança na efetividade dos seus agentes.
Desenvolvimento de software mostrou potencial notável, evoluindo de code completion para resolução autônoma de problemas. Agentes são particularmente eficazes porque:
Na implementação da própria Anthropic, agentes resolvem issues reais do SWE-bench Verified apenas a partir da descrição do pull request. Mesmo assim, a revisão humana continua crucial para garantir que a solução se alinha aos requisitos mais amplos do sistema.
ACI — Agent-Computer Interface
Independentemente do tipo de sistema agentivo que você está construindo, ferramentas provavelmente serão parte importante do seu agente. Tools permitem ao Claude interagir com serviços e APIs externas, especificando sua estrutura exata na API. Quando Claude responde, ele inclui um tool use block na resposta se planeja invocar uma ferramenta. Definições e especificações de ferramentas merecem tanta atenção de prompt engineering quanto seus prompts principais.
Há frequentemente várias formas de especificar a mesma ação. Você pode especificar uma edição de arquivo escrevendo um diff, ou reescrevendo o arquivo inteiro. Para output estruturado, você pode retornar código dentro de markdown ou dentro de JSON. Em engenharia de software essas diferenças são cosméticas e convertíveis entre si sem perda. Mas alguns formatos são muito mais difíceis de um LLM escrever que outros. Escrever um diff requer saber quantas linhas estão mudando no cabeçalho do chunk antes do novo código ser escrito. Escrever código dentro de JSON (em vez de markdown) exige escape extra de newlines e aspas.
Desenhar tools é como desenhar uma tomada de três pinos. A forma do plugue já impede de encaixar invertido — não tem como ligar errado, porque os pinos não cabem do outro jeito. Ferramenta boa pro agente é assim: em vez de escrever “atenção, não faça X”, a interface não deixa X acontecer. Se o caminho precisa ser absoluto, a tool recusa caminho relativo; o agente nem chega a errar.
Dê ao modelo tokens suficientes para “pensar” antes que ele se escreva num canto.
Mantenha o formato próximo ao que o modelo viu ocorrer naturalmente em texto na internet.
Sem overhead de formatação: não obrigue a manter contagem precisa de milhares de linhas, nem a escapar strings de código escrito.
Uma regra de bolso: pense em quanto esforço vai para interfaces humano-computador (HCI), e planeje investir a mesma quantidade de esforço criando boas interfaces agente-computador (ACI). Algumas formas de fazer isso:
// Antes — tool com path relativo, modelo errava após cd:
read_file({ path: "src/utils.ts" })
// Depois — tool exige path absoluto, uso impecável:
read_file({ path: "/repo/src/utils.ts" })
O que levar deste caderno
O ensaio não oferece uma receita única. Oferece um vocabulário comum e uma disciplina. Os takeaways seguintes derivam estritamente do texto original — são a destilação que este caderno oferece ao engenheiro sênior que vai voltar ao código amanhã.
Comece com um LLM aumentado. Só acrescente um workflow quando mover uma métrica. Só suba para agent quando o workflow travar.
Caminho previsível e estável? Workflow. Caminho imprevisível, com muitos passos e sem forma fechada? Agent — com sandbox e guardrails.
Prompt chaining, routing, parallelization (sectioning/voting), orchestrator-workers, evaluator-optimizer. Combine-os — não invente novos.
Prefira API direta em produção. Se usar framework, abra o capô. Abstrações escondem prompts; prompts escondidos escondem bugs.
Mostre planos, ferramentas invocadas, observações. O usuário só confia no que consegue ver; o engenheiro só depura o que o sistema deixa aparecer.
Ferramentas mal descritas produzem agentes que parecem burros. Ferramentas poka-yoke, com paths absolutos, exemplos e fronteiras claras, produzem agentes impecáveis.