## The database choice that ages poorly

A company builds one agent for customer support. Armazena as observações em um banco de dados, Postgres, Mongo, Redis, qualquer que a equipe já execute. Meses depois, outra equipe cria uma conta de agente de saúde. Alguém os conecta porque um humano se cansou de copiar e colar contexto entre ferramentas. Essa conexão, uma tabela de banco de dados compartilhada, torna-se um estado compartilhado multiagente por acidente.

Três agentes agora compartilham o estado das contas dos clientes: suporte de entrada, pontuação de integridade e recomendações de renovação.

O agente de suporte atende um cliente frustrado e armazena: “o cliente expressou insatisfação com o preço, considerando alternativas”. O agente de pontuação de saúde lê isso e faz o downgrade da conta. O agente de renovação lê a pontuação rebaixada, gera e envia uma oferta de desconto. Tudo em poucos minutos. Nenhum humano no circuito.

A observação inicial do agente de suporte estava errada. O cliente ficou frustrado com um erro de faturamento, e não de preço. Mas a extração de memória mediada pelo LLM comprimiu a interação em um resumo enganoso, e esse resumo se propagou através do estado compartilhado como verdade fundamental.

Retrieval worked at every step. A falha foi na escrita. Nada no sistema poderia detectar que a observação inicial era infiel à sua fonte, ou traçar a cadeia causal desde a má gravação até a má ação.

## Por que os sistemas de agente único mascaram o problema

Com um agente gravando em um armazenamento de memória, a corrupção na gravação degrada lentamente a qualidade. O agente resume uma observação ligeiramente errada. Ele substitui um atributo de entidade. Ele armazena fatos contraditórios. O sistema ainda funciona. Apenas fica gradualmente menos confiável. A camada de memória nunca é responsabilizada porque o modo de falha parece um problema de LLM.

É aqui que quase todo mundo está hoje. A dor é latente. Ninguém consegue responder a perguntas básicas: o que o agente descobriu, quando, de que fonte, contradisse algo que armazenou na semana passada. Mas o sistema não quebra visivelmente. A confiança se desgasta sutilmente.

## O que muda com vários agentes

Quando o Agente A escreve observações que o Agente B lê e atua, surge uma topologia de falha diferente.

**Amplificação de contradição.** Dois agentes armazenam fatos conflitantes sobre a mesma entidade a partir de interações diferentes. Um terceiro agente chega para agir e vê qualquer fato que a camada de recuperação venha à tona, sem nenhuma base para julgar entre eles. Sem um registro de observação somente anexado com carimbos de data e hora e atribuição de fonte, não há caminho forense para entender a contradição.

**Cascatas de substituição silenciosas.** O Agente A atualiza um registro. O Agente B, operando em uma leitura obsoleta, escreve sua própria atualização que reverte implicitamente a alteração do Agente A. Em um banco de dados mutável, isso é quase indetectável. Em um log somente anexado com observações vinculadas a hash, é estruturalmente impossível.

**Colapso do limite de confiança.** Estado compartilhado significa que cada agente confia nas gravações do outro. Mas os agentes têm capacidades, contextos de prompt e perfis de erro diferentes. Um agente especializado em análise financeira e um agente de suporte de uso geral provavelmente não deveriam ter autoridade de gravação igual sobre o mesmo estado de entidade. Em um banco de dados simples, sem restrições de esquema sobre quem pode escrever o quê, eles o fazem.

## As quatro fases

A indústria está se movendo em um arco previsível.

### 1. "Basta usar Postgres" (ou [basta usar um arquivo markdown](/posts/the-markdown-memory-ceiling))

Manus, Claude Code e OpenClaw usam arquivos de texto simples para memória. Evolução convergente, não um manual compartilhado. Quando uma equipe busca um banco de dados, a memória é fixada em tudo o que já está lá: RAG sobre Postgres com pgvector, Redis para estado de sessão, embeddings em Pinecone. Qualquer um dos caminhos funciona para casos de uso simples. O modelo mental é que os agentes precisam se lembrar de coisas, arquivos ou bancos de dados armazenam coisas, problemas resolvidos.

### 2. Otimização de recuperação

Produtos como Mem0, Zep e MemPalace aceitam que os agentes precisam de uma abstração de memória dedicada, mas enquadram o problema como qualidade de recuperação. Como colocar o contexto certo no prompt no momento certo. Isso resolve um problema que os desenvolvedores já podem sentir: recuperação incorreta, janelas de contexto inchadas, recuperações irrelevantes. Mas esta fase deixa o caminho de gravação não auditado. Quaisquer que sejam os extratos do LLM, são tratados como verdade fundamental.

Esta fase dominará durante os próximos um ou dois anos porque a dor da recuperação é legível. Os desenvolvedores percebem quando o agente esquece ou recupera a coisa errada. A corrupção de gravação é ilegível. O agente age com confiança em situações ruins e ninguém percebe até que as consequências posteriores venham à tona.

### 3. A crise de confiança

Isto acontece quando os agentes passam de assistentes de baixo risco para atores de alto risco, gerenciando dinheiro, tomando decisões de aquisição, lidando com fluxos de trabalho de conformidade, operando de forma autônoma durante dias ou semanas. A pergunta muda de "o agente recuperou a coisa certa?" para "posso provar o que o agente sabia, quando soube e se esse conhecimento era legítimo?"

Falhas de alto perfil em que os agentes agiram no estado de memória corrompido forçarão essa mudança. Os compradores empresariais exigirão trilhas de auditoria. Os reguladores das finanças e da saúde exigirão uma proveniência determinística.

### 4. A bifurcação

A indústria se divide. Caminho A: bancos de dados existentes adicionam primitivas de agente. Postgres obtém extensões para registro de observação e resolução de entidades. Supabase ou PlanetScale fornecem uma camada de produto de “memória de agente”. Isso captura muitos casos de uso em que os requisitos de confiança são moderados.

Caminho B: infraestrutura de estado de agência desenvolvida especificamente para agentes que operam além dos limites de confiança, mantendo um estado autônomo de longa duração ou que necessitam de origem criptográfica. As principais invariantes (resolução de entidade determinística somente anexada, vinculada a hash, restrita por esquema) são compromissos arquitetônicos que não podem ser adaptados de forma confiável como extensões de banco de dados.

Este é o caminho onde os sistemas agentes atingem todo o seu potencial. Agentes que podem confiar em seu próprio estado, traçar seu próprio raciocínio e coordenar-se com outros agentes sem corrupção silenciosa são qualitativamente mais capazes do que agentes executados na memória de melhor esforço.

A integridade de gravação não é um recurso de segurança implementado após o fato. É a base que torna possível a operação autônoma.

## Como os sistemas multiagentes serão realmente construídos

A maioria não será projetada como sistemas multiagentes. Eles vão agregar.

**Hub-and-spoke com um hub humano** é o padrão dominante atual. Um agente primário enfrenta o usuário e delega subtarefas a agentes especializados. O estado compartilhado é a janela de contexto do agente primário. O risco de integridade de gravação é baixo. Mas essa topologia tem um teto rígido: o agente do hub apresenta gargalos e não consegue manter o contexto em fluxos de trabalho de longa duração. Isso mapeia para as fases 1 e 2: "basta usar Postgres" ou uma camada de recuperação funciona bem porque um agente controla o estado.

**Agentes de pipeline** vêm em seguida. Transferências sequenciais em que cada agente processa e enriquece um item de trabalho. Liderar qualificação para pesquisa da empresa, elaboração de divulgação e agendamento de reuniões. A integridade de gravação começa a ser importante aqui. Se o agente de pesquisa armazenar dados incorretos da empresa, todos os agentes posteriores calibrarão incorretamente. É aqui que as equipas começam a passar da fase 2 para a fase 3: a recuperação ainda funciona, mas a crise de confiança está a crescer abaixo da superfície.

**Agentes orientados a eventos com contexto compartilhado** seguem. Vários agentes assinam eventos de um ambiente compartilhado (CRM, base de código, canal de comunicação), mantêm suas próprias perspectivas e gravam observações em um armazenamento comum. Sem orquestrador. Esta é a fase 3 completa: escritas simultâneas de agentes com diferentes estruturas interpretativas, nenhum coordenador para detectar contradições e a integridade da escrita torna-se genuinamente perigosa.

**Agentes autônomos persistentes com estado de longa duração** são o estado final. Agentes funcionando continuamente, mantendo modelos mundiais em evolução, sincronizando periodicamente com outros agentes ou com um armazenamento de verdade compartilhado. As janelas de contexto não podem servir como memória. Esses agentes precisam de armazenamento persistente com garantias reais de integridade. Esta é a fase 4: a bifurcação. Ou sua infraestrutura foi construída para isso ou não.

Uma tensão importante é que muitos desenvolvedores escolhem seu armazenamento nas topologias um e dois, quando o risco de estado compartilhado é leve. Eles escolhem qualquer banco de dados que já possuem e adicionam uma tabela de memórias. No momento em que atingem as topologias três e quatro, os compromissos arquitetônicos estão consolidados. A migração do estado mutável para o estado somente de acréscimo não é uma troca de biblioteca. É uma rearquitetura.

## A superfície de integração que importa

A arquitetura vencedora provavelmente não é “substituir seu banco de dados”, mas “ficar entre seus agentes e seu banco de dados”.

Os agentes escrevem observações em uma camada de integridade de gravação: somente acréscimo, com restrição de esquema e rastreamento de origem. Essa camada gerencia o estado legível pelo agente. O banco de dados existente do desenvolvedor continua sendo o sistema de registro de dados comerciais, registros de clientes, transações e catálogo de produtos. Mas o estado gerado pelo agente, as observações, as inferências, as resoluções das entidades, as decisões vivem em uma camada construída com um propósito.

Na prática, as duas camadas conversam entre si. Um agente lê um registro de cliente do Postgres, executa uma análise e grava suas observações (pontuação de integridade, risco de rotatividade, ação recomendada) na camada de integridade de gravação com uma referência ao registro de origem. Um segundo agente consulta a camada de integridade em busca de todas as observações sobre aquele cliente, obtém um instantâneo consistente com a procedência e age de acordo com ele. Se algo der errado, você rastreia a cadeia: qual agente escreveu o quê, quando, com base em quais dados de origem. O banco de dados de negócios nunca fica poluído com o estado gerado pelo agente, e a camada do agente nunca perde o controle de onde vieram suas observações.

A distinção entre “dados de negócios escritos por humanos” e “estado observacional escrito por agentes” é o enquadramento mais claro da necessidade de uma nova camada de dados. Você não está substituindo o banco de dados deles. Você está adicionando uma camada para uma categoria de dados que não existia antes dos agentes começarem a escrever de forma autônoma.

## O que estou construindo

Isso é o que [Neotoma](https://github.com/markmhendrickson/neotoma) faz. Observações apenas anexadas. Proveniência ligada ao hash. Gravações restritas por esquema. Resolução de entidade determinística. Cada observação que um agente escreve é ​​rastreável, auditável e consistente desde o primeiro dia.

Estou executando minha própria pilha de agentes nisso. Vários agentes (triagem de e-mail, gerenciamento de tarefas, finanças, planejamento de conteúdo), todos escrevendo para a mesma loja. O problema de estado compartilhado multiagente não é hipotético para mim. É o que encontro todas as semanas quando a extração de um agente contradiz a de outro ou quando uma leitura obsoleta produz uma ação posterior em um estado ruim.

O custo de esperar para adotar a integridade de gravação não é uma dívida técnica que você possa pagar mais tarde. É uma lacuna no seu histórico de auditoria. Tudo antes da migração é uma caixa preta. Essa lacuna é permanente.