Pare de desenvolver agentes de IA e use fluxos de trabalho com LLM mais inteligentes

• A maioria das equipes que cria sistemas baseados em LLM tenta começar por agentes (Agents), mas quase sempre esbarra em complexidade, falta de controle e dificuldade de depuração, e tudo desmorona com facilidade
• Padrões de agente de verdade, que exigem memória, RAG, uso de ferramentas e controle de workflow ao mesmo tempo, são raros na prática; a maior parte dos problemas pode ser resolvida de forma mais eficaz com workflows simples (chaining, paralelização, roteamento etc.)
• A recomendação é aplicar primeiro 5 padrões de workflow com LLM úteis no mundo real e usar agentes com cautela apenas quando forem realmente necessários
  • Prompt chaining, paralelização, roteamento, orchestrator-worker, evaluator-optimizer
• Mesmo quando agentes são necessários, o essencial continua sendo participação humana, controle claro e observabilidade (Observability)

---

Agentes de IA: eles são mesmo necessários?

• Insights de Hugo Bowne-Anderson, que oferece consultoria e treinamento relacionados à construção de sistemas com LLM para diversos engenheiros e equipes, incluindo Netflix, Meta e a Força Aérea dos EUA
  • Ele conduz o curso Building LLM Applications for Data Scientists and Software Engineers

Um começo errado: por que todo mundo está obcecado por agentes

• Muitas equipes, ao iniciar projetos com LLM, priorizam a adoção de estruturas complexas como agentes, memória, roteamento, uso de ferramentas e personalidade
• Quando se tenta montar isso na prática, surgem falhas e comportamentos anômalos com frequência em vários pontos, como colaboração entre agentes, escolha de ferramentas e memória de longo prazo
• Como exemplo, em um projeto de agente de pesquisa baseado em CrewAI, houve a experiência de ver cada papel (pesquisador, resumidor, coordenador) falhar em cooperar como o esperado e o sistema ruir sem reação

O que é um agente?

• Quatro características de sistemas com LLM: memória, recuperação de informação (RAG), uso de ferramentas e controle de workflow
• A última delas, controle de workflow (quando o LLM decide diretamente a próxima etapa ou se deve usar uma ferramenta), é chamada de característica agêntica
• Na maior parte do trabalho real, workflows simples (chaining, roteamento etc.) mostram maior estabilidade

Padrões de workflow com LLM para usar no lugar de agentes e que são úteis na prática

1. Prompt Chaining

• Descrição: divide várias tarefas em uma sequência de etapas (chain), fazendo com que o LLM processe cada uma delas em ordem
• Exemplo: extrair nome, cargo e empresa de um perfil no LinkedIn → adicionar informações extras sobre a empresa (missão, vagas etc.) → redigir um e-mail personalizado com base no perfil + informações da empresa
• Vantagens: como cada etapa fica claramente separada, é fácil rastrear e corrigir a causa de bugs; isso ajuda na depuração e na manutenção
• Diretrizes:
  • Indicado para tarefas conectadas de forma sequencial
  • Se uma única etapa falhar, toda a cadeia pode quebrar
  • Ao dividir em unidades menores de trabalho, é possível obter resultados mais previsíveis e depuração mais simples

2. Paralelização (Parallelization)

• Descrição: executa várias tarefas independentes ao mesmo tempo para acelerar o processo como um todo
• Exemplo: extrair em paralelo vários campos, como formação, experiência e habilidades, de perfis de várias pessoas para reduzir o tempo total de processamento
• Vantagens: é eficiente para extração/processamento de dados independentes mesmo em grande escala, e combina bem com ambientes distribuídos
• Diretrizes:
  • Cada tarefa deve ser independente, e a execução simultânea deve melhorar significativamente a velocidade total
  • É preciso ter cuidado com exceções como race condition, timeout e situações semelhantes durante a execução paralela
  • Adequado para processamento de grandes volumes de dados e análise simultânea de várias fontes

3. Roteamento (Routing)

• Descrição: o LLM classifica os dados de entrada e os direciona automaticamente para o workflow apropriado em cada caso
• Exemplo: em uma ferramenta de suporte ao cliente, classificar se a entrada é uma dúvida sobre produto, problema de pagamento ou solicitação de reembolso e então encaminhar automaticamente para o workflow correspondente; se o tipo for ambíguo, enviar ao handler padrão
• Vantagens: permite aplicar lógica de processamento especializada para cada tipo de entrada, separando casos diferentes de forma limpa
• Diretrizes:
  • Use quando tipos de entrada ou situações diferentes exigirem tratamento separado
  • Em casos limítrofes ou situações excepcionais, o roteamento pode falhar ou deixar passar casos
  • É essencial projetar um handler catch-all para situações não classificadas ou excepcionais

4. Orchestrator-Worker

• Descrição: um LLM no papel de orchestrator decompõe a tarefa e toma decisões, delegando subtarefas a workers (LLMs de execução) e controlando diretamente o fluxo e a ordem geral
• Exemplo: classificar um perfil-alvo como tech/non-tech → se for tech, delegar a geração do e-mail a um worker especializado; se for non-tech, delegar a outro worker
• Vantagens: separa tomada de decisão (classificação/julgamento) da execução (processamento individual), o que favorece controle dinâmico do fluxo e expansão
• Diretrizes:
  • Adequado quando cada tarefa exige tratamento especializado, além de ramificações complexas e coordenação por etapas
  • Se o orchestrator decompor ou delegar tarefas incorretamente, podem surgir erros em todo o fluxo
  • Mantenha a lógica explicitamente simples e projete com clareza as condições de delegação, ordem e encerramento

5. Evaluator-Optimizer

• Descrição: o LLM avalia o resultado (pontuação/feedback) e, se ele não atingir o critério exigido, revisa e melhora repetidamente
• Exemplo: gerar um rascunho de e-mail → o avaliador atribui uma nota de qualidade/feedback → encerrar ao atingir um nível mínimo ou ao ultrapassar o número máximo de iterações; caso contrário, revisar novamente
• Vantagens: permite melhorar iterativamente a qualidade do resultado final até um nível desejado, sendo útil quando há critérios quantitativos
• Diretrizes:
  • Indicado para workflows em que a qualidade é mais importante que a velocidade e em que a otimização iterativa é necessária
  • Sem condição de parada, o processo pode cair em loop infinito
  • É indispensável definir critérios claros de qualidade e limites de iteração

Quando um agente realmente é necessário

• Agentes mostram seu valor em ambientes onde há intervenção humana em tempo real (Human-in-the-loop) garantida
  • Exemplo 1: apoio em ciência de dados — o LLM tenta de forma criativa consultas SQL, visualizações e recomendações de análise de dados, e a pessoa avalia/corrige o resultado
  • Exemplo 2: parceiro criativo — ideias de copy, sugestões de headline e recomendações de estrutura de texto, em que a correção de direção e a avaliação de qualidade por humanos são centrais
  • Exemplo 3: assistente de refatoração de código — sugestões de design patterns, detecção de edge cases e otimização de código, com aprovação/complementação do desenvolvedor
• Característica: o agente não faz “tudo sozinho”; ele é mais eficaz em um ambiente em que uma pessoa corrige erros e ajusta a direção em tempo real

Quando agentes não são adequados

• Sistemas enterprise e mission-critical (finanças, saúde, jurídico etc.):
  • Como confiabilidade da automação e comportamento determinístico são importantes, uma estrutura em que um agente LLM toma decisões é arriscada
  • Devem ser usados padrões de controle claros, como orchestrator e roteamento
• Qualquer situação em que estabilidade e previsibilidade sejam importantes
  • Casos anormais: problemas em que o agente escolhe ferramentas erradas repetidamente sem contexto/memória, ou em que a divisão de trabalho/coordenação falha e todo o fluxo quebra
• Fatores de falha de sistemas de agentes que aparecem com frequência no mundo real
  • Falta de um sistema de memória explícito, causando perda de contexto
  • Poucas restrições na escolha de ferramentas (uso desnecessário/incorreto de tools)
  • Dependência excessiva de uma estrutura de delegação livre, levando ao fracasso na coordenação colaborativa

Lições para o design em produção

• Mesmo ao adotar agentes, é indispensável um nível de design, observabilidade e mecanismos de controle equivalente ao de um sistema de software maduro
• Em vez de frameworks complexos de agentes, é mais rápido e seguro projetar com observabilidade (Observability), loops de avaliação claros e uma estrutura controlável diretamente

Conclusão (TL;DR)

• Agentes muitas vezes são superestimados e usados em excesso
• Na maioria dos desafios reais, padrões simples de workflow são mais adequados
• Agentes mostram seu verdadeiro valor em ambientes com participação humana direta
• Em sistemas estáveis, podem ser um fator de risco
• Projete com observabilidade, controle explícito e uma estrutura de avaliação iterativa

• Em vez de frameworks complexos de agentes, projetar com observabilidade, loops de avaliação claros e uma estrutura controlável diretamente é, na prática, o segredo para desenvolver serviços baseados em LLM de forma mais rápida e segura

[samdo103]

Há um mês, usando o CURSOR para aprender o que era programação com IA, comecei a desenvolver um framework de desenvolvimento.

Por cerca de 3 semanas, repeti o ciclo de sucesso seguido pela quebra do código-fonte que havia sido validado por um AI Agent, e tentei de todas as formas controlar o AI Agent, mas falhei.

Então percebi que, antes de desenvolver o framework, a prioridade era desenvolver o código-fonte para controlar o AI Agent.

No fim, exatamente 1 mês depois de começar tentando entender o que era a IA, alcancei o resultado de concluir o desenvolvimento de um software 100% implementável e 100% operável por IA, com controle completo sobre o AI Agent (mais precisamente, sem necessidade de LLM externo nem de AI Agent).

Agora, há 14 dias, estou conduzindo o processo de criar e fazer cumprir regras operacionais enquanto dou treinamento adicional a essa META AI para um refinamento extra, e ao mesmo tempo estou migrando, melhorando e padronizando três sistemas MES que antes haviam sido feitos de forma incompleta por pessoas, já entrando na fase final.

E agora estou me preparando para mais uma evolução.

[spilist2]

Mas, no prompt chaining, não seria igualmente válido chamar de agentes cada um dos componentes, como o LLM que executa prompts individuais, o worker de execução, o worker orquestrador e o LLM avaliador?

[spilist2]

Ah, então existe isso de "controle final do fluxo de trabalho (quando o LLM decide diretamente a próxima etapa ou se deve usar uma ferramenta) ser chamado de característica agêntica". Entendi. Era um texto falando com foco em autonomous agent. Ainda não entendo muito bem sobre agentes, então...

[GN⁺]

Opiniões do Hacker News

• Desenvolver agentes foi realmente divertido, mas está claro que há problemas sérios em engenharia de contexto. Por maior que seja a janela de contexto, ainda é preciso fazer a curadoria do que o agente vai ver, e sinto falta de filtros eficazes que selecionem apenas as informações realmente importantes. Por isso, acaba sendo necessário ajudar espalhando arquivos .md aqui e ali, e a atribuição de papéis também é importante. Esse sistema de .md é uma espécie de sistema de memória primitivo, e pode evoluir para algo muito mais robusto. Também acho possível criar, em tempo real, programas ou modelos baseados em linguagem natural a partir das interações do usuário. Usando o Claude Code, percebi que “guiar” o agente com uma suíte de testes é um mecanismo de reforço muito poderoso, e como esse loop na maioria das vezes continua funcionando bem, espero que surjam novas ideias para tornar os agentes colaboradores mais inteligentes no futuro
  • Dá a sensação de que estou gastando mais tempo lutando com as ferramentas do que fazendo o trabalho de fato
  • Fico curioso se existe alguma forma recomendada de estruturar arquivos .md nesse tipo de sistema. Tenho receio de que colocar muita marcação para facilitar a leitura humana acabe atrapalhando o processamento pelo llm. Queria saber se criar arquivos .md para humanos, do mesmo jeito que normalmente faríamos, atrapalha ou não o uso por llm
  • Pela minha experiência, gerenciamento de contexto está no centro de quase todos os problemas. Por exemplo, montar o contexto correto para tarefas paralelas/recursivas, omitir certas etapas (como editar a resposta anterior) e mostrar apenas o resultado revisado, fazer o agente reconhecer a própria saída quando eu adiciono um comentário nela etc.; na prática existem várias situações assim
  • Achei interessante essa parte de reforçar o agente com uma suíte de testes; queria saber se você poderia explicar com mais detalhes como esse processo funciona na prática
• Ainda não tenho certeza se agentes de IA vão ser usados de forma tão ampla quanto as pessoas dizem no LinkedIn, mas deixo essa possibilidade em aberto. Hoje eu uso IA de forma fortemente controlada, como com Claude Code e Cursor. O motivo não é que o modelo seja insuficiente, mas sim que eu quero fornecer com frequência meu próprio gosto e direcionamento. Dar mais autonomia para a IA não me parece necessariamente atraente, porque preciso intervir para sentir conexão com a identidade do resultado. Talvez eu mude de ideia se a forma de trabalhar evoluir ou se surgir uma nova UX, mas, no momento, não quero que a IA seja agêntica demais
  • Tenho curiosidade se você acha que, com o tempo, ao entender bem como os modelos se comportam e ao fornecer mais e melhores contextos e instruções, seria possível atender em boa medida essas demandas de gosto e direção do usuário. Pela minha experiência, só com uma engenharia de prompt bem feita já dá para fazer a IA agir do jeito desejado em muitos fluxos de trabalho, sem necessidade de intervir com tanta frequência
  • Concordo exatamente. Já deixei comentários parecidos em outros lugares, e ainda acho que o velho ditado de que “não existe almoço grátis” continua valendo. Se um LLM pudesse resolver problemas sem participação humana, isso significaria que todo mundo conseguiria construir sistemas sofisticados idênticos com apenas algumas linhas de prompt, e nesse ponto desapareceriam os diferenciais e o valor entre os sistemas. Se o prompt for um novo nível de abstração, então, por exemplo, ao pedir ao Claude “faça um app de notas”, milhões de pessoas vão inserir o mesmo prompt barato, e aí fica a dúvida sobre qual seria exatamente o valor agregado pelo promptador
  • Acho que, com o tempo, cada um desses elementos de “gosto” também poderá ser sistematizado cada vez mais em prompts. Por exemplo, um prompt pode orientar que alterações de código não introduzam mutabilidade desnecessária e usem immutable sempre que possível. Outro prompt pode estabelecer regras para evitar logs inúteis (da forma específica como eu defino isso) etc. Ao revisar alterações de código, executo todos esses prompts individualmente e reúno o resultado em saídas MCP estruturadas. Assim, aplico essas partes a um agente de código para viabilizar iterações de revisão automatizada. Se surgir uma situação em que eu precise adicionar contexto manualmente, crio um novo prompt ou amplio um já existente para reforçar isso
• É curioso como já aparecem “autoridades” em uma área que parece ter só 1 ou 2 anos de carreira. Parece a versão invertida do meme de “procuramos alguém com 10 anos de experiência numa linguagem de 2 anos”
  • Eu venho construindo o que hoje se chama de 'ai agent' desde que o GPT-3 foi lançado, e muita gente além de mim teve a mesma experiência. Já se passaram 5 anos, e se nem em 5 anos surge um especialista, então acho que talvez especialistas simplesmente não existam nesse espaço. Claro que hoje a palavra “agente” está virando um buzzword, então o significado vem se esvaziando
  • Quando você lê relatos como “trabalhei com dezenas de equipes...”, a reação natural é achar um pouco dramático
• Resumo central: se já existe uma solução predefinida, não há muita razão para usar um agente (por exemplo, os “padrões” citados no artigo). Em geral, programadores tendem a recomendar soluções mais simples e confiáveis para problemas que podem ser resolvidos com programas. No futuro, a IA talvez fique realmente inteligente a ponto de resolver qualquer problema na força bruta, mas, por enquanto, isso só aumenta a complexidade. Acho que um dos motivos para as pessoas se empolgarem com agentes é que a maioria conheceu LLMs por meio de assistentes de chat. Nesses assistentes, muitas vezes não existe uma solução fixa e a interação é complexa, então é justamente aí que os agentes mostram seu valor. Exemplo: “encontre a sexta-feira à noite mais próxima e mande uma mensagem para o Bob perguntando se ele pode se encontrar comigo” — esse é o tipo de coisa para a qual há limites em programar todos os casos com antecedência. Como a forma de interação com o assistente é praticamente infinita, agentes acabam sendo adequados
  • Funciona muito bem quando a velocidade de verificação é maior do que fazer a tarefa por conta própria. Dito isso, eu ainda tenho dificuldade em confiar na IA sem validar o resultado
• Fico me perguntando por que tantos exemplos acabam virando “como enviar spam mais rápido e melhor”
  • Também tive essa impressão. Tipo rastrear o LinkedIn para encontrar pessoas e depois mandar spam por e-mail “personalizado”
  • Dá para comparar com a ideia de que a roda no fim das contas não gira sem graxa
• Isso era verdade no fim de 2023 até o começo de 2024, mas agora, em meados de 2025, acho que já não se aplica a muitas tarefas se você estiver usando LLMs SOTA. Antes, a maioria chamava LLM como se fosse uma função, mas isso também acontecia por escolha errada de ferramenta. Hoje os melhores LLMs (Gemini 2.5 Pro, Claude 4 etc.) são realmente inteligentes, e têm ótima capacidade de seguir instruções e de escolha de ferramentas. Ferramentas de checklist, comandos de delegate, divisão de tarefas e afins continuam sendo necessárias. Mas a abordagem de criar instruções e definir comandos — especialmente se a UI permitir configurar facilmente comandos de ferramenta — é mais flexível do que workflows e representa um nível acima de abstração. Workflows visuais, no fim, continuam sendo uma forma frágil e difícil de ajustar de programação. Isso era inviável há 6–12 meses, mas, se o LLM não for bom, ainda não se aplica. Em termos gerais, como são poucos os modelos que fazem bem instruction following e integração com ferramentas, vale a pena aplicar agentes nesses modelos. Nos próximos 1–2 anos, haverá uma grande tendência de agentes para uso de navegador/computador. Eles também vão incorporar bons sistemas de memória e um “modo de demonstração/observação” para aprender (gravar) como o usuário usa a UI, além de aprender procedimentos otimizados a partir de instruções humanas verbais ou documentadas
  • Com o surgimento recente dos modelos de agente mais poderosos (Claude Opus 4 etc.), a situação mudou completamente. Ainda é preciso ter um bom contexto, mas a precisão na escolha de ferramentas é realmente excelente
  • As técnicas do post original, em sua maioria, consistem em 'modelar o problema como um grafo de fluxo de dados e segui-lo literalmente'. Ir além da modelagem e simplesmente assumir que “o modelo vai se virar” não é engenharia, é fé
• Nas últimas 3 semanas, tentei fazer agentes funcionarem de forma estável, mas no fim acabei migrando para padrões muito mais simples. Os agentes atuais parecem algo como “uma mão com seis dedos”, como se estivessem num estágio muito inicial de evolução
• Quando alguém vê algo como “o coordenador desiste se a definição da tarefa não for clara” e conclui “então descarte o coordenador e use lógica imperativa”, eu acho que na verdade isso pode ser um problema que se resolve com prompts ou descrições de ferramenta mais específicas, além de procedimentos como resumos intermediários ou compressão de contexto do LLM. Sem exemplos reais de prompts/descrições de ferramenta longos e utilizáveis no artigo, fica difícil julgar. Intuitivamente, a resposta é usar a orquestração adequada para a tarefa, mas acredito que, na prática, orquestração agêntica pode funcionar bem em muito mais tarefas do que parece
• Também concordo 100%. Agentes são muito divertidos e ótimos para experimentar, mas, para realmente aumentar a produtividade, o ponto central é orquestrar bem workflows e processos específicos, concentrando a IA naquilo que só ela pode fazer. A propósito, também recomendo o texto sobre workflows de IA em ai.intellectronica.net
• Uma coisa que tenho visto bastante ultimamente é a adoção de LLMs em ferramentas de orquestração de workflow já existentes para construir sistemas com muito mais facilidade. A maior parte da complexidade está em a) o próprio modelo (os laboratórios mais recentes fornecem modelos fáceis de usar), e b) a colocação em produção do workflow (que as ferramentas de workflow facilitam). Como esses workflows se baseiam em trabalho já existente, é fácil perceber e medir o valor. Esse padrão apareceu tanto que eu até empacotei e publiquei um SDK para Airflow (uma ferramenta de workflow extremamente popular).
  https://github.com/astronomer/airflow-ai-sdk

[sto1111]

Eu também estou atualmente criando um Computer-use Agent chamado UseDesktop.

https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq

usedesktop.com

Concordo com a maior parte do que foi dito.

Neste texto, em vez de dicas realmente práticas, ele aborda mais só uma visão geral em alto nível, então se eu fosse acrescentar mais algumas dicas para desenvolver agents/fluxos agentic baseados em LLM, no fim das contas LLMs são baseados em transformers (isto é, inferência probabilística; com base no token/state atual, eles não “entendem” contextual ou semanticamente a próxima palavra para então produzi-la, mas geram o output de forma probabilística), então por melhor que seja o sys prompt, com frequência eles não dão a resposta desejada (por exemplo, você pede uma resposta em formato JSON e às vezes ele esquece um } etc.). Por isso, é essencial sempre adicionar várias funções de fallback baseadas em regex.

E quando você escreve um sys prompt para obter structured output, normalmente usa um modelo non-reasoning, e quanto maior o contexto, mais frequentemente ocorrem alucinações, então muitas vezes é melhor criar vários sys prompts e encadear eles.

Ao desenvolver um serviço, vários erros podem acontecer, então o ponto-chave é projetar a arquitetura do serviço de forma modular e fault-tolerant (por exemplo, deixar o supervisor agent assíncrono e os demais agents síncronos), especialmente no caso de sistemas agentic e agents, onde outputs inesperados acontecem com frequência.
Por isso, desde o início, ao escrever o código, é bom seguir SRP e escrever de forma declarativa; quero dizer que vale a pena adotar uma abordagem funcional (= sem side effects e com fluxo intuitivo).

E isso pode variar dependendo de você usar LLM via API ou servir o modelo diretamente, mas se for servir um SLM ou LLM por conta própria, é melhor não fazer model serving no mesmo servidor que hospeda o backend; separar IO bound tasks e CPU bound tasks (isto é, tasks que exigem GPU, multiplicação de matrizes e coisas do tipo) em servidores diferentes é melhor para fault tolerance (por exemplo, hospedar CPU bound tasks no Runpod).

Além disso, há várias outras dicas de desenvolvimento, mas vou parar por aqui para não ficar longo demais.

Espero que isso ajude alguém.

[jypark]

Muito obrigado por compartilhar sua valiosa experiência e opinião. A opinião de alguém que está atuando diretamente na área ajuda muito.