Iterative Audit Convergence in LLM-Managed Multi-Agent Systems: A Case Study in Prompt Engineering Quality Assurance

Resumo Técnico: Convergência de Auditoria Iterativa em Sistemas Multi-Agente Gerenciados por LLM

Declaração do Problema
As especificações de prompt para sistemas de Modelo de Linguagem de Grande Porte (LLM) multi-agente funcionam como a fonte de verdade do sistema, contendo contratos de dados, lógica de integração e regras comportamentais em arquivos interdependentes. Diferentemente do código-fonte tradicional, essas especificações em linguagem natural raramente são submetidas a um rigor de inspeção estruturada. Em pipelines de orquestração complexos e multi-lane, alterações de design em um documento frequentemente criam efeitos dominó (por exemplo, referências desatualizadas, incompatibilidades de esquema ou contratos de API inválidos) em outros. Revisões tradicionais de arquivo único são insuficientes por construção, pois não conseguem detectar inconsistências entre documentos. Este artigo aborda a falta de dados empíricos sobre a densidade de defeitos e o comportamento de convergência da auditoria iterativa aplicada a especificações de prompt em escala de produção.

Metodologia
O estudo apresenta um caso empírico de sistema único do AEGIS (Sistema Autônomo de Governança e Inteligência de Engenharia), um pipeline de orquestração de produção com sete lanes. A superfície de especificação consistiu em aproximadamente 7.150 linhas distribuídas em oito arquivos: sete arquivos PROMPT.md específicos de lane e um arquivo TICKET_CONTRACT.md compartilhado.

A metodologia de auditoria seguiu uma abordagem estruturada e iterativa, adaptada das tradições de inspeção de software (especificamente as walkthroughs de Weinberg e Freedman, em vez de inspeções completas de Fagan):

• Auditor: Sub-agentes Claude (a mesma família de LLM que autorou as especificações) atuaram como inspetores.
• Protocolo: Nove rodadas sequenciais de auditoria foram conduzidas ao longo de cinco semanas. O protocolo evoluiu durante o estudo: as rodadas iniciais focaram em verificações estruturais por arquivo, enquanto as rodadas posteriores carregaram explicitamente as especificações de produtor e consumidor juntas para realizar comparações entre lanes.
• Lista de Verificação: Uma lista de verificação de sete dimensões orientou os agentes, cobrindo consistência de versão, alinhamento de contratos de dados entre lanes, limites de permissão do Jira, convenções de rótulos, propagação da contagem de lanes, alinhamento de cadência e contradições internas.
• Critério de Convergência: O loop foi encerrado quando uma auditoria de escopo total (todos os oito arquivos) retornou zero achados. O estudo observa que o protocolo de auditoria co-evoluiu com a descoberta de defeitos, o que significa que a "função de auditoria" mudou entre as rodadas.

Principais Contribuições
O artigo oferece três contribuições delimitadas derivadas estritamente do estudo de caso:

1. Taxonomia de Defeitos (C1): Uma taxonomia pós-hoc de sete categorias de 51 defeitos superficiais, incluindo regras de codificação explícitas e exemplos representativos. As categorias são: Deriva de Versão, Referências de Jira Desatualizadas, Incompatibilidade de Esquema entre Lanes, Cobertura Ausente de Extensão Recente (Lane 7), Lacunas de Rótulo/Contrato, Texto Semanticamente Enganoso e Deriva de Fórmula/Timing.
2. Comportamento de Convergência Observado (C2): Dados empíricos mostrando convergência não monotônica. As contagens de defeitos por rodada foram 15, 8, 12, 2, 8, 1, 4, 1 e 0. O artigo interpreta os aumentos nas rodadas 3 e 5 não como regressões, mas como resultado da expansão do escopo de auditoria (por exemplo, migrando de verificações de arquivo único para verificações entre lanes), o que revelou inconsistências anteriormente mascaradas.
3. Protocolo de Auditoria Destilado (C3): Um protocolo reproduzível, incluindo uma lista de verificação travada, modelo de prompt, esquema de achados e um critério de convergência recomendado (duas passagens limpas consecutivas, mais estrito que a regra de passagem única usada no estudo).

Resultados

• Descoberta de Defeitos: O processo iterativo revelou 51 defeitos distintos de consistência de especificação de prompt. Isso é distinto dos 51 achados de código adversarial categorizados por STRIDE relatados em um pré-impresso complementar; o estudo atual foca na consistência da especificação (por exemplo, deriva de versão, referências desatualizadas) e não em vulnerabilidades de segurança em tempo de execução.
• Distribuição de Defeitos: A categoria mais prevalente foi Referências de Jira desatualizadas (12 defeitos, 23,5%), refletindo mudanças arquiteturais onde a criação de tickets do Jira foi removida de uma lane específica. Incompatibilidades de esquema entre lanes (5 defeitos, 9,8%) foram codificadas como alta severidade porque poderiam causar falhas silenciosas em tempo de execução (por exemplo, um produtor emitindo priority_score enquanto um consumidor espera fix_priority).
• Densidade de Defeitos: O estudo calculou uma densidade de aproximadamente 7,1 defeitos por mil linhas de especificação.
• Dinâmica de Convergência: A revisão de arquivo único perdeu completamente as incompatibilidades de esquema entre lanes. Esses defeitos só surgiram em rodadas posteriores (4–8) quando o escopo da auditoria foi expandido para incluir visibilidade multi-arquivo. O estudo observou que corrigir problemas estruturais nas rodadas iniciais às vezes revelou inconsistências semânticas que estavam anteriormente mascaradas.

Significado e Alegações
O artigo faz três alegações modestas e delimitadas pelo caso:

1. Limitação da Revisão de Arquivo Único: Neste sistema, a revisão de arquivo único perdeu classes de defeitos entre documentos por construção.
2. Convergência Não Monotônica: O caminho de convergência observado foi não monotônico, consistente com a hipótese de que edições em cascata e escopos de auditoria em expansão revelam defeitos em ondas, em vez de um declínio linear.
3. Co-evolução do Protocolo: O próprio protocolo de auditoria co-evoluiu com as correções; a versão "travada" fornecida no apêndice é o estado recomendado para replicação.

Os autores afirmam explicitamente que a generalização requer replicação com LLMs dissimilares e revisores humanos para descartar pontos cegos compartilhados (já que a mesma família de LLM autorou e auditou as especificações). Eles não afirmam que a revisão de escopo total de passagem única é universalmente insuficiente, apenas que não foi executada como controle neste estudo e que uma terminação de passagem única teria deixado defeitos descobertos posteriormente sem resolução sob seu protocolo específico. O estudo posiciona as especificações de prompt como artefatos de software que exigem métodos de ciclo de vida e auditoria iterativa, distintos dos testes tradicionais ou do refinamento auto-reflexivo de contexto único.