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](https://markmhendrickson.com/posts/what-my-agentic-stack-actually-does) com uma única instância do [Neotoma](https://neotoma.io/). 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](https://markmhendrickson.com/posts/the-swarm-that-runs-my-work). Essa configuração e meu trabalho no Neotoma como um sistema de registro abrangente são a origem deste ensaio.

![Um documento e um envelope, cada um ligado a uma ficha de fatos diferente](/images/posts/neotoma-paper/observation.svg "paper|Exemplo fictício · INV-2041|Duas fontes dizem coisas diferentes sobre uma fatura: o PDF indica vencimento em 22 de outubro; um email posterior indica 29 de outubro.")

## 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](https://markmhendrickson.com/posts/agentic-search-and-the-truth-layer). 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](https://markmhendrickson.com/posts/the-markdown-memory-ceiling), 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](https://markmhendrickson.com/posts/truth-layer-agent-memory). Deixei de o fazer porque passei a considerar memória uma categoria errada para o Neotoma: é [confusa](https://markmhendrickson.com/posts/your-ai-remembers-your-vibe-but-not-your-work), 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.

> **A recuperação e o registro**
>
> **As ferramentas de memória e recuperação ajudam um agente a guardar e encontrar contexto. Um sistema de registro assume outra tarefa: calcula o valor em vigor a partir de observações aceitas e mantém um caminho de volta às evidências de cada campo. As duas funções sobrepõem-se, e um produto pode abranger mais de uma.**

## 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](https://github.com/markmhendrickson/neotoma/blob/v0.25.0/docs/developer/source_storage_by_reference.md) 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.

![Uma fatura e um email separados, ligados por linhas finas a uma ficha de registro assinalada](/images/posts/neotoma-paper/invoice-example.svg "paper|O registro em vigor · INV-2041|A data de vencimento agora é 29 de outubro. O campo alterado aponta para a observação posterior. O valor continua a vir da primeira observação. Ambas as observações permanecem no registro.")

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](https://markmhendrickson.com/posts/know-which-of-your-agents-wrote-what/) 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](https://github.com/markmhendrickson/ateles/blob/a3e4d9ed2c33ac867bb67447221d559cbe8c5810/docs/foundation/adapters.md#L14-L22), 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](https://github.com/markmhendrickson/neotoma#vision-and-execution-status).

![Responsabilidade pelo domínio: um titular autorizado alcança um de dois compartimentos delimitados](/images/posts/neotoma-paper/vision-domain.svg "paper|Responsabilidade pelo domínio|A responsabilidade pelo domínio deixará claro quem pode corrigir cada parte delimitada do sistema de registro.")
![Acompanhamento de posições: duas afirmações preservadas ligam-se a um dossiê onde uma posição está assinalada como selecionada](/images/posts/neotoma-paper/vision-positions.svg "paper|Acompanhamento de posições|O acompanhamento de posições preservará afirmações concorrentes e permitirá inspecionar uma posição explícita.")
![Explicações: ao levantar um campo em vigor, revelam-se a sua base e um conjunto delimitado de efeitos](/images/posts/neotoma-paper/vision-explanation.svg "paper|Explicações|As explicações mostrarão por que razão um valor prevalece, a autoridade que o sustenta e quais valores ligados uma mudança poderá afetar.")

## 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](https://markmhendrickson.com/posts/the-spine-of-the-loop). 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](https://neotoma.io/install?utm_source=site&utm_medium=blog&utm_campaign=essay-system-of-record). O código e o rastreador de problemas estão no GitHub, em [github.com/markmhendrickson/neotoma](https://github.com/markmhendrickson/neotoma).

> **A ambição**
>
> **O Neotoma é o sistema de registro para agentes de IA. A ambição é dar às pessoas e aos agentes uma compreensão partilhada que possam examinar e governar: o que se sabe, por que se acredita nisso, onde discordam e quem tem autoridade para mudar. Essa compreensão deve sobreviver a qualquer modelo, ferramenta ou aplicação em particular.**