Um lugar onde um fato fica estabelecido

Quando vários agentes trabalham com os mesmos fatos, esses fatos mudam, e os agentes não ficam todos sabendo da mudança ao mesmo tempo. Uma data de vencimento mostra o problema com clareza.

Suponha que a fatura INV-2041 diga que o pagamento vence em 22 de outubro e que um email posterior do fornecedor altere o vencimento para 29 de outubro. Um agente lê a fatura, outro lê o email, e um terceiro prepara os pagamentos da semana com o que conseguir encontrar. O primeiro responde 22 de outubro, o segundo responde 29 de outubro, e o terceiro responde com a data que tiver encontrado primeiro. Nada nessa organização diz qual data vale, então a pessoa que coordena os agentes precisa conferir.

Inventei este exemplo específico da fatura, mas a organização por trás dele é real. Uso agentes em três ferramentas com uma única instância do Neotoma. Um processo que consulta o correio guarda as mensagens recebidas com suas fontes e transforma em tarefas as que exigem ação; sessões no Claude Code, Codex e Cursor assumem as mesmas tarefas e planos. Essa configuração e meu trabalho no Neotoma como um sistema de registro abrangente são a origem deste ensaio.

A recordação serve para outra tarefa

A recuperação de informação encontra material que parece relacionado com uma pergunta. Um índice vetorial ou um longo histórico de conversa faz isso bem e, para muitas tarefas, basta. Mas não resolve qual fato está em vigor. Pergunte pela data de vencimento e a recuperação devolve a fatura e o email ordenados pela semelhança com a pergunta, não por qual deles está atualizado.

Mais ferramentas e ambientes de agentes tornam isso mais difícil. Um agente guarda notas num ficheiro Markdown, outro guarda o que aprendeu no seu produto de chat, e um terceiro lê uma pasta partilhada. Cada cópia estava correta quando foi escrita. Quando o fato muda, as cópias mudam em momentos diferentes, ou não mudam, e nenhum agente consegue perguntar qual delas prevalece, porque não existe um lugar onde essa pergunta tenha resposta. O sistema de registro tem de ficar fora de qualquer um deles, num lugar a que todos possam aceder.

No início deste ano, chamei ao Neotoma uma camada de memória e uma camada de verdade. Deixei de o fazer porque passei a considerar memória uma categoria errada para o Neotoma: é confusa, e as pessoas continuavam a compará-lo com produtos de memória. O que preciso que um agente guarde são dados exatos sobre muitos tipos de coisas, numa forma auditável; o nome simples para o lugar que os guarda é sistema de registro.

É isso que quero dizer com sistema de registro: ele indica o que está em vigor, de onde veio e o que substituiu. A pesquisa por semelhança não pode responder a essas perguntas, porque a semelhança nada diz sobre o tempo ou a fonte.

O que o Neotoma faz hoje

Desenvolvo o Neotoma, o sistema de registro para agentes de IA. É software de código aberto sob a licença MIT e funciona localmente, num diretório de dados à sua escolha. O que se segue descreve o que o pacote publicado (0.25.0 no npm) faz hoje.

Cada escrita é guardada como uma nova observação, ligada à fonte de onde veio. Um novo valor é acrescentado ao lado do antigo em vez de o substituir. O Neotoma pode guardar o PDF ou email original juntamente com as entidades estruturadas derivadas dele, mantendo as observações ligadas à sua fonte.

As observações pertencem a entidades. O identificador de uma entidade deriva do tipo de entidade e dos seus campos de identificação. Na mesma instância e sob as mesmas regras de identidade, os mesmos valores de identificação produzem deterministamente o mesmo identificador, pelo que dois agentes que guardem a mesma fatura escrevem na mesma entidade.

As entidades também podem ser ligadas entre si: a fatura ao seu fornecedor, ou uma tarefa de acompanhamento à fatura a que se refere. Um agente cria essas relações explicitamente. Elas descrevem como os registros se encaixam, enquanto as ligações às fontes mostram o PDF ou email por trás de uma observação.

O Neotoma aplica automaticamente a regra de fusão do esquema para cada campo para calcular o seu valor em vigor a partir das observações. Na maioria dos campos, prevalece a observação mais recente. Com as mesmas observações e as mesmas regras de fusão, a redução produz o mesmo retrato do estado, sem pedir a um modelo que escolha de novo a cada leitura.

Cada campo em vigor identifica a observação que o definiu, e uma observação guardada identifica a sua fonte. É um rastro até à evidência, não uma prova de que um agente a leu corretamente. Uma correção é mais uma observação, não uma edição, e o valor anterior continua listado. Também é possível ler uma entidade tal como o Neotoma a tinha registrado num momento anterior.

Voltemos à fatura. As escritas dos dois agentes chegam a uma única entidade. A data de vencimento agora é 29 de outubro e identifica a observação proveniente do email. O valor a pagar continua a identificar a primeira observação, porque nada o alterou. O agente de pagamentos lê 29 de outubro, e a observação de 22 de outubro permanece listada com a sua fonte.

Os agentes acedem ao Neotoma por um servidor MCP, uma API REST e uma CLI. O guia de instalação explica como ligar ferramentas e ambientes de agentes compatíveis. Aponte cada ferramenta para a mesma instância e o mesmo perfil de dados, ou para a mesma entrada MCP, para partilhar registros; entradas separadas podem usar bases de dados separadas.

As pessoas podem consultar os seus registros na aplicação Neotoma incluída no pacote.

Uma solicitação assinada admitida pode estabelecer uma identidade de agente verificada. Concessões ativas e com âmbito delimitado determinam as ações permitidas; uma assinatura, por si só, não concede permissão.

Para onde isto caminha

Até aqui descrevi um sistema de registro que estabelece os fatos em vigor para os agentes. A direção é um sistema de registro mantido em conjunto por pessoas e agentes, onde qualquer pessoa possa perguntar qual valor está em vigor, que fonte o introduziu, se foi observado, inferido ou decidido, quem tinha autoridade para o corrigir e quais agentes dependeram da versão anterior. As capacidades de governança planejadas vão além da identidade assinada, das concessões delimitadas e da aplicação que existem hoje:

• Dar a cada domínio um responsável claro, com autoridade para corrigir os seus registros delimitada a esse domínio.
• Representar explicitamente afirmações concorrentes, disputas não resolvidas e posições oficiais.
• Mostrar por que razão um valor prevalece, a autoridade que o sustenta e o que uma mudança afetaria.

O Ateles prolonga essa direção no plano operacional. No desenho dos adaptadores do Ateles, os adaptadores trazem informação de sistemas como correio, calendários e plataformas de código para o Neotoma e levam ações autorizadas de volta a esses sistemas. O Neotoma guarda os registros; as ferramentas ligadas executam o trabalho.

A visão completa, com o estado atual de cada parte, está no README.

Um sistema de registro, não de recuperação

A resposta não é um índice melhor. A recuperação ajuda um agente a encontrar o que foi dito. Um sistema de registro diz-lhe o que está em vigor. Os agentes que trabalham em várias ferramentas precisam da segunda função, num lugar a que todos possam aceder; e um sistema de registro só ajuda quando os agentes escrevem nele e leem dele.

Se utiliza agentes em mais de uma ferramenta ou ambiente de execução, comece por um fluxo de trabalho cujos fatos e entidades estejam relacionados:

npm install -g neotoma
neotoma init
neotoma setup --tool claude-code

Use a opção de configuração para a sua ferramenta ou ambiente de execução; o guia de instalação cobre as outras integrações compatíveis. Depois, guarde os fatos e entidades relacionados do fluxo a partir de um agente e leia-os a partir de outro ligado à mesma instância configurada e ao mesmo perfil de dados ou entrada MCP.

O guia de instalação está em neotoma.io/install. O código e o rastreador de problemas estão no GitHub, em github.com/markmhendrickson/neotoma.