Sistemas de código com múltiplos agentes de IA não falham necessariamente porque os agentes não conseguem se comunicar. Eles podem falhar porque compromissos importantes feitos na conversa não têm onde viver depois. É essa a tese central de um experimento publicado no Towards Data Science, que propõe um “Commitment Ledger” — um livro-razão de compromissos — construído apenas com a biblioteca padrão do Python.
O ponto de partida: CooperBench
A motivação vem de um benchmark recente de Stanford e SAP Labs, o CooperBench, que testa se agentes de código conseguem trabalhar como companheiros de equipe. O resultado chamou atenção: os pares que cooperavam não tiveram desempenho consistentemente melhor — em alguns casos, foram piores do que um único agente fazendo o mesmo trabalho. A análise apontou mensagens vagas ou mal cronometradas, suposições erradas sobre o que o outro agente estava fazendo e agentes se afastando de compromissos já assumidos.
Como o ledger funciona
O autor, Emmimal P Alexander, isolou um problema específico: um compromisso existe na conversa, mas outro agente não tem estado persistente para consultar antes de pegar o mesmo trabalho. A solução é um sistema determinístico, sem nenhuma chamada de modelo, dividido em três partes.
O detector de compromissos reconhece frases como “vou implementar repository/items.py” a partir de quatro formas de frase, uma lista fixa de 13 verbos e seis padrões de objeto. Em um conjunto de teste rotulado à mão com 150 linhas, o detector acertou todas: 100% de precisão e 100% de revocação. O ledger guarda um histórico imutável de eventos (COMMITTED, STARTED, IMPLEMENTED, TESTED, REPORTED, VERIFIED), com ramificações de falha para CONFLICTED e ABANDONED — de modo que um erro posterior de um agente não apaga o progresso válido de outro.
O que mudou no teste
No caso de teste com dois agentes e um catálogo de itens sem donos pré-atribuídos, a comparação entre “só chat” e “chat + ledger” foi reveladora. Conflitos caíram de 1 para 0, dependências não notificadas de 1 para 0 e retrabalho de 1 para 0. Mas dois números não mudaram: compromissos esquecidos (1 em ambos) e trabalho não verificado (1 em ambos). Ou seja, o ledger melhorou a coordenação, mas não força um agente a concluir o trabalho nem verifica se o que foi relatado é verdade.
A lição que importa
O próprio autor é o primeiro a ressalvar que se trata de um exemplo trabalhado, não de um benchmark estatístico. Ainda assim, a conclusão é útil para quem constrói sistemas multiagentes: tornar compromissos explícitos resolve falhas de estado compartilhado, mas não resolve execução nem verificação. Em um deploy real, ele mudaria três coisas: o estado VERIFIED viria de uma checagem externa (teste real ou revisão de diff), compromissos parados ganhariam follow-up automático, e o mapa de dependências seria extraído do código em vez de escrito à mão.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
