Falhas de Loop Multiagente São Falhas de Design Organizacional, Não Falhas de Prompt

A maioria das configurações multiagente eventualmente encontra o mesmo obstáculo: agentes pulando entre si, revisores pedindo mais uma rodada de polimento para sempre, workers de pesquisa gerando subtópicos indefinidamente, chamadas de ferramentas espiralando até o limite de recursão. As documentações dos frameworks chamam isso de "loops" e oferecem um parâmetro de max-iterações. Uma hipótese que ganha força é que o parâmetro trata um sintoma, e o problema real é como os agentes estão organizados.

O padrão que se repete: quando os agentes são projetados como pares (pesquisador fala com analista, analista fala com escritor, escritor devolve para revisor), ninguém é claramente dono do resultado. Cada agente pode continuar pedindo mais trabalho a outro agente. O grafo tem condições de parada no papel, mas nenhum agente tem autoridade para declarar "está pronto, pare a execução". Essa autoridade é implícita e se dilui pela rede de pares.

A correção é tratar a rede de agentes como um organograma com linhas de reporte explícitas, não como uma sala de bate-papo de pares. Camadas propostas:

• Presidente (autoridade máxima, pode encerrar)
• Escritório de Estratégia
• Gerente de Divisão
• Líder de Equipe
• Trabalhador Especialista
• QA e Política como escritórios separados que podem rejeitar e escalonar, mas não gerar trabalho ilimitado

Mecânicas principais:

• Um dono de missão responsável por execução
• Um dono por fluxo de trabalho
• Profundidade de delegação finita
• Contrato de retorno tipado por worker: status, evidência, saída, bloqueadores, próxima ação
• Apenas o gerente tem autoridade para reabrir ou encerrar
• Memória reside nas camadas de autoridade; especialistas recebem apenas contexto limitado ao escopo

O modo de falha de recursão do revisor em particular é eliminado quando os verificadores estruturalmente têm direito a uma passagem de rejeição, depois devem escalonar.

Frameworks existentes já possuem os primitivos:

• CrewAI — processo hierárquico onde um gerente valida a saída do worker
• LangGraph — supervisores, subagentes e limite explícito de recursão
• OpenAI Agents SDK — orquestração estilo gerente, distinta de transferências entre pares
• AutoGen — GroupChatManager
• Anthropic — sistema de pesquisa orquestrador-worker

A ideia subutilizada: tratar o gerente não como moderador de um chat em grupo aberto, mas como uma linha de reporte formal com autoridade para encerrar.

Duas preocupações em aberto:

1. A hierarquia pode se tornar seu próprio gargalo — se cada decisão sobe, o presidente vira um ponto único de latência e falha.
2. Escalonamento como funcionalidade só funciona se o topo tiver autoridade real de parada. Se o presidente apenas chamar outro LLM que chama mais LLMs, o loop apenas subiu um andar.

Repositório com as camadas de organograma propostas: github.com/jeongmk522-netizen/agentlas_org_chart