Por que agentes de IA não devem ser donos do contexto, e como uma arquitetura federada onde a memória é passiva e o Git é a espinha fecha os gaps que nenhuma ferramenta resolveu ainda.
O problema de memória em agentes de IA não é falta de ferramentas. É ausência de separação entre quem guarda o contexto e quem o executa. As soluções atuais centralizam memória no agente, criando dependência de ferramenta, contaminação semântica entre domínios e degradação inevitável. Este paper propõe memória federada: uma arquitetura onde o contexto pertence ao usuário, domínios são isolados e a memória é passiva e soberana. Os agentes de código são clientes intercambiáveis que leem e escrevem guiados por um contrato; nenhum é o núcleo. O Git é a espinha que unifica versionamento e sincronização. A governança opera em dois modos declarados: cooperativo (contrato, o piso recomendado) e adversarial (enforcement por isolamento de sistema operacional, abaixo do agente). A captura é automática via hooks do agente; a classificação por confidence e risk determina o que se promove sozinho e o que exige decisão humana. A implementação de referência é um vault Markdown versionado em Git, com Context Packs como unidade mínima de contexto e o filesystem como caminho de acesso, evoluindo para MCP e Graphiti sob demanda.
Toda ferramenta de IA parece brilhante nos primeiros minutos. Ela entende o pedido, produz resultado relevante, e por um momento parece que você finalmente tem um colaborador que acompanha o raciocínio. O problema aparece na segunda sessão. Ou na décima. A ferramenta esquece o que foi decidido, mistura contexto de projetos distintos, repete perguntas que já foram respondidas, e precisa ser reeducada continuamente.
Isso não é bug. É consequência de uma escolha arquitetural: a memória, quando existe, pertence ao agente. Ela vive dentro da ferramenta, no formato da ferramenta, acessível apenas pela ferramenta. Quando você troca de ferramenta, perde a memória. Quando a ferramenta atualiza, a memória degrada. Quando você usa duas ferramentas em paralelo, cada uma tem uma versão diferente da realidade.
A reação natural é tentar concentrar tudo em um lugar: um "super cérebro", um arquivo de contexto enorme, um sistema centralizado que o agente lê inteiro antes de responder. No começo, isso parece resolver. Com o tempo, o sistema degrada de outra forma: uma tarefa de marketing puxa convenções de código; um projeto antigo contamina um projeto novo; memórias de meses atrás entram como se ainda fossem válidas. O agente sabe demais e, justamente por isso, começa a errar de formas mais sofisticadas.
O campo ainda não tem uma resposta estabelecida para isso. Ferramentas de memória existem, Mem0, Zep, Letta, sistemas nativos como Claude Code e Cursor, mas todas partem do mesmo pressuposto: a memória é um componente interno do sistema de agência. O agente gerencia a memória. O agente decide o que guardar. O agente decide o que trazer para o contexto.
Este paper argumenta que esse pressuposto é o problema, não a solução. E que a saída não é um componente ativo que decide pelo agente: é separar a memória do executor. O contexto vive em arquivos passivos, versionados e auditáveis, fora de qualquer ferramenta. O agente puxa o que precisa, guiado por um contrato explícito. As seções 03 e 05 desenvolvem essa separação.
As soluções existentes são tecnicamente sofisticadas. Usam embeddings vetoriais, grafos de conhecimento, compressão de contexto, retrieval semântico. O problema não é a tecnologia. É o pressuposto arquitetural que governa onde a memória mora e quem a controla.
Claude Code tem CLAUDE.md e um sistema de memória local. Cursor tem regras de projeto. Windsurf tem memórias internas do Cascade. Cada implementação funciona bem dentro da ferramenta que a criou, e falha completamente fora dela. Se você usa Claude Code de manhã e Cursor à tarde para o mesmo projeto, as duas têm memórias diferentes, possivelmente conflitantes, sem mecanismo de sincronização ou governança. A memória pertence à ferramenta, não ao projeto, não ao usuário. Isso vale até para um agente que se pretendia usar como base da arquitetura: o Hermes mantém memória própria (SQLite, MEMORY.md), que compete com o vault federado em vez de servi-lo. Memória nativa, por melhor que seja, puxa o contexto de volta para dentro da ferramenta.
Mem0, Zep e similares resolvem portabilidade parcialmente: a memória vive em um serviço externo que múltiplas ferramentas consultam. Mas introduzem três novos problemas. Primeiro, dependência de infraestrutura externa, a memória está agora na nuvem de outra empresa. Segundo, ausência de governança explícita, o que entra é decidido automaticamente, sem aprovação humana, e hipóteses viram fatos permanentes. Terceiro, ausência de isolamento semântico, toda a memória vive em um espaço vetorial único, e projetos distintos contaminam uns aos outros por proximidade semântica.
Graphiti (Zep) e sistemas similares adicionam dimensão temporal e relacional. São tecnicamente mais ricos, mas sofrem do mesmo problema de governança: quem decide o que entra no grafo? Com que critério uma informação de conversa vira um nó persistente? Automação sem curadoria produz grafos que crescem, mas não necessariamente melhoram.
Em todas as abordagens existentes, a memória é um componente interno do sistema de agência. O agente guarda o contexto e o mesmo agente o executa. Essa concentração é a raiz do problema, não uma propriedade inevitável da arquitetura.
| Solução | Portabilidade | Isolamento | Governança | Soberania | Compartilhamento entre agentes |
|---|---|---|---|---|---|
| Memória nativa (Claude Code, Cursor) | Nenhuma | Parcial | Nenhuma | Ferramenta | Não disponível por design |
| Mem0 / Zep | Parcial | Nenhuma | Automática | Serviço externo | Não disponível por design |
| Graphiti | Parcial | Parcial | Limitada | Serviço externo | Não disponível por design |
| Sistemas centralizadores / Life OS | Presa ao app | Nenhuma | UI-driven | Aplicativo | Não disponível por design |
| Memória Federada (v3.0) | Total | Por domínio | Proporcional ao risco (automática para baixo risco, humana para hipóteses e alto risco) | Usuário | Via vault compartilhado (mente de colmeia: estrutura pronta, escala em roadmap) |
Antes de descrever o erro, separe três camadas que leitores confundem o tempo todo. Confundi-las é a raiz do problema:
O erro das abordagens atuais é colocar a memória dentro do agente, fundindo duas funções que deveriam ser separadas: guardar o contexto e executar com base nele. Quando as duas vivem no mesmo componente, qualquer falha em uma contamina a outra.
Um agente que guarda a própria memória tem incentivo estrutural para guardar demais: mais contexto parece mais seguro. Um agente que executa com base em memória que ele mesmo governa não tem mecanismo de auditoria: erros de memória viram erros de execução silenciosos. E como a memória morre com a ferramenta, o contexto fica refém de quem o executa.
Sistemas de software maduros resolveram isso há décadas com separação de responsabilidades. Bancos de dados não executam lógica de negócio. Servidores de aplicação não gerenciam persistência diretamente. O dado vive fora do processo que o consome, versionado e auditável. A arquitetura de agentes de IA ainda não internalizou esse princípio.
E o roteamento? Na v1.0 deste paper, a tentação foi tratar o roteamento como uma terceira função: um componente ativo e central que decidia o que o agente lê. Não é. O roteamento de leitura é o próprio agente puxando o que precisa, guiado pelo contrato e por arquivos estáticos versionados. Não há roteador central, e não precisa haver. O que dá auditoria e correção não é um roteador ativo, é a memória viver fora do agente, em arquivos versionados que qualquer cliente lê e qualquer humano inspeciona.
Memória federada é uma arquitetura onde o contexto pertence ao usuário, domínios são isolados semanticamente, o roteamento é explícito e governado, e agentes são consumidores temporários de contexto, não donos dele.
Soberania do usuário. A base pertence ao usuário. Agentes entram e saem; o contexto continua portátil, legível por humanos e versionável. Nenhuma ferramenta deve ser pré-requisito para acessar a própria memória.
Isolamento por domínio. Contextos de domínios distintos, marketing, engenharia, escrita, pesquisa, não devem compartilhar o mesmo espaço semântico. Contaminação entre domínios é prevenida por estrutura, não por instrução ao agente.
Contrato neutro de consumo. Um arquivo de contrato central descreve como qualquer agente deve consumir a memória. Adaptadores específicos por ferramenta traduzem esse contrato, mas não o substituem. O contrato tem hierarquia: regras da empresa e do dev vivem em 00-global/RULES.md e valem para todos os projetos; quando um projeto precisa sair de uma regra, registra um override em 70-decisions/ com motivo, responsável e data. Override aprovado tem precedência, e o desvio fica rastreável.
Contexto mínimo suficiente. O agente recebe o contexto necessário para a tarefa em execução, não o histórico completo. Context Packs são a unidade de entrega: pacotes enxutos, orientados à tarefa, com escopo explícito do que usar e do que evitar.
Humano como auditor de última instância. Captura é automática via hooks do agente. Classificação é responsabilidade do agente (confidence + risk). Aprovação é proporcional ao risco: entradas verificadas de baixo risco promovem-se automaticamente com TTL; hipóteses e alto risco exigem decisão humana explícita. O humano não é gargalo de captura, é filtro de qualidade.
A v1.0 enunciou esses cinco princípios e parou. A prática mostrou três gaps que precisavam ser fechados antes da arquitetura ser robusta o suficiente para ser adotada por terceiros.
Context Packs eram entregues, agentes os consumiam, e ninguém media se o pacote tinha sido útil. Packs ruins permaneciam em uso indefinidamente porque não havia mecanismo de rejeição. A solução é estrutural, não cultural: cada pack ganha um campo Validation: que documenta como o uso é registrado, qual o gatilho automático de revisão (três marcações ruins consecutivas) e como o humano marca um pack como obsoleto. Sem feedback, não há ciclo de melhoria. Com feedback estruturado, packs ruins têm meia-vida finita.
Quando duas notas afirmam coisas conflitantes, o que vence? Na v1.0, a resposta era implícita ("quem revisou mais recentemente"), e portanto não-determinística, diferentes agentes chegavam a respostas diferentes. A v2.0 estabelece a regra explícita: vence a entrada mais recente com status: approved. Entradas com status: superseded permanecem no histórico, mas são ignoradas em runtime. Timestamp sozinho não decide, o status é obrigatório. Na ausência de status, o agente deve perguntar ao humano, não chutar.
O princípio de aprovação humana funciona quando o humano está na frente da tela. O problema começa quando o agente roda em modo automático: agendado, headless, em CI. A resposta da v3 não é um núcleo que medeia chamadas, porque esse núcleo não existe. São dois modos declarados. No modo cooperativo, que é o padrão, a regra vive no contrato e na estrutura: leitura liberada em todo o vault, escrita permanente fora de /90-inbox/ convertida em sugestão. O agente coopera porque o contrato pede, e a captura por hooks registra o que importa. No modo adversarial, contra um agente que decida ignorar o contrato, nenhum componente do lado do agente segura a escrita. O enforcement vem de baixo: isolamento de sistema operacional (seção 05).
A v2 descreveu o Hermes como um núcleo ativo que mediava o acesso ao contexto, aplicava política e resolvia conflito. Teste de campo e a documentação oficial do Hermes mostraram que esse componente não existe como descrito: o Hermes é um agente de código completo, com memória própria, não um porteiro que medeia outros agentes. A caracterização estava errada. Esta seção a substitui.
Antes da correção, é preciso separar três camadas que leitores confundem o tempo todo, e cuja confusão é o erro arquitetural da seção 03:
A correção é simples. A memória federada é passiva e soberana: um conjunto de arquivos Markdown versionados. Ela não roteia, não aplica política, não medeia nada. Os agentes de código são clientes intercambiáveis que leem e escrevem nesse vault guiados por um contrato (AGENT.md) e pela estrutura de pastas. O Hermes é um deles. Nenhum é o núcleo.
As quatro funções que a v2 atribuía a um núcleo continuam existindo, mas em outro lugar:
status: approved vence superseded (seção 04) mora nos próprios arquivos. Qualquer agente que leia o vault aplica a mesma regra, porque ela está nos dados, não num componente.hermes.policy.yml descrito na v2 não existe no Hermes real.O que sustenta a arquitetura é o Git. O vault é um repositório Git. O agente trabalha num clone: lê com pull, escreve com commit e push. Numa peça só, o Git entrega sincronização entre máquinas, versionamento, autoria, diff e rollback, com um mecanismo aberto e neutro que não fere a soberania nem amarra a um fornecedor.
A arquitetura cresce por degraus, sob dor, não por padrão:
Subir de degrau dá escala e busca. Não dá disciplina de escrita de graça: isso é sempre OS ou código próprio, em qualquer degrau.
Daí o modelo de ameaça, declarado abertamente:
/90-inbox/, ou usuário separado sem escrita nas pastas protegidas. Nunca vem do lado do agente.Memória passiva não é fraqueza: é a condição da soberania. Um vault que depende de um núcleo ativo para existir está amarrado a esse núcleo. Um vault que é só arquivos versionados pertence ao usuário e funciona com qualquer agente. Quando enforcement é necessário, ele vem do sistema operacional, abaixo do agente, nunca do próprio agente.
Suporte multimodal é acomodado pela estrutura de /assets/ por domínio e projeto. A capacidade de processar imagens, áudio e PDFs depende do LLM configurado no agente, não do agente em si. Consulte a documentação do provider para capacidades atuais.
Sistemas centralizadores tratam todo conteúdo da memória como válido até que um humano explicitamente o marque como obsoleto. Em prática, isso significa que conteúdo desatualizado permanece em circulação por meses ou anos, ninguém revisa o que não está visivelmente quebrado.
Memória federada tem uma vantagem estrutural sobre sistemas centralizadores nesse ponto: o conteúdo vive como arquivos no sistema operacional do usuário. Arquivos têm mtime. Guiado pelo contrato, o agente cliente, ou um hook de captura, inspeciona o mtime de cada arquivo listado em Use: ao montar um Context Pack. Se algum arquivo passou mais de noventa dias sem atualização, o pack carrega um aviso anexado ao output.
A escolha de avisar, e não bloquear, é deliberada. Conteúdo antigo não é necessariamente errado. Princípios de engenharia podem ter sido escritos há um ano e continuarem válidos. Mas conteúdo antigo merece um momento de checagem antes de ser usado como base para decisão nova. O aviso atende esse propósito sem virar fricção.
Sistemas centralizadores não têm equivalente. A memória vive como objetos opacos dentro do aplicativo, sem mtime exposto, sem inspeção possível por componente externo. Memória federada herda essa capacidade do sistema de arquivos, não foi inventada, foi reconhecida.
O comportamento padrão é informativo. O humano pode escalar configurando um hook, ou instruindo o agente via contrato, para bloquear packs com conteúdo acima de um limite (por exemplo, seis meses). Para packs de domínios voláteis (regulatório, ML, mercado), o limite pode ser menor; para domínios estáveis (princípios, fundamentos), maior. A configuração é por pack, não global, porque a velocidade de envelhecimento é específica do conteúdo.
Memória federada não é superior em todos os cenários. A comparação honesta exige reconhecer onde outras abordagens têm vantagem.
Para usuários com uma única ferramenta, um único projeto e baixa necessidade de portabilidade, a memória nativa é a escolha certa. Fricção de setup zero, integração perfeita com o fluxo da ferramenta, nenhuma infraestrutura adicional. O custo, dependência de ferramenta, ausência de portabilidade, só aparece quando o contexto cresce além do que a ferramenta comporta.
Há um degrau abaixo desta arquitetura, e ele é legítimo. Um agente só, poucos projetos, pouco contexto acumulado: um arquivo de contrato global com regras e preferências, mais um por projeto com o contexto local, versionados em Git, resolvem bem. No Claude Code esse arquivo é o CLAUDE.md; na convenção neutra adotada por vários agentes, é o AGENTS.md. Mas isso é contrato, não memória: não acumula conhecimento revisado, não isola domínios e não tem ciclo de revisão. Esta arquitetura começa a se pagar quando o contexto cresce, quando entra um segundo agente, ou quando a memória precisa ser revisada e auditável. Antes disso, o degrau simples é a escolha certa, e quem começa pelo AGENTS.md já está, sem perceber, no embrião do contrato neutro que esta arquitetura formaliza.
Para times que precisam de memória compartilhada entre múltiplos usuários, com retrieval semântico automático e sem curadoria manual, Mem0 e Zep são mais adequados. A federada exige disciplina de curadoria que não escala automaticamente para equipes grandes sem processos adicionais.
Existe uma categoria de projetos que adota a abordagem oposta da federada: concentrar memória, automação, integrações e agentes em um único aplicativo monolítico, frequentemente chamados de "Personal AI", "Life OS" ou "super-app de produtividade". Eles vencem em superfície de uso: UI pronta, integrações empacotadas, comunidade visível, curva de adoção quase nula. O usuário instala, conecta serviços e tem algo funcionando em minutos.
O custo aparece depois. A memória vive dentro do aplicativo, no formato do aplicativo. Trocar de ferramenta significa começar do zero. A arquitetura é, por design, centralizadora, exatamente o anti-pattern que motivou este paper. Para quem prioriza velocidade de adoção sobre soberania, é a escolha certa; para quem prioriza portabilidade e governança, é o problema vestido de solução.
Para usuários que trabalham com múltiplos agentes em paralelo, múltiplos domínios de trabalho, e que precisam de portabilidade real, onde a memória deve sobreviver à troca de ferramenta, a federada é a única abordagem que resolve o problema estruturalmente. O diferencial não é um componente esperto, é a soma de quatro propriedades que nenhuma das outras entrega junto: soberania (a memória é legível por humanos e pertence ao usuário), portabilidade (não requer ferramenta específica para ser acessada), auditoria (versionada em Git, com autoria e histórico) e isolamento por domínio. Tudo isso com mecanismos abertos, sem amarrar a um fornecedor.
O projeto DecisionNode1, desenvolvido independentemente, chegou a conclusões parcialmente sobrepostas: decisões como unidade estruturada, acesso via MCP por múltiplos agentes, histórico auditável, padrão blackboard implícito. Resolve especificamente o sub-módulo de decisões com busca semântica por embeddings, uma implementação concreta de parte dos princípios propostos aqui. A convergência independente de projetos distintos para conclusões similares é evidência de que o problema é real e a direção arquitetural é válida.
À medida que múltiplos agentes especializados coexistem no mesmo ecossistema, o padrão blackboard evolui para o que chamamos de mente de colmeia: cada agente mantém sua memória privada, mas conhecimento reutilizável é publicado numa área compartilhada do vault que qualquer agente pode consultar. Leitura federada, escrita controlada. Nenhum agente altera diretamente a memória de outro. Melhorias são propostas, não impostas.
O paper Agentic Context Engineering (ACE), publicado em 2025 por pesquisadores de Stanford, SambaNova Systems e UC Berkeley (arXiv:2510.04618), chegou de forma independente a uma formulação que valida a arquitetura proposta aqui. O ACE trata o contexto como um "playbook" que evolui ao longo do tempo, mantido por três papéis: Generator (executa a tarefa e produz a trajetória), Reflector (analisa acertos e erros e extrai lições) e Curator (consolida as lições em atualizações incrementais do playbook). O paralelo com a arquitetura federada é direto: o agente executor (Claude Code, Cursor, etc.) é o Generator; a captura por hooks com classificação confidence + risk é o Reflector; o review-inbox com promote-skills e a regra approved/superseded é o Curator; e o vault federado é o playbook. A diferença é filosófica e é o diferencial desta arquitetura: no ACE, os três papéis são totalmente automáticos, executados por LLMs. Na memória federada, o Curator mantém o humano como auditor de última instância. Baixo risco consolida automaticamente; hipóteses e alto risco exigem decisão humana. Em uma frase: esta arquitetura é ACE com governança proporcional ao risco. O ACE reporta ganhos de +10,6% em tarefas de agente e +8,6% em raciocínio de domínio sem fine-tuning, evidência de que a direção (contexto como playbook que evolui, não prompt estático) é tecnicamente sólida.
Sistemas como o Paperclip (paperclip.ing) resolvem um problema adjacente mas distinto. Não são sistemas de memória, são plataformas de orquestração de equipes de agentes, com org charts, orçamentos por agente, heartbeats agendados e governança hierárquica. A distinção é importante: memória federada é infraestrutura de contexto por agente. Orquestração é infraestrutura de coordenação entre agentes. Quem usa as duas camadas juntas tem a solução mais completa: contexto persistente e governado por um lado, coordenação estruturada por outro. O Paperclip inclusive usa um SKILLS.md próprio para injeção de contexto em runtime, convergência com a pasta /50-skills/ desta arquitetura. São projetos complementares, não concorrentes.
Na outra ponta do espectro, o Pi (pi.dev) é minimalista por design e não tem MCP nativo. Tem AGENTS.md, skills e compaction automático próprios. A integração com o vault federado acontece via filesystem direto, rodar o Pi dentro do vault já carrega o AGENTS.md automaticamente, sem necessidade de configurar um MCP server. A memória federada adiciona o que o Pi não oferece sozinho: portabilidade entre máquinas, isolamento por domínio e governança com aprovação humana.
Adotar memória federada não compra todos os problemas resolvidos. Seis limitações merecem ser reconhecidas explicitamente, não para justificar a arquitetura, mas para deixar claro onde ela termina e onde o usuário precisa preencher a lacuna.
A arquitetura governa o que entra no contexto e organiza o que pode ser escrito, mas não desfaz a ação que o agente já executou. Se um agente, ao receber um Context Pack, produz código ruim, manda e-mail errado ou aplica uma mudança em sistema externo, a memória federada não tem como reverter isso. Rollback continua sendo problema do sistema-alvo (Git para código, sent-folder para e-mail, transações para banco). A memória federada melhora a chance de o agente fazer a coisa certa; não garante que a ação seja reversível quando ele falha.
Esta limitação é parcialmente mitigada por duas coisas. Primeiro, o pre-action logging: antes de executar ações de alto risco, o agente registra em /99-archive/pre-action-log.md o contexto ativo, o pack carregado, o agente executor e o recurso alvo. Não é rollback, é rastreabilidade. Segundo, como o vault é um repositório Git, toda escrita na própria memória é um commit reversível. Para a memória, o Git cobre o rollback; para a ação externa, o sistema-alvo é que precisa cobrir.
A inspeção de mtime avisa quando arquivos do Context Pack passaram do limite de idade configurado. O aviso é informativo, não bloqueante por padrão. Conteúdo antigo pode continuar válido; conteúdo recém-atualizado pode estar errado. A arquitetura não substitui revisão de conteúdo, torna mais visível o ponto onde a revisão é necessária. Confundir aviso de validade com garantia de correção é uma falha de interpretação que o sistema não previne.
Esta limitação é mitigada pelo campo review_date nos Context Packs e Decisions. Em vez de depender apenas do mtime do arquivo, o agente cliente, ou um hook, verifica se next_review venceu, independente de o arquivo ter sido modificado. O humano que revisa o conteúdo e confirma que ainda é válido atualiza o review_date sem alterar o arquivo. O sistema distingue conteúdo não modificado de conteúdo revisado.
Com a classificação automática por confidence + risk, o que é verified + low promove-se sozinho com TTL, e o inbox acumula apenas hipóteses e decisões de alto risco. A dependência humana fica restrita a isso: se você nunca revisar o inbox, hipóteses e itens de alto risco não viram memória, enquanto o fluxo automático segue operando para o resto. Os hooks de captura (ver o guia, seção 09c) reduzem a dependência de ação manual, mas não eliminam a revisão dos casos consequentes. Isto é uma premissa de operação assumida, não uma falha escondida: o modo cooperativo pressupõe um humano que faz curadoria de qualidade no que importa.
A implementação de referência foi exercitada em escala pequena (uma pessoa, poucos domínios, alguns projetos). Comportamento em escala média ou grande é projeção arquitetural, não dado de campo. Mas escala não é um teto, é a escada de maturidade descrita na seção 05: o piso é vault Markdown + Git; sob dor de tempo real, soma-se sincronização contínua; sob dor de volume, entram um MCP server como acesso comum e o Graphiti como índice derivado dos Markdown; e o isolamento físico em múltiplos vaults aparece quando NDA ou dados sensíveis de cliente o exigem. Cada degrau entra sob dor concreta, não por antecipação.
A estrutura da mente de colmeia está implementada: /50-skills/published/, /proposed/, /deprecated/, INDEX.md e protocolo de publicação via inbox. Os scripts promote-skills.mjs e update-index.mjs automatizam a promoção por TTL e a atualização do índice. O que ainda é roadmap: integração com Graphiti para relações entre skills, busca semântica no índice, e worker local que indexa automaticamente quando o ecossistema de agentes especializados crescer o suficiente para o compartilhamento fazer sentido operacional.
Esta é a limitação que um teste de campo expôs e que a honestidade exige declarar. No setup recomendado (vault Markdown + Git + contrato), a governança de escrita é contrato, não trava. Um agente que coopera deposita sugestões no /90-inbox/ e respeita as pastas protegidas porque o AGENT.md pede. Um agente que decida ignorar o contrato escreve onde quiser, porque as pastas são graváveis por quem roda o agente. Nenhum componente do lado do agente impede isso. Quem precisa de enforcement real, contra um agente potencialmente hostil, sobe ao modo adversarial descrito na seção 05: o controle vem do sistema operacional, abaixo do agente (container com mount read-only exceto no inbox, ou usuário separado sem escrita nas pastas protegidas). Subir de degrau na escada de maturidade dá escala e busca, nunca disciplina de escrita de graça.
O campo de agentes de IA amadureceu rapidamente na camada de capacidade, raciocínio, geração de código, análise de documentos. A camada de memória ficou para trás, e o gap está se tornando o principal limitador de uso contínuo. Não é falta de inteligência do agente. É falta de continuidade de contexto entre sessões, projetos e ferramentas.
As soluções atuais tratam memória como feature de produto: algo que cada ferramenta implementa internamente, de forma proprietária, com o usuário como beneficiário passivo. A proposta deste paper inverte essa relação: memória é infraestrutura do usuário, não do produto. Agentes são consumidores temporários de um contexto que pertence a quem trabalha, não a quem fornece a ferramenta.
A adoção dessa arquitetura não depende de mudança nos agentes de IA. Depende de uma mudança de pressuposto sobre onde a memória mora. Quando a memória pertence ao usuário, legível, versionável, portátil, governada, a troca de ferramenta deixa de ser uma perda.
Esta arquitetura recusa quatro caminhos. Recusa backend hospedado como serviço, quebra a soberania. Recusa memória automática sem revisão, é o anti-pattern central. Recusa adaptador único universal, cada agente tem convenções próprias, um adaptador genérico vira o pior denominador comum. Recusa RAG no caminho crítico, embeddings ajudam na busca, nunca substituem Markdown como fonte.
O que esta arquitetura aceita: ser mais lenta de adotar do que um aplicativo monolítico; exigir disciplina de curadoria que ferramentas automáticas não exigem; pedir ao usuário que aprenda o contrato antes de delegar; e operar, por padrão, no modo cooperativo, onde a governança de escrita é contrato e não trava. Enforcement contra um agente hostil não é função do contrato: é hardening de sistema operacional, fora do escopo padrão e disponível para quem precisar (seção 08). O preço da soberania é a participação ativa.
Uma escolha de mecanismo decorre disso. Um sync proprietário, como o Obsidian Sync, resolve sincronização em tempo real, mas não versiona e amarra a base a um fornecedor. Por isso a arquitetura de referência usa Git: ele sincroniza e versiona numa peça só, com mecanismo aberto, e a sincronização contínua proprietária fica como camada opcional por cima, nunca como espinha.
1 DecisionNode, github.com/decisionnode/DecisionNode. Implementação de referência para o sub-módulo de decisões com embeddings vetoriais e acesso via MCP.
2 Hermes Agent, NousResearch. github.com/NousResearch/hermes-agent
3 Graphiti, Zep. help.getzep.com/graphiti/graphiti/overview
4 Model Context Protocol, modelcontextprotocol.io
5 ACE (Agentic Context Engineering). Stanford University, SambaNova Systems, UC Berkeley. arXiv:2510.04618. Framework de contexto evolutivo com papéis Generator, Reflector e Curator.
6 Para a implementação completa com passo a passo, templates e estrutura de vault: ver o Guia de Implementação disponível no repositório.