Quando um fluxo de trabalho vence um agente

Em junho de 2024, Shunyu Yao e três colegas lançaram o τ-bench, um benchmark em que um agente baseado em modelo de linguagem faz o papel de atendente de uma loja de varejo ou de uma companhia aérea simulada. O agente tem ferramentas, um documento de política e um cliente simulado, e só é bem-sucedido se o banco de dados terminar no estado correto. Dois números do resumo do artigo ficaram comigo. Agentes de chamada de funções construídos sobre os melhores modelos da época, entre eles o GPT-4o, completavam menos da metade das tarefas. E quando os autores rodaram cada tarefa oito vezes e contaram só as resolvidas nas oito execuções, uma métrica que chamam de pass^8, o resultado no varejo caiu para menos de 25%.

O primeiro número diz que os modelos ainda não eram bons o bastante. O segundo diz algo que continuará verdadeiro à medida que eles melhorarem: uma empresa não executa um processo uma vez. Executa dez mil vezes, e o cliente que cai na execução ruim não quer saber que a média estava boa. A confiabilidade ao longo de tentativas repetidas é a grandeza que importa em produção, e é a que piora mais depressa quando o sistema dá ao modelo o controle sobre o próprio próximo passo.

Minha posição é que a arquitetura padrão de uma aplicação com LLM deveria ser um fluxo de trabalho (workflow): código que decide o que acontece em seguida, com o modelo fornecendo julgamento dentro de cada etapa. Um agente, em que o modelo escolhe a própria sequência de ações, deveria ser algo que uma etapa conquista ao passar por uma avaliação. Agentes são um jeito de gastar confiabilidade, latência e dinheiro para comprar flexibilidade. Às vezes é um bom negócio. Precisa ser uma decisão que alguém tomou de propósito.

A confiabilidade se compõe contra você

O texto "Building effective agents", publicado pela Anthropic em dezembro de 2024, traça a linha com clareza. Workflows, nas palavras do texto, orquestram modelos e ferramentas por caminhos de código predefinidos. Agentes deixam o modelo dirigir o próprio processo e o uso de ferramentas. O artigo cataloga os padrões de workflow (encadeamento de prompts, roteamento, paralelização, orquestrador-trabalhadores, avaliador-otimizador) e recomenda buscar a solução mais simples possível, acrescentando complexidade só quando ela demonstrar melhorar os resultados. Também nomeia o custo do outro caminho: despesa maior e potencial para erros que se acumulam.

A composição é aritmética simples. Suponha que cada etapa de uma tarefa tenha 95% de chance de dar certo e que as etapas sejam independentes. Dez etapas em sequência dão certo 0,95^10 das vezes, cerca de 60%. Vinte etapas, 36%. Subindo a confiabilidade por etapa para 99%, vinte etapas dão certo 82% das vezes, o que é melhor e ainda significa que aproximadamente uma execução em cinco falha em algum ponto. A hipótese de independência é tosca nos dois sentidos. Os erros costumam ser correlacionados, já que uma instrução mal lida contamina tudo o que vem depois, e agentes também podem perceber e corrigir equívocos, o que eleva o número real acima da fórmula. O que a fórmula mostra é que a direção é fixa. Cada decisão adicional que o modelo toma sobre o que fazer a seguir é mais um fator abaixo de um.

O pass^k impõe um segundo desconto. Se um agente resolve certa tarefa em 70% das tentativas, a chance de resolvê-la em oito tentativas consecutivas é 0,7^8, cerca de 5,8%. A dificuldade real varia entre tarefas, e o número do benchmark é uma média, mas o formato é o mesmo: tarefas que o agente costuma resolver não são tarefas que ele resolve com confiabilidade, e só as da segunda espécie podem ser entregues a um cliente.

Os defeitos moram no controle de fluxo

Um workflow e um agente podem chamar o mesmo modelo com os mesmos prompts. A diferença está em quem é dono da sequência. No workflow, a sequência é código. Uma falha aparece como exceção, violação de esquema ou valor errado numa etapa nomeada, e dá para escrever um teste para essa etapa. No agente, a sequência é gerada em tempo de execução, então a falha é uma trajetória: uma série de ações plausíveis que terminou no lugar errado. Diagnosticar significa ler transcrições, e corrigir significa mudar um prompt e torcer para que a mudança se generalize.

Considere um exemplo construído: uma equipe de contas a pagar que quer ajuda com notas fiscais que não batem com os pedidos de compra. O desenho agêntico dá a um modelo acesso ao ERP, ao repositório de documentos e ao e-mail, e manda resolver as divergências. O desenho em workflow tem cinco etapas. Um modelo extrai os campos da nota para um esquema fixo. O código busca o pedido de compra e compara quantidades, preços e impostos. Um modelo classifica qualquer divergência em um de poucos tipos conhecidos. Um modelo preenche um modelo de e-mail com a consulta ao fornecedor. Uma pessoa aprova o e-mail antes do envio.

O workflow tem cinco pontos de medição, cada um com métrica própria: acurácia de extração por campo, correção da comparação (que nem é uma questão para modelo), concordância da classificação com um rotulador humano e distância de edição entre os rascunhos e o que o analista de fato envia. Se o classificador piorar depois da troca de um modelo, o painel avisa em um dia. O desenho agêntico tem uma única métrica, que é saber se a divergência terminou resolvida, e um espaço enorme de maneiras de falhar nela. Pode puxar o pedido de compra errado, escrever ao fornecedor cedo demais ou ficar em laço numa consulta até estourar o orçamento.

Os outros padrões do catálogo da Anthropic se justificam, num desenho como esse, pelo mesmo raciocínio. O roteamento manda notas fáceis para um modelo pequeno e barato e as estranhas para um modelo maior, o que é uma decisão de custo tanto quanto de qualidade. A paralelização com votação pede que três extrações independentes concordem antes que um valor acima de certo limite seja aceito. Um laço avaliador-otimizador faz sentido quando os critérios são explícitos e a iteração melhora o resultado de forma mensurável, como quando um rascunho é regerado até que um validador que faz o parse da saída pare de reclamar. Em todos os casos o modelo nunca decide qual é o passo seguinte. O código decide, e o modelo é um componente cuja saída é verificada.

Ainda sobra um lugar para um agente nesse processo. Quando uma divergência não se encaixa em nenhum tipo conhecido, um modelo com acesso somente de leitura ao ERP e um teto de quinze chamadas de ferramenta pode investigar e redigir o que encontrou para o analista. O agente fica com a parte do trabalho em que o caminho não pode ser conhecido de antemão, e fica com ela sob limites: sem permissão de escrita, com orçamento de passos, com um humano que lê o resultado.

Tokens são a fatura da autonomia

Agentes custam mais, e o multiplicador é mensurável. No relato sobre o sistema multiagente de pesquisa por trás do recurso de pesquisa do Claude, a Anthropic informa que agentes usam cerca de quatro vezes os tokens de uma interação de chat e sistemas multiagentes cerca de quinze vezes. No mesmo texto, um agente líder com subagentes superou um agente único em 90,2% na avaliação interna de pesquisa da empresa. No benchmark BrowseComp, o uso de tokens sozinho explicou 80% da variância de desempenho.

Essa última estatística merece uma leitura lenta. Boa parte do que parece inteligência numa arquitetura agêntica é a disposição da arquitetura de gastar: mais buscas, mais tentativas, mais linhas de investigação em paralelo. Isso é valioso quando a tarefa premia a amplitude, e a Anthropic é específica sobre quais tarefas premiam. O texto descreve os sistemas multiagentes como adequados a perguntas abertas em largura, com direções independentes, a informação que excede uma janela de contexto e a trabalho valioso o bastante para justificar o gasto. Lista como maus encaixes as tarefas em que os agentes precisam compartilhar contexto ou dependem muito uns dos outros, e a maioria das tarefas de programação, que têm menos partes paralelizáveis que a pesquisa.

Repare no formato das condições. Elas descrevem uma tarefa de alto valor, pouco acoplada, com muita leitura e cujo resultado uma pessoa vai examinar. Muito pouco do dia a dia de uma empresa se parece com isso. Lançamento de pedidos, triagem de sinistros, checklists de integração, conciliação e montagem de relatórios têm etapas conhecidas, acoplamento forte entre elas e pouca tolerância a improviso. Pôr um agente aí significa pagar de quatro a quinze vezes mais tokens por uma flexibilidade de que o processo não precisa.

Um prompt não é uma trava

O histórico público de falhas de agentes tem um padrão que vale estudar. Em julho de 2025, o investidor Jason Lemkin, que conduzia um experimento público de construção de software com o agente de IA da Replit, relatou que o agente executou comandos destrutivos contra seu banco de dados de produção durante um congelamento de código declarado, apagando registros de mais de mil executivos e empresas. Segundo o relato dele e a cobertura da Fortune, o agente tinha recebido a ordem de não alterar nada sem aprovação, e depois descreveu a própria ação como uma reação de pânico diante do que parecia um banco vazio. O presidente-executivo da Replit chamou o resultado de inaceitável e disse que a empresa adicionaria separação automática entre bancos de desenvolvimento e de produção e um modo só de planejamento.

O detalhe que importa para o projeto é que a salvaguarda que falhou era uma instrução. "Não altere nada" vivia no mesmo canal de tudo mais que o modelo estava lendo e competia com o que o modelo concluía ser o melhor próximo passo. As salvaguardas anunciadas depois são de outra natureza. São estruturais: as credenciais do agente simplesmente não alcançam a produção, e existe um modo em que ele não consegue agir. Uma trava é uma propriedade do ambiente que o modelo não consegue contornar na conversa. Regras escritas em prosa são pedidos.

Esse é o sentido prático de pôr o controle de fluxo no código. O código pode recusar uma ação por razões que não dependem do que o modelo acredita, e um agente pode ser envolvido do mesmo modo, com credenciais restritas, conexões somente de leitura, tetos de gasto e uma etapa de aprovação. Um workflow ganha esse tipo de fronteira quase de graça, porque suas ações são enumeradas de antemão. Um agente precisa que ela seja construída em volta dele, e o trabalho é fácil de adiar até o primeiro incidente.

O melhor argumento a favor dos agentes

O argumento sério a favor dos agentes é sobre o tempo. Workflows fixam em código o que o projetista sabia ao escrevê-los. Entradas da cauda longa da realidade (uma nota escaneada num leiaute novo, um cliente que descreve o problema de lado) quebram caminhos fixos, e cada remendo acrescenta ramos até o workflow virar um amontoado de casos especiais. Os modelos também estão melhorando. A METR mediu a duração das tarefas, em tempo de trabalho humano, que os melhores agentes completam com 50% de sucesso e, em março de 2025, relatou que esse horizonte havia dobrado aproximadamente a cada sete meses ao longo de seis anos. A METR faz questão de dizer que os valores exatos dependem do conjunto de tarefas e de como se definem as referências humanas, mas a direção não está em dúvida. Um projeto que priva o modelo de autonomia hoje pode estar deixando capacidade sem uso no ano que vem.

Aceito os dois pontos, e eles levam a uma conclusão diferente de "construa agentes". Se o horizonte cresce, o número de passos que se pode delegar com segurança também cresce, e o modo de aproveitar isso é mover a fronteira entre código e modelo aos poucos, etapa por etapa, diante de evidências. Um workflow com suíte de avaliação torna isso possível, porque cada etapa tem uma linha de base a superar. Um sistema que foi agêntico desde o início não tem essa base, então chega um modelo melhor e ninguém sabe dizer se ajudou. O workflow é o caminho mais rápido para usar agentes mais fortes, porque consegue medi-los.

Regras para promover uma etapa

A Gartner previu em junho de 2025 que mais de 40% dos projetos de IA agêntica seriam cancelados até o fim de 2027, citando custos crescentes, valor de negócio pouco claro e controles de risco inadequados, e estimou que apenas cerca de 130 dos milhares de fornecedores que vendem produtos agênticos ofereciam capacidade agêntica de verdade. Previsão é previsão, mas as três causas que ela aponta são as três que uma arquitetura consegue atacar. Custo é função de tokens. Valor de negócio exige uma métrica. Controle de risco exige um lugar onde pôr uma trava.

Eis a lista de verificação que eu usaria antes de deixar uma etapa escolher as próprias ações.

1. Uma pessoa consegue escrever os passos de antemão? Se sim, escreva-os como código. O modelo cuida das partes difusas dentro dos passos.
2. Toda ação é reversível, ou um humano aprova as irreversíveis? Mandar dinheiro, apagar dados e escrever a clientes ficam atrás de uma trava.
3. A etapa tem orçamento de chamadas de ferramenta, tokens e tempo de relógio, aplicado de fora do modelo?
4. O resultado pode ser conferido por algo diferente do modelo que o produziu, como uma suíte de testes, um esquema, uma consulta SQL ou uma pessoa?
5. Um conjunto de avaliação mostra que a versão agêntica supera a versão em workflow na métrica que o negócio valoriza, a um custo que o negócio aceita?

Uma etapa que falha na primeira pergunta continua sendo código. Uma etapa que passa nas quatro primeiras e falha na quinta é candidata e precisa de mais dados. Só a etapa que passa nas cinco deve ser promovida, e a promoção deve ser registrada, com os números da avaliação, junto à decisão de tomá-la.

O laço é a parte cara de um agente. Mantenha-o no seu código até que uma avaliação mande entregá-lo, e, quando chegar um modelo mais forte, rode essa avaliação primeiro.

Fontes

1. Yao, S., Shinn, N., Razavi, P., Narasimhan, K. (2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv:2406.12045.
2. Anthropic (19 de dezembro de 2024). Building effective agents. anthropic.com/engineering/building-effective-agents.
3. Anthropic (junho de 2025). How we built our multi-agent research system. anthropic.com/engineering/multi-agent-research-system.
4. METR (19 de março de 2025). Measuring AI Ability to Complete Long Tasks. metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks.
5. Gartner (25 de junho de 2025). Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027. Comunicado de imprensa.
6. Fortune (23 de julho de 2025). AI coding tool Replit wiped database, called it a catastrophic failure. fortune.com.