O Agente Que Eu Construí e Não Precisava

Eu gastei duas semanas construindo um agente autônomo para classificar e rotear tickets de suporte. O LLM decidia em cada etapa: qual categoria, qual equipe, qual prioridade, qual template de resposta. Era sofisticado. Era elegante. E era completamente desnecessário.

Sabe o que funcionava melhor? Três chamadas de LLM dentro de um pipeline de código tradicional: uma para classificar, uma para extrair dados, uma para gerar a resposta. Tudo conectado por if/else. Sem loop de decisão. Sem “autonomia”. Sem surpresas.

O resultado: 3x mais rápido, 5x mais barato, e zero comportamentos inesperados. O agente era mais impressionante. O workflow era mais útil.

Essa experiência me ensinou a lição que a Anthropic publicou em seu guia oficial de agentes e que em 2026 se tornou consenso entre engenheiros seniores: não construa agentes quando bastam workflows.

A Diferença Que Parece Sutil (E Não É)

A diferença fundamental entre workflow e agente é quem decide o próximo passo.

Workflow: passos pré-definidos. Você, o desenvolvedor, dita as regras e o caminho que a informação deve seguir. A IA pode ser usada dentro dos passos (classificar texto, gerar resposta, extrair dados), mas ela não decide o fluxo. Ticket chega → IA classifica → sistema roteia para equipe certa. Cada etapa foi programada por você. Previsível. Auditável. Barato.

Agente: decisões dinâmicas. Você dá ferramentas ao modelo e ele decide, a cada curva, o que fazer a seguir. O LLM recebe o problema, decide puxar dados da conta, analisa o histórico, decide se emite reembolso ou escalona para humano. O modelo escolhe o caminho em tempo real.

A Lyzr (plataforma de orquestração de agentes usada por Accenture, JPMorgan Chase, PepsiCo) resume a evolução: “Em 2024-2025, a conversa enterprise era sobre agentes — o que podem fazer, como construí-los, qual framework usar. Em 2026, a conversa mudou para orquestração.” Não é sobre o agente individual. É sobre como múltiplos componentes — alguns agentes, muitos workflows — trabalham juntos.

O Maior Erro dos Engenheiros

O erro mais comum que eu vejo (e cometi): pular direto para agentes complexos porque são a palavra da moda.

A pressão é real. Todo keynote é sobre “agentes autônomos”. Todo benchmark mede performance agêntica. Todo investidor pergunta “vocês têm agentes?”. E o resultado: equipes gastam meses construindo agentes sofisticados para tarefas que um pipeline de 50 linhas de Python resolveria.

A realidade é que a maioria das soluções lançadas como “agentes” são, na verdade, workflows fantasiados. Forçar um LLM a tomar decisões estruturadas que poderiam ser resolvidas com if/else é uma falha de engenharia que torna a aplicação inconsistente, lenta e desnecessariamente cara.

A Gartner prevê que 40%+ dos projetos agênticos serão abandonados até 2027 — não por qualidade de modelo, mas por custos escalantes, valor de negócio incerto e controles de risco inadequados. Muitos desses projetos simplesmente não deveriam ter sido agentes.

A DevTools Academy é direta: plataformas de orquestração “não magicamente tornam agentes mais capazes. Dão às equipes uma forma de rodá-los com menos pontas soltas.” A magia não está no agente. Está na infraestrutura ao redor dele — e frequentemente, essa infraestrutura é um workflow.

Quando Você Realmente Precisa de um Agente

A regra de ouro: previsibilidade. Você só deve adotar uma arquitetura de agente quando for genuinamente impossível prever os próximos passos de forma antecipada.

O exemplo perfeito é um agente de pesquisa web: ele busca no Google, lê o conteúdo de uma página, e baseado no que encontrou (algo que você não tinha como prever), decide qual deve ser o próximo termo de pesquisa. Cada passo depende do resultado do anterior de formas imprevisíveis. Aí o agente brilha.

Outros casos legítimos para agentes: navegação autônoma em ambientes desconhecidos (robótica), negociação multi-step com partes externas (onde a resposta do outro lado é imprevisível), exploração de dados onde o objetivo é vago (“me diga algo interessante sobre este dataset”), e resolução de problemas abertos de codificação (onde o agente precisa testar, falhar e iterar).

Se o seu sistema não exige essa flexibilidade caótica, fique com o workflow.

Os 5 Padrões de Orquestração Reais de 2026

A Lyzr catalogou os padrões que as empresas realmente usam em produção (não os que aparecem em papers):

1. Sequencial (Pipeline). Agente A completa, passa para B, que passa para C. Linear, previsível, determinístico. O padrão mais simples. Para pipelines de documentos, aprovações multi-step, enriquecimento de dados. É basicamente um workflow com chamadas de LLM.

2. Hierárquico. Um agente coordenador delega para agentes especializados. O coordenador decide quem faz o quê, mas os agentes especializados executam tarefas definidas. Escalável — pode gerenciar centenas de agentes organizados em “departamentos”.

3. Paralelo (Fan-out/Fan-in). Múltiplos agentes especializados processam em paralelo, e um agregador combina os resultados. Para tarefas que podem ser decompostas e executadas independentemente.

4. Deliberação. Agentes debatem iterativamente até convergir. Para decisões complexas que se beneficiam de perspectivas múltiplas.

5. Federado. Sistemas independentes de diferentes organizações colaboram sem compartilhar dados privados. O padrão mais novo de 2026.

Repare: os padrões 1 e 3 são essencialmente workflows com LLMs dentro. Só os padrões 4 e 5 exigem decisão dinâmica real. A maioria dos projetos em produção vive nos padrões 1-3.

Meu Framework de Decisão

Depois de errar bastante, adotei um framework simples:

Passo 1: Mapeie o processo inteiro. Antes de escrever qualquer código, mapeie cada etapa do fluxo de ponta a ponta. Use post-its, whiteboard, papel — não importa.

Passo 2: Marque os pontos de decisão. Em cada etapa, pergunte: “O próximo passo é previsível ou depende de contexto que eu não consigo antecipar?”

Passo 3: Use workflow para tudo que é previsível. Classificação? Workflow. Extração de dados? Workflow. Roteamento? Workflow. Geração de resposta baseada em template? Workflow.

Passo 4: Use agente APENAS nos pontos genuinamente imprevisíveis. Pesquisa web aberta? Agente. Diagnóstico de problema ambíguo? Agente. Negociação dinâmica? Agente.

Passo 5: Trate agentes como componentes dentro do workflow. Um agente é um componente especializado dentro de um workflow maior — não a estrutura inteira da aplicação. O workflow é o trilho. O agente é o vagão que explora o terreno quando o trilho acaba.

Conclusão: Comece Pelo Trilho

Seja pragmático. A recomendação dos engenheiros seniores é sempre começar com um workflow rígido e bem definido. Se, e somente se, você encontrar um ponto no fluxo onde o próximo passo depende de análise contextual imprevisível, adicione um agente ali.

Agentes são poderosos. Mas poder sem controle é o que derrubou a AWS da Amazon por 13 horas, deletou dados do Grigorev, e causou 6,3 milhões de pedidos perdidos. Workflows são menos impressionantes. Mas são previsíveis, baratos, auditáveis e não tomam decisões catastróficas às 3 da manhã.

A pergunta certa não é “como construir um agente?”. É: “eu realmente preciso de um?”

Na maioria das vezes, a resposta é não. E tudo bem.

Compartilhe se isso clareou sua arquitetura:

Eu gastei duas semanas construindo um agente sofisticado. Um pipeline de 50 linhas fazia o mesmo trabalho. Mais rápido, mais barato, sem surpresas. Às vezes, o código chato é o código certo.

Leia Também