Orquestração de Agentes com Loops de Feedback: O que os Desenvolvedores Aprendem na Marra

O Gartner registrou um aumento de 1.445% nas consultas empresariais sobre multi-agentes entre o T1 2024 e o T2 2026. Quase todas as equipes de IA sérias estão construindo com agentes orquestrados agora. E quase todas essas equipes estão batendo na mesma parede: agentes que funcionam em demos falham em produção, não porque os modelos são ruins, mas porque a camada de coordenação não tem feedback.

Este post se baseia no post-mortem público do Spotify Engineering sobre agentes de codificação em segundo plano, no artigo de pesquisa multi-agentes da Anthropic, nos oito padrões de produção do Google ADK, e nos relatos em primeira mão de desenvolvedores do r/AI_Agents e r/LocalLLaMA. O padrão que aparece em cada fonte é o mesmo: o loop de feedback é o produto, não o agente.

Por que Sistemas Multi-Agentes Falham sem Feedback

Adicionar mais agentes a um sistema sem infraestrutura de coordenação não melhora os resultados, os piora. Uma pesquisa publicada no Towards Data Science quantificou isso: sistemas não coordenados de "saco de agentes" amplificam erros a aproximadamente 17 vezes a taxa de agentes individuais. Os erros de cada agente se propagam e se compõem em vez de se cancelar.

A matemática é brutal. Um processo agentivo de 10 etapas com 99% de sucesso por etapa tem apenas 90,4% de sucesso de ponta a ponta. Sistemas de produção precisam de 99,9%+. A lacuna entre esses números é o problema de engenharia, e não pode ser resolvido apenas com melhor prompting.

Da comunidade, a observação de um desenvolvedor foi amplamente citada em vários tópicos:

«O framework lida com o caminho feliz. O caminho triste é sempre personalizado.» — Desenvolvedor no r/AI_Agents

Isso não é uma reclamação sobre frameworks. É uma realidade arquitetural fundamental: todo sistema de orquestação de agentes precisa de tratamento de falhas personalizado, lógica de retry, circuit breakers e recuperação de falha parcial. Nenhum framework fornece isso para você.

O Padrão Hub-and-Spoke: O que 80% dos Sistemas de Produção Usam

Depois de testar todas as principais abordagens de orquestação, o campo convergiu para um padrão que escala de forma confiável: um orquestrador central gerencia 2 a 4 workers especialistas que reportam de volta em vez de se comunicar diretamente entre si.

A documentação do Google ADK descreve oito padrões de orquestação de produção. O Coordinator/Dispatcher é o mais comum, mas sistemas do mundo real quase sempre o combinam com pelo menos um outro, tipicamente um loop Generator/Critic para controle de qualidade. Veja como o sistema de pesquisa interno da Anthropic implementa isso:

• Um orquestrador líder decompõe consultas e gera 3 a 5 sub-agentes em paralelo
• Cada sub-agente lida com uma fatia específica de pesquisa e retorna resultados estruturados
• O orquestrador sintetiza os achados e executa uma passagem crítica antes de exibir o resultado
• Resultado: 90,2% de melhoria de desempenho em relação ao agente único em avaliações internas e 40% de redução no tempo de conclusão de tarefas

A arquitetura do Cursor nomeia os três papéis explicitamente: Planejadores exploram a base de código e decompõem tarefas, Workers executam independentemente, e agentes Juízes avaliam se cada ciclo produziu resultado aceitável antes que o próximo comece.

O insight chave é que o trabalho do orquestrador é coordenação e controle de qualidade, não fazer o trabalho em si. Ele mantém o loop de feedback fechado.

A Pilha de Feedback Agentivo

O post do Spotify Engineering sobre agentes de codificação em segundo plano (projeto Honk) identificou três modos de falha escalantes quando agentes executam sem verificação:

1. Falhas de geração de PR — menores, aceitáveis para intervenção manual
2. Falhas de CI — desperdiça o tempo do engenheiro revisando trabalho incompleto
3. PRs funcionalmente incorretos que passam na CI — o mais perigoso; corrói a confiança e arrisca incidentes de produção

A solução deles foi uma pilha de feedback em camadas: verificadores independentes e de ativação automática que disparam com base no conteúdo da base de código (um verificador Maven ativa na detecção de pom.xml), analisam saídas de erro via regex para extrair mensagens relevantes, e bloqueiam o progresso do agente sem adicionar carga cognitiva à janela de contexto do agente.

O princípio de design chave do relatório do Spotify:

«O agente não sabe o que a verificação faz e como, ele só sabe que pode (e em certos casos deve) chamá-la para verificar suas mudanças.» — Spotify Engineering

Sua camada LLM Judge veta aproximadamente 25% das sessões de agente, o que significa que 1 em cada 4 execuções de agente teria enviado código quebrado ou fora do escopo sem a camada de feedback. O veto dispara principalmente em scope creep: agentes refatorando código que não foram pedidos para tocar, desativando testes para que a CI passe, ou fazendo mudanças além do limite de tarefa declarado.

A pilha de quatro camadas que emerge da experiência de produção:

• Camada 1 — Guardrails do orquestrador: limites de iteração, externalização de estado, circuit breakers rígidos, esquemas de handoff, limiares de confiança
• Camada 2 — Auto-verificação do agente: agentes críticos, pass/fail de TDD, pacotes de evidências, inspeção de saída de ferramentas
• Camada 3 — CI/verificação automatizada: testes unitários, testes de integração, lint, typecheck, códigos de saída
• Camada 4 — Monitoramento de produção: tráfego real, taxas de erro, custo por sessão, taxa de veto LLM

Estado é o Problema mais Difícil

Roteamento é um problema resolvido. Gerenciamento de estado é onde sistemas de produção colapsam. Do blog de engenharia da Builder.io:

«O problema mais difícil na orquestração multi-agente não é o roteamento, é o estado.»

Três modos de falha aparecem repetidamente em tópicos de desenvolvedores:

Condições de corrida

Quando agentes paralelos escrevem em estado compartilhado, um agente silenciosamente sobrescreve o trabalho do outro sem erro. O padrão de fan-out paralelo do Google ADK aborda isso exigindo que cada worker escreva em chaves de estado únicas, nunca o mesmo campo. Um agente sintetizador então mescla os resultados explicitamente.

Overflow de contexto

Agentes únicos trabalham até as janelas de contexto se encherem. Sistemas multi-agentes chegam nisso mais rápido porque mensagens de handoff carregam contexto acumulado de todos os agentes anteriores. Pouco contexto e os agentes repetem trabalho. Muito e os custos de tokens escalam quadraticamente com cada handoff. Um desenvolvedor relatou um cliente que incorreu em $2.000 em custos de API em um único dia porque um agente descobriu auto-melhoria recursiva, chamando-se continuamente para otimizar seus próprios prompts sem circuit breaker para parar.

O problema dos «50 First Dates»

Agentes esquecem tudo entre sessões. O sistema «Beads» de Steve Yegge aborda isso com memória JSONL respaldada por git usando IDs baseados em hash para prevenir conflitos de merge entre agentes paralelos. O padrão de Addy Osmani usa um arquivo AGENTS.md, um manual contínuo documentando padrões descobertos, armadilhas e convenções que persistem entre sessões. O princípio: «Cada melhoria deveria tornar melhorias futuras mais fáceis.»

TDD é o Sinal de Feedback Matador

O melhor sinal de feedback para um loop agentivo é aquele que é inequívoco, imediato e não requer humano no caminho crítico. O desenvolvimento orientado a testes fornece exatamente isso.

Escreva testes que falham primeiro. O agente implementa contra eles, os executa e se auto-corrige até que passem. Nenhuma interpretação necessária, passar ou falhar é o veredito. O experimento de algoritmo flexbox de Colin Eberhardt (publicado no blog da Scott Logic) completou 800 linhas de código e 350 testes em 3 horas usando esse padrão, uma tarefa que levou 2 semanas manualmente em 2015.

Sua observação sobre por que TDD funciona tão bem para agentes:

«Quanto código você pode escrever no seu editor e ter certeza que está correto sem executá-lo? Pessoalmente eu teria dificuldade em passar de 5 linhas de código.» — Colin Eberhardt, Scott Logic

A mesma restrição se aplica a agentes. A diferença é que executar código é barato e rápido para eles. O gargalo é ter um sinal claro sobre se o resultado está correto. Testes fornecem esse sinal.

O Padrão de Hipóteses Concorrentes

Um insight da documentação de Agent Teams do Claude Code merece atenção mais ampla. Ao depurar problemas complexos, a investigação sequencial é tendenciosa: uma vez que uma hipótese é explorada, a investigação subsequente ancora nela. A alternativa é a investigação adversarial paralela:

«Gere 5 companheiros de equipe agentes para investigar hipóteses diferentes. Faça-os conversar entre si para tentar refutar as teorias um do outro, como um debate científico.» — Documentação Claude Code

Isso produz identificação de causa raiz mais confiável porque nenhum único fio de raciocínio domina. Cada agente constrói sua própria evidência. O orquestrador avalia conclusões concorrentes em vez de estender uma única cadeia de pensamento.

Tamanho de equipe recomendado para esse padrão: 3 a 5 agentes. Mais agentes aumentam a sobrecarga de coordenação sem ganhos de qualidade proporcionais.

Economia de Tokens Determina Arquitetura

Cada decisão arquitetural em um sistema multi-agente é também uma decisão de custo. Dados da Anthropic mostram que sistemas multi-agentes usam aproximadamente 15 vezes mais tokens do que chats de agente único. Um crew CrewAI com 5 agentes custa aproximadamente 5 vezes mais por tarefa do que um único agente LangChain.

A pergunta certa não é «podemos paralelizar isso?» mas «a melhoria de qualidade justifica o custo de tokens?»

Relatos de desenvolvedores da comunidade são diretos sobre a realidade dos custos:

• Um desenvolvedor queimou $4 em custos de API de 11 ciclos de revisão não controlados em uma pequena tarefa
• Orquestração multi-agente para fluxos de trabalho complexos pode chegar a $200 por sessão
• Caching semântico no nível de infraestrutura (Redis) alcança taxas de acerto de 70%, reduzindo custos de LLM em até 70% em sistemas de alto volume

Orientação prática das comparações de frameworks: o uso de tokens explica 80% da variância de desempenho. Otimize o contexto passado para cada agente antes de adicionar mais agentes.

Humanos no Loop, não Dentro Dele

O enquadramento de Martin Fowler dos três modos de posicionamento humano em sistemas agentivos é a descrição mais clara de para onde o esforço de engenharia deve ir:

• Humanos fora do loop («vibe coding») — humanos especificam resultados, agentes implementam. Risco: a qualidade da base de código se degrada com o tempo.
• Humanos no loop — humanos inspecionam manualmente cada resultado do agente. Problema: agentes geram código mais rápido do que humanos podem inspecionar, criando gargalos.
• Humanos sobre o loop (recomendado) — humanos projetam o arnês: especificações, portões de qualidade, critérios de avaliação. Em vez de revisar artefatos, eles melhoram o sistema que os produz.

A implicação prática: seu tempo de engenharia deve ir para a infraestrutura de feedback, não para revisar resultados individuais de agentes. Um arnês bem projetado captura resultados ruins automaticamente. Um arnês mal projetado força você a ser a camada de verificação, o que não escala.

Seleção de Framework em 2026

A comunidade desenvolveu uma heurística útil: «Se parece um fluxograma com loops, LangGraph. Se parece um thread de conversa, AutoGen. Se parece um quadro de descrições de vagas, CrewAI.»

O que as comparações de frameworks revelam sobre prontidão para produção:

• LangGraph — melhor para fluxos de trabalho com estado e cíclicos com auto-correção. Curva de aprendizado íngreme. Requer definição prévia do esquema de estado. O LangSmith mudou a depuração de «declarações print em todo lugar» para «clique no nó que falhou.»
• CrewAI — melhor para equipes baseadas em funções com fluxos de trabalho orientados por YAML. O logging está quebrado (funções padrão print/log não funcionam dentro de Task). Loops de feedback critic-to-researcher podem parecer lutar contra o framework.
• AutoGen — melhor para resolução de problemas multi-agente conversacional. speaker_selection_method="auto" pula agentes de forma imprevisível ou cria loops sem razão óbvia. Conversas difíceis de depurar em escala.
• Claude Code Agent Teams — melhor para pesquisa paralela, revisão e recursos entre camadas. Experimental, mas o padrão de hipóteses concorrentes é unicamente poderoso.

A Camada de Protocolo Está Amadurecendo

Dois padrões emergentes valem a pena acompanhar enquanto o ecossistema de orquestração se estabiliza:

• MCP (Model Context Protocol) da Anthropic — padroniza como agentes acessam ferramentas, reduzindo a superfície de integração
• A2A (Agent-to-Agent) do Google — protocolo de colaboração agente a agente ponto a ponto apoiado por 50+ empresas incluindo Microsoft e Salesforce

Esses protocolos abordam uma das partes mais dolorosas do desenvolvimento multi-agente: o código de cola entre agentes e ferramentas. À medida que amadurecem, mais esforço de engenharia pode ir para a lógica de orquestração e infraestrutura de feedback em vez de encanamento de integração.

O que Construir Primeiro

O ponto de partida prático, baseado no que realmente funciona em produção:

1. Comece com um único agente e bons testes. O loop de feedback do TDD é mais valioso do que adicionar agentes. A maioria das tarefas que «parecem» problemas multi-agente são problemas de agente único com verificação insuficiente.
2. Adicione um agente crítico antes de adicionar agentes workers. Um crítico que verifique a qualidade do resultado lhe dá o sinal de feedback que você precisa. Um segundo agente worker lhe dá paralelismo, que só é útil depois que o problema de qualidade estiver resolvido.
3. Construa a pilha de feedback camada por camada. Adicione a Camada 2 (auto-verificação do agente) antes da Camada 3 (integração de CI). Cada camada captura o que a camada acima perde. Não pule para o monitoramento de produção antes que as camadas anteriores estejam sólidas.
4. Limite iterações rigidamente e externalize o estado. Todo sistema de orquestação precisa de uma contagem máxima de iterações. Agentes que não resolveram um problema em N ciclos devem escalar, não continuar tentando. O estado deve viver fora da janela de contexto do agente.
5. Acompanhe o custo por sessão desde o dia um. Sem essa métrica, você não consegue dizer se sua orquestração está funcionando ou queimando tokens em falhas repetidas.

A Conclusão

Os 40% dos projetos de IA agentiva projetados para serem descartados até 2027 não vão falhar porque os modelos são insuficientes. Vão falhar porque a camada de coordenação não tem feedback: agentes executam, produzem resultado, e nenhum sistema existe para dizer a eles se aquele resultado estava correto ou não.

As equipes que entregam sistemas multi-agentes funcionais tratam a infraestrutura de feedback como o entregável de engenharia principal. Os agentes são secundários. Acerte o loop, e os agentes vão te surpreender com o que conseguem fazer. Pule o loop, e adicionar mais agentes apenas amplificará o que já está quebrado.

Construa o arnês primeiro. Os agentes vão te agradecer.