Orquestração de agentes de IA: quando um agente vira vários e como não perder o controle

Todo projeto de agentes de IA que dá certo chega ao mesmo ponto. O agente único que resolvia bem uma tarefa começa a receber tarefas demais, o prompt passa de três páginas, as ferramentas passam de vinte e a taxa de erro sobe. A resposta natural é dividir. É aí que começa a orquestração de agentes de IA, e é aí que a maioria dos times perde o controle do sistema.

Este texto descreve os padrões que usamos em produção, o que precisa existir para vários agentes trabalharem juntos sem se atropelar e os sinais de que a divisão foi longe demais. É um texto de engenharia, escrito para quem vai decidir arquitetura ou aprovar quem decide.

Sinais de que um agente só não basta

Um agente é um modelo de linguagem em loop com acesso a ferramentas, que planeja, executa e verifica até concluir uma tarefa. Funciona bem enquanto a tarefa é coesa e o conjunto de ferramentas é pequeno. Deixa de funcionar quando aparecem estes sintomas.

• Prompt com instruções contraditórias. O mesmo agente precisa ser rigoroso ao validar um contrato e criativo ao redigir uma resposta. As instruções se anulam.
• Ferramentas demais. Acima de quinze ou vinte ferramentas, o modelo começa a escolher errado com frequência, mesmo com descrições boas.
• Contexto estourando. A tarefa exige carregar documentos, histórico e resultados intermediários que juntos não cabem na janela, ou cabem com custo proibitivo.
• Permissões incompatíveis. Parte da tarefa pode consultar dados de cliente e parte não pode. Um agente único com todas as permissões é um risco de segurança.
• Etapas com exigências diferentes. Uma etapa precisa de latência baixa e modelo pequeno; outra precisa de raciocínio longo e modelo grande. Um agente só não otimiza os dois.

Se dois ou mais desses sintomas aparecem, dividir é o caminho. Se aparece só um, provavelmente o problema se resolve com prompt, ferramentas ou contexto melhor. Uma consultoria de IA experiente vai tentar as correções simples antes de propor um sistema multiagente, porque cada agente a mais é custo, latência e superfície de falha.

Padrões de orquestração de agentes de IA que funcionam em produção

Existem dezenas de variações na literatura. Na prática, três padrões cobrem quase tudo o que colocamos em produção.

Supervisor

Um orquestrador de agentes de IA recebe a tarefa, decide qual agente especialista chamar, avalia o resultado e decide o próximo passo. Os especialistas não conversam entre si, só com o supervisor. É o padrão mais fácil de controlar, porque há um único ponto de decisão e um único lugar para registrar o que aconteceu. O custo é que o supervisor vira gargalo e acumula contexto a cada rodada.

Pipeline

Os agentes formam uma sequência fixa: o primeiro extrai, o segundo valida, o terceiro redige, o quarto revisa. Cada um recebe a saída do anterior e nada mais. Não há decisão dinâmica de roteamento. É o padrão mais barato, mais previsível e mais fácil de testar, porque cada etapa tem entrada e saída definidas. Serve para processos com passos conhecidos, como análise de documento ou triagem de ticket.

Especialistas paralelos

A tarefa é dividida em partes independentes, resolvidas ao mesmo tempo por agentes diferentes, e um agregador consolida. Exemplo: analisar um contrato pelas lentes jurídica, financeira e operacional simultaneamente. Ganha em latência e em qualidade por especialização. Perde em custo, porque roda tudo de uma vez, e em consistência, porque os especialistas podem se contradizer e o agregador precisa resolver.

Na maioria dos sistemas reais os padrões se combinam: um supervisor que aciona pipelines, ou um pipeline com uma etapa paralela. A regra que seguimos é começar com pipeline sempre que o processo permitir, e só introduzir supervisor quando o roteamento dinâmico for necessidade comprovada.

Estado, memória e handoff entre agentes

A parte que mais falha em sistemas multiagentes de IA não é o modelo. É a passagem de bastão. Quando o agente A termina e o agente B começa, o que B sabe? Se a resposta é “tudo que A viu”, o contexto explode. Se é “só o resultado final de A”, informação relevante se perde. O desenho do handoff é decisão de arquitetura, não detalhe.

Tratamos três tipos de estado de forma separada.

Estado da tarefa. O que já foi feito, o que falta, quais resultados intermediários existem. Fica fora dos agentes, em um armazenamento estruturado que qualquer agente pode consultar e que o orquestrador atualiza. Não vive no prompt.

Memória de contexto. Os documentos, dados e histórico que um agente precisa para a etapa atual. É montada sob demanda a cada chamada, a partir de uma camada de recuperação, e descartada depois. A mesma disciplina de RAG corporativo se aplica: permissão, versionamento, medição de aderência.

Memória de longo prazo. O que o sistema aprendeu sobre um cliente, um caso ou um processo ao longo de várias execuções. É a mais perigosa, porque acumula erro e dado pessoal. Precisa de política de retenção, de revisão e de possibilidade de apagar, por exigência da LGPD e por higiene.

O handoff em si deve ser um contrato explícito: o agente entrega um objeto com campos definidos, validado antes de seguir. Se a validação falha, volta ou escala para humano. Handoff em texto livre, onde o próximo agente precisa interpretar o que o anterior quis dizer, é a fonte número um de erro silencioso que vimos em produção.

Observabilidade: traces, custos, falhas

Um agente único que erra é fácil de depurar: há um prompt, uma resposta, uma lista de chamadas de ferramenta. Cinco agentes que erram juntos produzem um emaranhado onde ninguém sabe quem decidiu o quê. Sem observabilidade desenhada desde o início, a arquitetura de agentes de IA vira uma caixa preta que ninguém consegue operar.

O mínimo que exigimos em produção:

• Trace por tarefa. Um identificador único que atravessa todos os agentes, com cada chamada de modelo, cada ferramenta acionada, cada decisão de roteamento e o tempo gasto em cada uma.
• Custo por tarefa e por agente. Tokens de entrada e saída, modelo usado, custo em reais. Agregado por dia, por tipo de tarefa e por agente. Sem isso, o primeiro mês em produção traz uma fatura surpresa.
• Taxa de falha por etapa. Quantas vezes cada agente devolveu resultado inválido, estourou tempo, chamou ferramenta errada ou escalou para humano.
• Amostragem para avaliação. Uma fração das tarefas vai para revisão humana ou para um modelo juiz, com o resultado alimentando o painel de qualidade.
• Limites duros. Máximo de rodadas, máximo de tokens e máximo de custo por tarefa. Quando o limite bate, o sistema para e escala. Agente em loop infinito é o incidente mais caro que existe.

Um detalhe que faz diferença: o trace precisa ser legível por quem opera, não só por quem desenvolveu. Se a segunda linha de defesa, o compliance ou o suporte não conseguem abrir um trace e entender o que o sistema fez, a observabilidade existe só no nome.

Outro detalhe: a observabilidade precisa existir antes do primeiro dia em produção, não depois do primeiro incidente. Instrumentar um sistema multiagente que já está rodando é muito mais caro do que desenhar com a instrumentação desde o início, e o incidente que motiva o trabalho costuma ser exatamente o que ninguém consegue explicar.

Quando orquestração é excesso

Orquestração de agentes de IA é ferramenta para problema específico, não estágio de maturidade a ser alcançado. Vemos com frequência sistemas com cinco agentes fazendo o que um pipeline determinístico com uma única chamada de modelo faria melhor.

Sinais de que a orquestração passou do ponto:

• Agentes que só repassam informação sem transformar nada.
• Roteamento dinâmico que, na prática, escolhe sempre o mesmo caminho. Isso é pipeline com custo de supervisor.
• Mais de 30% do custo por tarefa gasto em coordenação, e não em trabalho útil.
• Latência total que inviabiliza o uso no processo real.
• Ninguém no time consegue explicar, em uma frase, por que cada agente existe.

A pergunta que fazemos antes de adicionar um agente: qual sintoma da lista da primeira seção ele resolve? Se não há resposta clara, o agente não entra. Sistemas menores são mais baratos, mais rápidos, mais fáceis de auditar e mais fáceis de explicar para quem aprova o orçamento.

Perguntas frequentes

Qual a diferença entre orquestração de agentes de IA e automação de workflow?

Automação de workflow executa passos fixos com regras determinísticas. Orquestração de agentes de IA coordena componentes que decidem com base em linguagem e contexto, com roteamento que pode variar por tarefa. Muitos processos precisam só do primeiro, com um modelo de linguagem em uma ou duas etapas.

Preciso de um framework de orquestração?

Ajuda, mas não substitui desenho. Frameworks resolvem loop, chamada de ferramenta e trace básico. Não resolvem contrato de handoff, política de memória, limites de custo nem integração com seus sistemas. Escolha um que não esconda o que o modelo está fazendo.

Quantos agentes é razoável ter em produção?

Na nossa experiência, a maioria dos sistemas úteis tem entre dois e seis agentes. Acima disso, o custo de coordenação e observabilidade cresce mais rápido que o ganho. Se o desenho pede mais, provavelmente há dois sistemas diferentes disfarçados de um.

Como controlar o custo de um sistema multiagente?

Limites duros por tarefa, roteamento de etapas simples para modelos menores, cache de contexto e medição por agente desde o primeiro dia. O custo de um sistema multiagente não é o custo de um agente vezes o número de agentes; é isso mais a coordenação, e a coordenação costuma ser subestimada.

Se está avaliando dividir um agente em vários ou desenhando um sistema do zero, a página de agentes de IA descreve como estruturamos esses projetos, do primeiro agente ao sistema orquestrado em produção.