Open Memory Protocol Initiative

Persistent memory is becoming a core layer of agent infrastructure faster than shared exchange semantics are emerging

Agent memory is persistent context that affects future model or agent behavior: user-provided facts, model- or agent-derived summaries, project instructions, prior decisions and actions, tool outputs, and references to underlying transcripts or artifacts. It is scoped to a user, project, organization, or shared group, and is distinct from a raw chat export. A memory system selects, transforms, organizes, retrieves, and expires information for future use.

Every major coding-agent harness (Claude Code, Codex, goose, OpenClaw, Letta Code) implements memory, but each uses a different convention. A developer cannot move a stateful agent from one harness to another. An enterprise cannot switch memory providers without re-ingesting derived memory objects. Open-source memory projects duplicate one another because there is no shared object model, provenance format, or exchange protocol to converge on.

Fragmented memory has real engineering and security costs. Developers write bespoke adapters. Users and enterprises cannot reliably move accumulated context. Provenance is often lost when memory is copied. Permissions that were meaningful in one system may not survive export, and security review is harder when each integration defines its own exchange behavior. A common open layer addresses these costs without dictating how each agent internally reasons, summarizes, indexes, or retrieves information.

The Open Memory Protocol (OMPI) closes this gap. The Open Memory Protocol Initiative (OMPI) is the working group hosted at the AI Disclosures Project that develops, maintains, and grows the ecosystem around it.

The smallest interoperable layer over existing memory primitives

Charles Packer's discussion draft opens up a set of concrete questions the working group will take up. Among them:

• What common structure a folder of memory files should have so any coding-agent harness can read it.
• How memory should be loaded into the model's context on every request, and how the rest of the memory should be held back until the agent asks for it.
• How to separate the small amount of memory that is always in context from the larger store that is progressively disclosed.

What today's memory systems already do

The working group's scoping note surveys memory implementations across coding harnesses, consumer assistants, and enterprise agent systems, and identifies shared practices that are candidates for a minimal open protocol. These are the concrete issues the group will discuss — not commitments about what OMPI will contain.

• Persistent memory across sessions. Memory that survives across chat sessions rather than disappearing at conversation end. Present in Claude Code, OpenHands, Hermes, VS Code / Copilot, Deep Agents, ChatGPT, Gemini, AWS AgentCore, Vertex Memory Bank, and Microsoft Foundry.
• Scope and ownership. Every memory tied to an owner or context: user, project, agent, team, or organization. Labels vary across systems, but each can answer "whose memory is this?"
• Lifecycle operations. Memory treated as something with a lifecycle: create (remember), read (recall), update (correct or revise), delete (forget). Explicit in Hermes, Letta, Foundry, Copilot Studio, and various coding harnesses.
• Selective retrieval. Agents request the memories relevant to the current task rather than loading the entire memory store.
• Controls and policy. Rules for privacy, access, retention, provenance, and permission — who may create, read, modify, or delete memory.

The full scoping note covers coding-harness patterns (files, project + user scopes, always-loaded core, deferred stores), consumer-assistant patterns (learned user context, past-chat recall, explicit remember / correct / forget), enterprise patterns (structured records, extraction and consolidation, semantic retrieval, TTL policy), what is converging cross-vendor (background consolidation, progressive disclosure), and what is not converging and should stay implementation-specific (retrieval internals, human-approval workflow, MCP memory access).

What is available today

Partners and implementation collaborators

From first informal discussion to sustainability review