Building effective agents

o problema

No fim de 2024 a palavra “agente” já não selecionava nada. Parte do mercado chamava de agente um sistema totalmente autônomo, operando sozinho por períodos longos com um monte de ferramenta; outra parte chamava de agente um fluxo prescrito, com os passos escritos à mão. Como os dois nomes eram o mesmo, as discussões de arquitetura viravam discussão de vocabulário, e a decisão de projeto que importa — quem escolhe o próximo passo, você ou o modelo — ficava implícita.

O segundo problema era de engenharia. A Anthropic diz ter trabalhado com dezenas de times construindo agentes, e o padrão que apareceu foi contraintuitivo: as implementações que deram certo não usavam framework nem biblioteca especializada. Usavam padrões simples e composáveis. Os frameworks resolvem o trabalho chato — chamar o llm, declarar e parsear ferramenta, encadear chamadas —, mas empilham abstração em cima do prompt e da resposta, que é exatamente o que você precisa enxergar quando algo quebra. E, pior, tornam barato adicionar complexidade que não se paga. Suposição errada sobre o que a biblioteca faz por baixo é, segundo o post, fonte comum de erro de cliente.

a ideia

Duas categorias, uma fronteira. Workflow: llms e ferramentas orquestrados por caminhos de código predefinidos. Agente: o llm dirige o próprio processo e decide o uso de ferramentas, mantendo controle sobre como cumpre a tarefa. Ambos são “sistemas agênticos”; a diferença é onde mora a decisão.

Em cima disso vem a regra de método: ache a solução mais simples que funciona e só aumente a complexidade quando ela melhorar o resultado de forma demonstrável. Workflow entrega previsibilidade e consistência em tarefa bem definida. Agente entrega flexibilidade quando a decisão precisa ser do modelo, em escala. E, para muita aplicação, nenhum dos dois: uma chamada única bem otimizada, com retrieval e exemplos in-context, basta.

como funciona

O bloco base é o augmented llm — um modelo com retrieval, ferramentas e memória, capaz de gerar as próprias queries de busca, escolher ferramenta e decidir o que reter. Daí o post sobe a escada de complexidade:

• prompt chaining: a tarefa vira uma sequência fixa de passos, cada chamada consumindo a saída da anterior, com gates programáticos entre elas para conferir se ainda está no trilho. Troca latência por acurácia, porque cada chamada fica mais fácil.
• routing: um classificador (llm ou algoritmo tradicional) manda a entrada para um caminho especializado. Serve quando otimizar o prompt para um tipo de entrada estraga os outros, e permite mandar pergunta fácil para modelo barato e pergunta difícil para modelo caro.
• parallelization: em duas variantes. Sectioning quebra a tarefa em subtarefas independentes — por exemplo, uma instância responde ao usuário enquanto outra faz guardrail, que funciona melhor do que pedir as duas coisas à mesma chamada. Voting roda a mesma tarefa várias vezes com prompts diferentes e agrega, útil para revisão de código em busca de vulnerabilidade.
• orchestrator-workers: um llm central quebra a tarefa dinamicamente, delega e sintetiza. Topologicamente parece paralelização, mas as subtarefas não são predefinidas — só o orquestrador, vendo a entrada, sabe quantos arquivos precisam mudar.
• evaluator-optimizer: um llm gera, outro critica, em loop. Exige critério de avaliação claro e o sinal de que feedback humano articulado melhoraria a resposta.

O agente é o degrau final e, ironicamente, o mais simples de descrever: um llm usando ferramentas com base em feedback do ambiente, em loop.

enquanto não terminou:
    modelo planeja e escolhe uma ação
    executa a ferramenta / roda o código
    ground truth do ambiente volta como observação
    checkpoint opcional: pausa para julgamento humano
    para se concluiu ou se estourou o teto de iterações

O ponto delicado está no ambiente, não no loop: o agente precisa de ground truth a cada passo — resultado de tool call, saída de execução — para saber se progrediu. Por isso o apêndice trata a interface agente-computador (ACI) com o mesmo rigor que se dá a interface humana: descrição de ferramenta com exemplo de uso, edge cases, fronteira clara entre ferramentas, formato próximo do que o modelo já viu na internet, e poka-yoke nos argumentos para tornar o erro difícil.

o que isso custou

O texto é experiência relatada, não medição. Não há tabela, ablação nem número comparando os padrões; a evidência é “dezenas de times” e as implementações internas. Quem quiser saber quanto o routing economiza no seu caso vai ter que medir sozinho — o que, aliás, é a recomendação explícita do post.

Os limites que os autores assumem são concretos. Sistema agêntico troca latência e custo por desempenho, e essa troca nem sempre vale. Autonomia traz custo mais alto e erro que compõe ao longo dos turnos, o que exige teste extensivo em sandbox, guardrails e condição de parada. Agente só serve em ambiente confiável e supõe algum grau de confiança na decisão do modelo. Routing depende de a classificação ser boa; evaluator-optimizer depende de existir critério claro. E, mesmo no melhor caso relatado — o agente que resolve issues do SWE-bench Verified só com a descrição do pull request —, revisão humana continua necessária para garantir alinhamento com os requisitos do sistema maior.

onde isso aparece hoje

O vocabulário pegou: prompt chaining, routing, orchestrator-workers e evaluator-optimizer viraram nomes de prateleira para desenhar sistema com llm. O post também aponta o Model Context Protocol como caminho para plugar ferramentas de terceiros com um cliente simples — e o MCP seguiu como padrão aberto de integração.

A própria página traz a nota que fecha o ciclo: boa parte do cenário de tooling descrito mudou desde dezembro de 2024, e a abordagem atual da Anthropic está documentada nos Managed Agents. O que sobreviveu não foram as ferramentas, foram os três princípios: mantenha o desenho simples, mostre explicitamente os passos de planejamento do agente, e trate a documentação e o teste das ferramentas como parte central do produto.