Quando dois agents discordam sobre um fato

Um agent lê o contrato e registra que o preço de renovação é um número. Um segundo agent lê a thread de email onde esse preço foi renegociado semana passada e registra um diferente. Os dois estão agora na memória da empresa. Os dois parecem igualmente verdadeiros. Da próxima vez que alguém, uma pessoa ou um terceiro agent, perguntar “qual é o preço de renovação?”, o sistema tem duas respostas e nenhuma ideia de qual dar.

Isso não é um bug em nenhum dos agents. Os dois fizeram seu trabalho corretamente. O bug é que ninguém decidiu o que acontece quando duas leituras corretas do mundo apontam em direções opostas.

Verdade num sistema multi-agent é um protocolo, não uma suposição. O trabalho inteiro é decidir como o sistema resolve um conflito antes mesmo de ter um, e “escolha o que foi escrito por último” não é uma decisão, é uma moeda jogada vestindo um timestamp.

Este post é sobre esse protocolo: por que discordância é o estado normal, não o quebrado, e o que uma regra de reconciliação de fato tem que pesar.

A versão ingênua: a última escrita vence

Na primeira vez que você constrói memória compartilhada para uma frota de agents, você constrói a coisa mais simples que poderia funcionar. Cada agent escreve o que aprende num único store. Quando duas escritas tocam o mesmo fato, a mais nova sobrescreve a mais velha. A última escrita vence.

Funciona lindamente até o exato momento em que dois agents estão fazendo trabalho real ao mesmo tempo.

Aqui está a falha, concretamente. Imagine um agent lendo um contrato assinado, uma leitura lenta e cuidadosa de um documento autoritativo, que termina às 9h02 e registra o preço de renovação. Enquanto isso, um agent mais rápido passa os olhos por um chat interno onde alguém chutou o preço de memória, e ele termina às 9h04. A última-escrita-vence agora acredita no chute, porque o chute chegou dois minutos depois. O sistema não escolheu a fonte melhor. Escolheu o relógio mais tarde.

A última escrita vence não resolve conflitos. Ela os esconde sob um timestamp.

E o timestamp é o pior critério de desempate possível, porque recência e confiabilidade são descorrelacionadas. A coisa mais recente que um agent viu é frequentemente a menos confiável, um aparte no Slack, uma página cacheada e desatualizada, um rascunho que alguém nunca enviou. Quando você nota que o número errado está na memória, três outros agents já o leram, agiram sobre ele e escreveram suas conclusões em cima. O erro não fica parado. Ele se propaga.

Então o store ingênuo te dá uma memória que está confiante e silenciosamente errada, e fica mais errada quanto mais ocupado você está. O conserto não é um relógio melhor. O conserto é parar de fingir que o relógio algum dia foi a resposta.

Por que discordância é o estado normal

Antes de construir a regra, temos que corrigir o instinto de que conflito é raro. Não é. Num sistema onde muitos agents leem muitas fontes, conflito é o output esperado, e um sistema surpreendido por ele é um sistema que vai perder para ele.

Pense de onde os fatos vêm. O mesmo fato, um preço, uma data, o cargo de uma pessoa, um status, vive num contrato, num email, num chat, num campo de CRM, numa transcrição de reunião e na cabeça de três pessoas. Essas fontes nunca foram consistentes umas com as outras. Elas discordam agora mesmo, na sua empresa, antes de qualquer agent tocá-las. O CRM diz uma coisa porque ninguém o atualizou. O email diz outra porque foi ali que a decisão real aconteceu. Os agents não criaram a discordância. Eles a revelaram.

Um único knowledge-worker humano resolve esses conflitos constantemente sem nomeá-lo. Você lê o chat, depois lembra “mas o contrato diz o contrário”, e confia no contrato. Você ouve duas versões de uma data e confia na da pessoa que é dona do calendário. Você está rodando uma regra de reconciliação na sua cabeça, autoridade da fonte, confiança, recência, tudo pesado numa fração de segundo, e a faz há tanto tempo que esqueceu que é uma habilidade.

O store ingênuo não tem nada dessa habilidade. Ele trata toda escrita como igualmente verdadeira e mantém a última. Então o primeiro trabalho de verdade não é armazenar fatos. É dar ao sistema o julgamento que um humano aplica de graça: quando duas verdades colidem, qual vence, e por quê.

A regra de reconciliação tem três inputs, não um

A última-escrita-vence falha porque usa exatamente um input, tempo, e o usa como a resposta inteira. Uma regra de reconciliação de verdade usa tempo como um input entre vários, e nunca o decisivo por si só.

Três inputs carregam a maior parte do peso.

Autoridade da fonte, de onde veio o fato? Um contrato assinado supera um email encaminhado. Um sistema de registro supera um chute de corredor. Um documento primário supera um resumo dele. Esse é o input em que humanos mais se apoiam e o que a última-escrita-vence ignora completamente. A primeira pergunta nunca é “quando isso foi escrito?”. É “isto é uma leitura de quê?”. Um fato herda a confiabilidade da sua fonte, e essa ordenação é algo que você pode decidir de antemão: contratos acima de campos de CRM acima de chat acima da própria inferência de um agent.

Confiança, quão certo o agent estava quando escreveu isso? Nem toda leitura é igual, mesmo da mesma fonte. Um agent que extraiu uma data de uma linha limpa e explícita (“renova no dia 14”) deveria escrevê-la com alta confiança. Um agent que inferiu uma data de um contexto que teve que costurar deveria escrevê-la com baixa confiança e dizer isso. Quando dois fatos colidem, o que o escritor tinha certeza vence o que ele meio-chutou, mas só se o agent registrou sua confiança em primeiro lugar. Um fato sem confiança anexada é um fato que você não consegue reconciliar.

Recência, qual leitura é sobre o estado mais atual do mundo? Recência não é inútil. Ela só é a última na fila, não a primeira. Quando dois fatos vêm de fontes de igual autoridade e igual confiança, dois emails, ambos autoritativos, ambos certos, então sim, o mais novo geralmente reflete a verdade mais atual. Recência é o desempate depois que os outros dois falaram, não o argumento de abertura. O preço renegociado vence o preço original porque a renegociação veio depois E veio de uma fonte igualmente autoritativa, não por causa do relógio sozinho.

A regra, dita claramente: ordene por autoridade da fonte primeiro, desempate por confiança, desempate o restante por recência. Três botões, aplicados em ordem. A última-escrita-vence era essa mesma regra com os dois primeiros botões arrancados.

Há uma quarta coisa que a regra tem que fazer, e é a que as pessoas esquecem: quando os inputs genuinamente empatam, igual autoridade, igual confiança, valores conflitantes, a regra não deve escolher. Ela deve marcar o fato como disputado e revelá-lo, porque uma resposta confiante e errada é pior que um honesto “essas duas fontes discordam, qual está certa?”. A disposição de dizer eu tenho duas respostas e não consigo escolher é parte do protocolo, não uma falha dele.

A nossa: o conflito vira um evento de primeira classe

Aqui está a virada que faz a coisa toda funcionar. No store ingênuo, um conflito é um acidente que sobrescreve silenciosamente. Num sistema de verdade, um conflito é um evento, algo que a camada de memória nota, registra e resolve de propósito, deixando um rastro do porquê.

Quando um novo fato chega contradizendo um já na memória, o sistema não só compara timestamps e segue em frente. Ele roda a regra. Checa a autoridade de ambas as fontes, a confiança de ambas as escritas, e só então a recência. Mantém o vencedor como a resposta viva, e mantém o perdedor também, não como verdade, mas como história: aqui está o que costumávamos acreditar, aqui está a fonte que derrubou, aqui está a regra que decidiu. O fato que perdeu a discussão não é deletado. Ele é o recibo que prova que o sistema não jogou uma moeda.

Esse rastro é o que transforma memória de um chute em algo em que você pode confiar. Quando um terceiro agent lê “o preço de renovação é X”, não está lendo um valor que por acaso foi escrito por último. Está lendo um valor que venceu, que bateu uma leitura concorrente por uma regra declarada, com o perdedor ainda em arquivo. Se a resposta acaba sendo errada, você não dá de ombros para uma caixa-preta. Você lê o rastro, encontra o botão que foi mal ajustado, talvez uma fonte ordenada alto demais, talvez um agent confiante demais, e conserta a regra, não só o um fato.

E o caso disputado ganha seu sustento. Digamos que duas fontes igualmente autoritativas se contradigam frontalmente e a regra honestamente não consiga escolher. O sistema não finge. Ele marca o fato como disputado e o levanta, para uma pessoa, ou para um agent cujo trabalho é ir achar o desempate lendo mais uma fonte. Uma discordância que o sistema sabe que tem é uma coisa pequena e consertável. Uma discordância que ele não sabe que tem é o número errado se propagando por toda decisão lá embaixo.

O store ingênuo otimiza para nunca ter que pensar sobre conflito. O sistema de verdade otimiza para lidar bem com conflito, porque sabe que o conflito está vindo.

A virada: toda empresa já é um motor de reconciliação

Dê um passo atrás dos agents e você vai reconhecer esse problema, porque sua empresa vem rodando esse protocolo na mão há anos.

Em algum lugar da sua organização, duas pessoas acreditam em duas coisas diferentes sobre o mesmo fato agora mesmo. Uma tem o número do último trimestre, a outra tem o deste trimestre. Uma leu o contrato, a outra lembra da call. Na maior parte do tempo não explode, porque eventualmente alguém com contexto e autoridade suficientes diz “não, este é o número real, eis o porquê”, e todos atualizam. Essa pessoa é a sua regra de reconciliação. Ela está pesando fonte, certeza e recência na cabeça, e a empresa roda no julgamento dela.

O problema é que esse julgamento vive em poucas pessoas sobrecarregadas, dispara só quando um conflito por acaso aparece, e não deixa rastro quando dispara. Quando essa pessoa está ocupada, o número errado vence por padrão, exatamente como a última-escrita-vence. Quando ela vai embora, a regra vai junto. A habilidade mais importante da empresa, decidir em qual versão de um fato acreditar, é indocumentada, aplicada de modo desigual, e invisível até falhar.

O que estamos construindo é uma memória que roda esse julgamento à vista de todos, toda vez, com as razões escritas. Não um agent que nunca erra, esse não existe. Um sistema onde, quando dois agents discordam sobre um fato, há uma regra que decide, um registro do porquê decidiu, e um sinal honesto quando não consegue. Verdade num sistema multi-agent é um protocolo, não uma suposição, e as empresas que vencem a próxima década serão as que escreveram o protocolo em vez de deixá-lo na cabeça de uma pessoa cansada.

---

Isso é parte do que estamos construindo na Apollo Space: um cérebro da empresa onde muitos agents leem muitas fontes, discordam constantemente, e resolvem por uma regra que você pode inspecionar, não uma moeda jogada vestindo um timestamp. Se sua empresa já tomou uma decisão sobre um número que acabou sendo a versão errada, você já sabe que o conflito nunca foi o perigo. O silêncio em torno dele foi.