Supervisor, Router e Workers: organizando uma equipe de agentes

Depois de decidir que vale a pena ter mais de um agente e que alguém precisa orquestrar essa conversa, sobra uma pergunta de organização: quem faz o quê dentro do grupo. Um dos arranjos mais comuns para responder isso não veio da IA, veio de como equipes humanas já se organizam há bastante tempo: alguém direciona o trabalho, alguém executa a parte especializada, e alguém avalia se o resultado realmente resolveu o que foi pedido.

Router: decidir para onde a tarefa vai

O Router é a peça que recebe a tarefa inicial e decide qual caminho ela deve seguir. Na prática, costuma ser um agente (ou uma chamada de classificação mais simples) que analisa a entrada e escolhe, entre um conjunto de opções conhecidas, qual Worker especializado é o mais adequado para aquele tipo de pedido.

A vantagem de separar essa decisão do resto do fluxo é permitir que cada Worker seja construído com um prompt bem mais estreito e específico, sem precisar lidar com a variedade completa de pedidos que o sistema recebe. O Router absorve essa variedade e o restante do sistema lida só com o recorte que já foi filtrado.

Workers: execução especializada, sem ambição de fazer tudo

Cada Worker é responsável por um tipo específico de tarefa, com instrução e, muitas vezes, ferramentas próprias para aquele domínio. Um Worker de busca de informação, um Worker de geração de código, um Worker de formatação de resposta final: cada um bom numa coisa, sem tentar cobrir o que os outros já fazem.

Essa especialização é o que sustenta a promessa original de arquitetura multi-agente, separação de responsabilidades bem definida, desde que o Router realmente encaminhe cada tarefa para o Worker certo e os Workers não precisem, na prática, adivinhar contexto que deveria ter vindo do Router.

Supervisor: avaliar antes de considerar a tarefa terminada

O Supervisor entra depois que um Worker (ou uma sequência deles) produz um resultado. A função dele não é executar a tarefa de novo, é avaliar se o que foi entregue atende ao objetivo original, com um critério mais explícito do que simplesmente confiar que o Worker acertou.

Esse padrão de avaliação separada do agente que gerou o resultado é o que permite capturar erro antes que ele chegue no usuário final: se o Supervisor rejeita a entrega, o fluxo pode voltar para o mesmo Worker com feedback específico sobre o que faltou, redirecionar para outro Worker mais adequado, ou escalar para intervenção humana quando nenhuma das tentativas automáticas resolve.

Estado compartilhado entre os nós

Para essa coordenação funcionar, Router, Workers e Supervisor normalmente compartilham algum tipo de estado comum durante a execução: o pedido original, o histórico de tentativas já feitas, o resultado da última avaliação. Frameworks orientados a grafo, como LangGraph, modelam isso explicitamente como um objeto de estado que passa de nó em nó, cada nó lendo e atualizando a parte que lhe interessa, em vez de cada agente operar isolado sem visibilidade do que já aconteceu antes dele na mesma execução.

Sem esse estado compartilhado, o Supervisor não tem como avaliar direito (falta contexto sobre o que foi pedido originalmente) e o Router não tem como aprender com falhas anteriores dentro da mesma execução.

O que fazer quando um agente falha

Falha aqui não significa só exceção não tratada. Significa também um Worker que devolve um resultado que passa despercebido, mas está errado, ou o Supervisor rejeitando repetidamente sem que nenhuma correção resolva. Estratégias comuns de fallback incluem redirecionar para um Worker alternativo, limitar o número de tentativas antes de escalar para revisão humana, e degradar a resposta para algo mais simples e seguro em vez de insistir indefinidamente numa versão mais ambiciosa que não está convergindo.

O ponto comum entre essas estratégias é que nenhuma delas assume que o sistema vai acertar sempre. Elas assumem que ele vai errar às vezes, e desenham um caminho para isso não travar tudo nem sair silenciosamente errado. Essa é, talvez, a diferença real entre uma arquitetura multi-agente bem pensada e uma coleção de agentes conversando entre si na esperança de que dê certo.