Lição 5: Falha e coordenação

Objetivos de aprendizado:

• Explicar por que um subagente que afirma estar “pronto” não pode ser tomado ao pé da letra, e por que você precisa de uma forma independente de verificar
• Reconhecer as duas falhas comuns na colaboração multiagente: trabalho duplicado e resultados conflitantes
• Na etapa de integração de resultados, saber como remover duplicatas e como lidar com saídas contraditórias

Pré-requisitos: concluir a Lição 4, capaz de diferenciar os três padrões de colaboração e o handoff | Anterior: Lição 4 << | Próxima: Lição 6 >>

Dois subagentes pesquisam cada um o plano inicial do mesmo provedor de nuvem. Um relata que começa em $20 por mês, o outro diz $25 — e ambas as saídas confiantemente se marcam como “verificado, sem erros”. As lições anteriores todas cobriram como montar a colaboração multiagente; esta cobre onde ela falha depois de você tê-la construído — o status autorrelatado de um subagente não pode ser confiado, trabalho duplicado, resultados conflitantes — e o que o orquestrador deveria fazer sobre cada um.

Um subagente dizendo “pronto” não significa que ele acertou

Quando um subagente devolve um resultado, ele geralmente adiciona uma linha como “concluído” ou “verificado, sem erros”. Essa afirmação não é evidência — é apenas o resumo que o próprio subagente faz da própria saída, e esse resumo pode estar errado. A observação oficial do comportamento de agentes é exatamente esta: "Claude stops when the work looks done. Without a check it can run, "looks done" is the only signal available, and you become the verification loop: every mistake waits for you to notice it."¹ É por isso que o conselho oficial é "Have Claude show evidence rather than asserting success."¹

A documentação oficial chama isso de trust-then-verify gap (lacuna do confiar-e-depois-verificar): "The trust-then-verify gap. Claude produces a plausible-looking implementation that doesn't handle edge cases. Fix: Always provide verification (tests, scripts, screenshots). If you can't verify it, don't ship it."¹ Esse conselho foi escrito sobre escrever código, mas a mesma lógica se aplica a qualquer delegação: o que um subagente devolve se lê de forma fluida, tem o formato certo, parece ter sido feito com cuidado — e tudo isso é só “plausível na aparência”, o que não é o mesmo que de fato correto. Se o orquestrador toma um subagente pela palavra de que está “pronto” e emenda a saída direto no resultado final, ele pulou a verificação por completo.

Como verificar: defina um padrão verificável para a saída de um subagente

“Não tome pela palavra” é fácil de dizer; a parte difícil é como verificar. Ler uma vez e decidir que “parece bom” não é verificação — isso ainda está preso na primeira metade da trust-then-verify gap. A abordagem confiável é definir primeiro um padrão concreto e verificável e depois medir a saída do subagente em relação a ele.

Um padrão usado em um sistema de produção se parece com isto: "We used an LLM judge that evaluated each output against criteria in a rubric: factual accuracy (do claims match sources?), citation accuracy (do the cited sources match the claims?), completeness (are all requested aspects covered?), source quality (did it use primary sources over lower-quality secondary sources?), and tool efficiency (did it use the right tools a reasonable number of times?)."² O que esses cinco critérios têm em comum é que cada um pode ser verificado concretamente, não pontuado por impressão. A precisão factual pode ser verificada linha a linha em relação às fontes que o subagente citou; a completude pode ser verificada em relação a cada requisito listado na descrição da tarefa, para ver se todos foram cobertos; a eficiência de ferramentas pode ser lida direto do log de chamadas, para julgar se houve chamadas obviamente redundantes ou duplicadas.

Trazendo isso para a sua própria configuração de colaboração, o primeiro passo para verificar a saída de um subagente não é perguntar “isso parece certo”, mas perguntar “para esta tarefa, quais critérios eu posso verificar concretamente” — liste-os e depois meça a saída em relação a cada um.

Trabalho duplicado: vários subagentes fazendo a mesma coisa

A Lição 3 cobriu como uma descrição de tarefa que não é detalhada o suficiente leva a subagentes que "misinterpreted the task or performed the exact same searches as other agents."² Essa é a causa raiz, mas a falha normalmente só vem à tona no momento em que os resultados são agregados — o orquestrador recebe várias saídas de subagentes e descobre que duas delas se sobrepõem fortemente, cobrindo a mesma coisa com palavras diferentes.

Trabalho duplicado não é um erro catastrófico em si — o conteúdo não está errado, ele só desperdiça os tokens e as chamadas que deveriam ter coberto um ângulo diferente. Mas é um sinal: os limites de tarefa de alguns subagentes não foram desenhados com clareza suficiente, e vale voltar para verificar as descrições de tarefa da etapa de despacho, em vez de apenas remover manualmente as duplicatas deste lote de resultados e dar por encerrado. Quando você detecta trabalho duplicado, em vez de apenas apagar o conteúdo repetido, é mais valioso descobrir por que ele se repetiu — se as duas descrições de tarefa se sobrepuseram em escopo, ou se os subagentes derivaram cada um para a mesma direção, a mais óbvia.

Resultados conflitantes: dois subagentes chegam a conclusões contraditórias

Mais complicado que trabalho duplicado é um conflito de resultados — como a cena que abriu esta lição: dois subagentes fazem cada um sua própria pesquisa e devolvem conclusões que se contradizem, um dizendo que o plano inicial começa em $20 por mês, o outro dizendo $25. Você não pode lidar com isso “só escolhendo um” ou “rachando a diferença” — ambas as abordagens correm o risco de servir um número errado como a conclusão final.

Quando você bate em um conflito de resultados, a ordem sensata é: primeiro olhar em que cada lado baseou sua resposta — eles consultaram fontes diferentes, um usando a página ao vivo atual do provedor e o outro usando por acidente uma página antiga em cache; se a base pode ser rastreada, você normalmente consegue dizer qual é mais confiável e substituir a não confiável; se a própria base não consegue resolver quem está certo, não decida você mesmo durante a integração — sinalize a contradição como está para revisão humana, ou suba um novo subagente especificamente para verificar aquele ponto de discordância. O problema que um conflito de resultados expõe normalmente é mais digno de preocupação do que trabalho duplicado — significa que pelo menos uma saída de subagente está errada, e se você a joga no resultado final sem tratamento, você empacotou um erro não verificado como uma conclusão “pronta”.

Integração de resultados e remoção de duplicatas: o que o orquestrador faz para fechar

Costurar várias saídas de subagentes em um resultado final não é uma questão de concatená-las uma após a outra — significa percorrer de novo as categorias de problema acima: há conteúdo duplicado que precisa ser mesclado, há conclusões contraditórias que precisam ser verificadas ou sinalizadas, cada afirmação remonta a uma base correspondente. Esse último ponto é especialmente fácil de esquecer — a Lição 3, “Escrevendo prompts para delegação”, mencionou que o sistema de produção montou um agente dedicado, descrito como "a CitationAgent, which processes the documents and research report to identify specific locations for citations. This ensures all claims are properly attributed to their sources."² A mesma lógica vale na etapa de integração: uma vez que várias saídas de subagentes são reunidas, é fácil ter atribuição errada — escrever como uma conclusão sobre a empresa pela qual o subagente B era responsável dados que o subagente A encontrou. Verificar a atribuição de fonte de cada afirmação na etapa de integração importa tanto quanto verificar se os próprios fatos são precisos.

Remover duplicatas, verificar conflitos e checar a atribuição de fonte — esses três juntos são o trabalho real da etapa de “agregar”, e não, como a Lição 2 alertou, apenas concatenar as respostas brutas dos subagentes e dar por encerrado.

Recapitulação

• “Pronto” ou “verificado, sem erros” quando um subagente devolve é apenas um autorrelato, não evidência. Sem uma verificação que ele possa rodar, “parece pronto” é o único sinal disponível¹; a documentação oficial é explícita de que o Claude "produces a plausible-looking implementation that doesn't handle edge cases", e se você não consegue verificá-la, não a entregue.¹
• A verificação não pode parar em “se lê bem” — defina critérios verificáveis para a tarefa específica, como a rubrica com que o LLM juiz oficial trabalhou, onde precisão factual, precisão de citação, completude, qualidade de fonte e eficiência de ferramentas podem cada um ser verificados linha a linha.²
• Trabalho duplicado é uma consequência comum de limites de tarefa que não foram desenhados com clareza², normalmente vindo à tona só quando os resultados são agregados; detectar uma duplicata não é apenas apagar o conteúdo extra, vale voltar para verificar as descrições de tarefa da etapa de despacho.
• Resultados conflitantes — dois subagentes chegando a conclusões contraditórias — não podem ser tratados escolhendo um ao acaso ou rachando a diferença; verifique primeiro a credibilidade da base de cada lado e, quando você não conseguir ranqueá-las, sinalize o conflito como está para revisão humana.
• A etapa de integração faz três coisas ao mesmo tempo: remover duplicatas, verificar conflitos e checar se a atribuição de fonte de cada afirmação está errada² — esse é o trabalho real da etapa de “agregar”, não apenas concatenar as respostas brutas dos subagentes.

>> Lição 6: Mão na massa: construindo um pipeline de revisão de dois agentes