Open Memory Protocol Initiative
A multi-stakeholder working group hosted at the AI Disclosures Project, developing an open, interoperable protocol for portable AI-agent memory
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 (OMP) 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
- A memory-directory contract that any conforming harness can read: markdown files at the root, optional nested subdirectories for progressive disclosure.
- A four-rule harness contract: root markdown is loaded into context, nested markdown is deferred, deferred paths are surfaced to the agent, agents can selectively read deferred files.
- The distinction between core memory (always in-context) and external memory (progressively disclosed).
- Structural validation rules for MEMORY.md discovery across the memory tree.
Backends, ownership, and internal architecture stay with implementers
- Storage backend (files, database, vector store, hybrid)
- Synchronization or version control (git, MemFS, cloud replication)
- Who owns or may write each file
- How memory is edited or summarized inside a harness
- When a running conversation refreshes the prefix after an edit
What a portable OMP record contains
The working object model is developed openly and tested against real implementations. The expected minimum fields are design hypotheses, not fixed requirements at the start of the project.
| Element | Purpose |
|---|---|
| Identity and version | Stable record identifier and schema/protocol version, for migration and de-duplication. |
| Scope / namespace | User, project, organization, or shared-group scope; separates memory that may be portable from memory that must remain local. |
| Type and payload | A small typed envelope plus implementation-extensible content, so systems can interoperate without forcing one internal memory taxonomy. |
| Source and provenance | Originating system, underlying event/transcript/artifact reference where available, transformation history, and authorship/derivation metadata. |
| Lifecycle | Creation and update times, retention or expiry information, and optional decay/recency semantics. |
| Permissions and consent | Who or what may read, export, modify, or share a record; preserves access constraints during exchange. |
| Integrity metadata | Hashes, signatures, or other integrity information supporting chain of custody and tamper detection. |
Security enters the protocol at the object and exchange layers
Memory is security-sensitive because it persists information and can influence later agent actions. Security and privacy therefore enter the protocol design at the object and exchange layers, not as deployment-only concerns.
| Risk | Mitigation |
|---|---|
| Memory poisoning or malicious modification | Provenance and integrity metadata; permissioned writes; immutable source links where possible; adversarial fixtures; review of high-impact write paths. |
| Unauthorized disclosure | Explicit scope and permission fields; least-privilege export; redaction and filter hooks; secure defaults; no assumption that all memory is exportable. |
| Permission mismatch across systems | Minimum interoperable permissions; fail closed when semantics cannot be preserved; record non-portable policy metadata alongside the payload. |
| Loss of provenance or chain of custody | Source and derivation metadata; transformation history; stable identifiers; integrity checks; conformance tests for provenance across import/export cycles. |
| Software supply-chain risk | Signed releases; dependency manifests and SBOMs; coordinated-disclosure process; continuous-integration security checks on the reference implementation. |
What is available today
Agent Memory Specification, v0.1
Draft authored by Charles Packer (CEO, Letta) with feedback from the AI Disclosures Project team. Circulating in the working group in advance of the September 9 kickoff.
Read the draftPython package (pre-alpha)
A minimal Python implementation of the loader, validator, and harness contract. Runs against any spec-conformant memory directory.
View on GitHubWorking-group governance model
Steering committee, RFC process, licensing, and long-term stewardship plan (target: standards-body handoff after production adoption).
Read governanceState of agent memory (2026)
A survey of production and open-source memory systems (Letta, Mem0, Zep, Graphiti, AWS AgentCore Memory, Google OKF, and coding-agent harnesses) and where OMPI fits.
Read the surveyFormal in-kind partners and implementation collaborators
Mozilla
Co-hosts working-group convenings and leads ecosystem recruitment across Mozilla's open-source and AI-developer network.
IBM
Co-hosts convenings, contributes enterprise-adoption pathways, and advises on standards-body process.
Letta
Author of the draft OMPI specification. Contributes MemGPT / Letta memory-object model and the open-source Trajectory package.
Block / goose
Open-source agent harness built on the Model Context Protocol. First-vertical implementation target for OMPI conformance.
From kickoff to IETF handoff
Join the working group
If you build agent memory, maintain a coding-agent harness, run a memory-layer service, or work on standards for AI infrastructure, we want you in the working group.
Email OMPI GitHub