Memória de agentes de IA busca um padrão comum inspirado no OpenTelemetry

O inventário que todo time de dev já tem sem perceber

Abra o repositório de um time que usa agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → para codar e é provável achar um AGENTS.md ou CLAUDE.md, talvez regras em .cursor/rules/*.mdc, um agente escrevendo arquivos numa pasta /memories via memory tool da Anthropic, o GitHub Copilot guardando fatos sobre aquele repo do lado do servidor, e um servidor MCP de memória mantendo um grafo de conhecimento em JSONL. Um post no blog da LoreKit soma isso e chega a quatro formatos diferentes rodando ao mesmo tempo, e nenhum lê o outro.

Na prática, isso significa que uma lição que o agente de CI aprendeu fica presa em quem a escreveu. O agente do editor de código não enxerga aquilo, e a próxima ferramenta que o time testar também não. O autor do post, que constrói a própria LoreKit (um dos formatos candidatos) e trabalha também com observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → na Dash0, argumenta que o problema não é falta de ferramenta: é falta de acordo. E lista uma onda constante de posts em comunidades como r/ClaudeAI e r/LocalLLaMA de gente construindo sua própria camada de memória, cada uma com schema e MCP tools próprios, provando que o problema é real e crescendo.

O precedente: antes de 2019, cada vendor de observabilidade tinha seu agente

A comparação que sustenta o artigo é direta. Antes de 2019, cada fornecedor de observabilidade distribuía seu próprio agente de instrumentação, sua própria biblioteca e seu próprio formato de dado: trocar de vendor significava reinstrumentar o código inteiro. Dois projetos abertos, OpenTracing e OpenCensus, tentaram resolver isso e competiam entre si.

Em 2019 eles se fundiram em OpenTelemetry, e o que ficou acordado foram quatro camadas: um modelo de dado (o que é um span, uma métrica, um registro de log), convenções semânticas (nomes como service.name e http.*), um protocolo único (OTLP) e implementações de referência compartilhadas (SDKs e o Collector). Os vendors continuaram competindo no que fazem com o dado depois que ele chega: armazenamento, consulta, análise.

O argumento central do post é que memória de agente está exatamente onde a observabilidade estava antes de 2019: muita implementação, nada combinado por baixo. E o timing ajudaria, porque os formatos ainda são jovens o bastante para mudar, e já existe uma casa neutra disponível: tanto MCP quanto AGENTS.md vivem sob a Agentic AI Foundation, da Linux Foundation.

O mapa dos formatos hoje

O post reúne um panorama (que o próprio autor marca como um retrato de fim de 2026, sujeito a mudar rápido) de como cada família resolve as mesmas quatro perguntas: onde a memória é verdadeira, qual sua identidade, o que ela diz e quando deixa de valer.

Algumas dessas escolhas acertaram algo que um padrão deveria preservar: o Copilot Memory combina citações verificáveis contra o código com esquecimento por padrão, mas fica preso a um único produto. O LangGraph mostra como o núcleo pode ser pequeno, resumido em put(namespace, key, value). O Graphiti modela tempo de verdade, com linhas do tempo separadas para quando um fato era verdadeiro e quando foi registrado. E o AGENTS.md prova que um arquivo simples num caminho conhecido já pode virar padrão de fato.

O que já existe de proposta, e o que falta nelas

O post lista três iniciativas em andamento. A Portable Memory, da MacPaw Research, é um pacote .mem com serialização reproduzível byte a byte, tombstones de exclusão e assinatura opcional, mas os próprios autores admitem que ainda não tem adoção ampla. O Open Memory Protocol é um rascunho de abril de 2026 para mover conversas e as memórias derivadas delas entre plataformas, como um ZIP com manifesto. O formato COGX, do Cognee, faz a ponte de importação entre Mem0, Letta e Zep.

Essas três resolvem majoritariamente exportação: tirar a memória de uma pessoa do vendor A e levar para o vendor B. Mas ferramentas de código têm um segundo problema, mais específico de engenharia: endereçamento ao vivo. Quando um job de CI, um agente no editor e um bot de review trabalham no mesmo repositório ao mesmo tempo, como eles leem e escrevem no mesmo lugar e concordam sobre o que aquilo significa? Um padrão completo precisaria cobrir os dois casos, e as propostas de hoje cobrem só o primeiro.

Como seria um registro padrão, na prática

O post propõe (deixando claro que os nomes de campo são ilustrativos, não uma proposta fechada) um formato de registro com um envelope de frontmatter e o conteúdo da memória em Markdown logo abaixo:

---
spec: agent-memory/0.1
id: 8f0c2a6e-4b1d-4c7a-9e2f-3a5b6c7d8e9f
address: { level: repo, value: github.com/acme/checkout }
key: tests-need-local-postgres
kind: lesson
written_by: { type: agent, name: claude-code }
content_type: text/markdown
lifecycle: { expires_at: null, extended_by: write }
attributes: { vcs.pr: 482, ci.run_url: "https://ci.example/runs/123" }
---
Integration tests fail with `ECONNREFUSED 127.0.0.1:5432` unless Postgres
is already running. Start it before `pnpm test`:

 docker compose up -d db

O campo address e o key dizem onde aquilo é verdade, id dá identidade ao registro, lifecycle diz quando ele expira e written_by responde a pergunta que, segundo o post, é o único ponto de bifurcação real entre os formatos existentes: quem escreve a memória. Em arquivos de instrução é uma pessoa; no memory tool, no Letta e no LoreKit é o próprio modelo; no Mem0 e no Graphiti é um serviço que extrai fatos da conversa. Um padrão não precisa escolher um único dono, só precisa registrar qual foi, para quem lê saber quanto confiar.

Em torno desse registro, o post espelha as mesmas quatro camadas do OpenTelemetry: convenções (nomes compartilhados para níveis de endereço como global, project, repo, branch, e namespaces de atributo como vcs.*, ci.*, agent.*), um contrato (operações fixas de escrita, leitura, listagem, busca e arquivamento, expostas via MCP) e testes de conformidade no lugar de uma implementação de referência única, checando se um round-trip do registro preserva tudo e se atributos desconhecidos sobrevivem a uma reescrita.

As objeções, respondidas no próprio post

O autor antecipa quatro críticas. À primeira, de que quem constrói uma ferramenta de memória só quer um padrão no formato da própria ferramenta, ele responde que por isso a LoreKit entra como só mais uma linha da tabela, não como o modelo a seguir. À segunda, de que o MCP já seria o padrão, ele distingue que o MCP padroniza a chamada, não o registro: assim como a observabilidade precisou de um protocolo e de um modelo de dado, memória também precisa dos dois.

À terceira, de que memória compartilhada vira um canal de prompt injection, a resposta é concordar: qualquer coisa que um agente lê pode direcioná-lo, e compartilhar memória amplia quem pode escrever nela. Por isso um padrão deveria tornar isso visível, registrando quem escreveu cada memória, permitindo assinaturas (a Portable Memory já faz isso) e deixando um registro apontar para o código do qual ele depende. À quarta objeção, a mais forte segundo o próprio autor, de que mais um padrão só pioraria a fragmentação (o clássico xkcd 927), a resposta aponta para o próprio OpenTelemetry: o acordo veio quando projetos existentes se fundiram, não quando alguém lançou mais um.

O que fica em aberto, e o que muda pra quem constrói com agentes hoje

O post deixa quatro perguntas sem resposta fechada: quais níveis de endereço fazem sentido (monorepos pedem algo entre repo e branch), se esquecimento deveria ser o padrão por default, se um registro deveria apontar para o código do qual depende, e quem coordenaria esse trabalho (grupo de trabalho, fundação ou um rascunho aberto a contribuições).

Para quem já tem agente de CI, bot de review e assistente de código rodando no mesmo repositório, o recorte prático é simples: hoje, cada um desses provavelmente guarda memória num lugar diferente, e migrar de ferramenta significa perder o que foi aprendido. Não existe ainda um padrão para adotar, mas dá para já mapear quantos desses quatro formatos convivem no seu próprio setup, e cobrar interoperabilidade dos fornecedores que você usa. Quem quiser ver um desses formatos na prática pode rodar npx @lorekit/cli install, que grava os registros como Markdown simples, legível com grep e diff, e comparar com o que as outras ferramentas do seu stack já escrevem.

Fonte: Hacker News