Agentes de IA na entrega: onde pagam e onde não

"Agente de IA" virou termo guarda-chuva para coisas muito diferentes, e essa imprecisão custa dinheiro. Times montam orquestração complexa para um problema que um fluxo fixo resolveria melhor, mais barato e com menos chance de falhar de madrugada.

Workflow e agente não são a mesma coisa

A distinção que a Anthropic propõe na engenharia de agentes é a mais útil que existe hoje:

• Workflow: o LLM roda dentro de caminhos de código predefinidos. Você decide a sequência; o modelo preenche as etapas.
• Agente: o LLM decide o próprio caminho, escolhe as ferramentas e determina quando terminou.

Workflow é previsível, barato de depurar e fácil de testar. Agente é flexível e caro, em tokens, em latência e em dificuldade de investigar quando dá errado.

A recomendação que acompanha a distinção é direta: use a solução mais simples possível, e só adicione autonomia quando o problema realmente exigir.

Comece pelo workflow, quase sempre

Boa parte das tarefas de entrega de software tem sequência conhecida. Gerar release notes a partir de commits, classificar e rotear um ticket, atualizar changelog, traduzir documentação. Nada disso precisa de um agente decidindo estratégia: precisa de um encadeamento com validação entre as etapas.

A regra prática: se você consegue desenhar o fluxograma antes, é workflow. Se o caminho depende do que for descoberto no meio do caminho, aí sim é candidato a agente.

Os padrões que aparecem de verdade

Quatro se repetem em praticamente todo projeto sério:

1. Encadeamento. Saída de uma chamada vira entrada da próxima, com checagem programática entre elas. A checagem é o que impede o erro de se propagar.
2. Roteamento. Uma chamada barata classifica, e cada classe vai para um prompt ou modelo especializado. Economiza dinheiro e melhora qualidade ao mesmo tempo.
3. Paralelização. Rodar a mesma análise sob ângulos diferentes e agregar, ou dividir trabalho independente. Baixa latência percebida.
4. Avaliador e otimizador. Um gera, outro critica segundo critérios explícitos, itera algumas vezes. Funciona bem quando existe critério objetivo, e vira loop infinito caro quando não existe.

Ferramentas são a parte que decide o resultado

Um agente é tão bom quanto as ferramentas que você dá a ele e quão bem elas estão descritas. Ferramenta mal nomeada, com parâmetro ambíguo ou sem mensagem de erro útil, produz agente que tenta a mesma coisa cinco vezes.

Vale tratar a definição de ferramenta com o mesmo cuidado de uma API pública: nome que diz o que faz, parâmetros com tipo e descrição, erro que explica como corrigir. O Model Context Protocol padroniza exatamente essa camada de conexão entre aplicação, contexto e ferramentas, o que reduz o acoplamento entre o seu agente e um fornecedor específico.

O que os benchmarks dizem sobre a realidade

Vale calibrar expectativa com o SWE-bench, que avalia modelos em issues reais de repositórios reais em vez de exercícios sintéticos. Quando foi publicado, expôs uma distância grande entre desempenho em tarefa de demonstração e desempenho em código de produção com histórico, dependências e contexto implícito.

Os números melhoraram bastante desde então, mas a lição estrutural continua: tarefa bem delimitada e verificável vai bem; tarefa que exige entender a intenção por trás de um sistema inteiro vai mal. Isso deveria guiar onde você aponta o agente primeiro.

Onde agente paga no ciclo de entrega

Os casos com melhor relação entre risco e retorno têm três características em comum: resultado verificável por máquina, escopo limitado e custo baixo de errar.

Migração mecânica repetitiva com testes cobrindo o comportamento. Triagem de falha em CI, correlacionando log e commit. Geração de teste para código legado sem cobertura, com o teste passando como critério objetivo. Investigação de dependência vulnerável, com a proposta de atualização validada pela suíte.

O que não paga hoje: deixar agente abrir PR direto em produção sem revisão, ou mexer sozinho em código central sem cobertura de teste.

O que isso significa para o seu time

Escolha uma tarefa repetitiva, com critério de sucesso verificável por máquina, e implemente como workflow primeiro. Meça tempo economizado e taxa de acerto por duas ou três semanas.

Só promova para agente se o fluxo fixo estiver falhando por não conseguir antecipar os caminhos. E antes disso, invista nas ferramentas e no logging: sem rastro de qual ferramenta foi chamada, com quais argumentos e com qual resultado, você não vai conseguir depurar nem melhorar nada.