UHP vs Open Memory Protocol (OMP)

Plan memory portability around the loader contract

The OMPI artifact hub, reopened 4 October 2026, lists several proposals rather than one finished portable-memory standard. Current artifacts were recovered under early-draft-specs/ at revision 41c72801; the old main/spec/draft-v0.1.md and main/spec/draft-v0.2-packer.pdf paths return 404. The former textual v0.1 analysis below remains historical, with its immutable original draft recovered separately. UHP is UHP 2026-09-28 Draft.

Choose a proposal before claiming compatibility

Recovered primary artifact	Reader decision	Boundary of the evidence
Letta/Packer draft v2, six pages	Use its directory hierarchy and selective-loading rules for a file-based loader	Root Markdown may be partially visible/truncated; nested files are deferred. Its scope excludes write ownership, synchronization, version control and live-prefix refresh. Optional metadata is not a portable authorization system.
AI Disclosures draft, four pages, internally titled Federated Memory Protocol	Consider a shared interface across multiple memory servers	Proposed interfaces distinguish ground truth, transcripts and inferences; no filesystem requirement. This is a separate contribution, not a later revision of the Letta loader.
IBM proposal, four pages	Evaluate import/export identity, provenance, invalidation and permission mapping	Proposed guarantees do not establish an implemented common runtime. The PDF prints “Sep 3, 2027” while its repository artifact and PDF metadata predate that date; the chronology remains unresolved.

The README at the same revision describes Letta v0.2 as expanding schema, provenance and lifecycle. The PDF’s own scope is narrower. This comparison follows the inspected PDF for its concrete loading rules and preserves that description conflict. The Packer draft also pairs a 500-token recommendation with an inconsistent character estimate; use your own tokenizer rather than treating it as a conversion rule. No consolidated ratified OMPI version or cross-proposal compatibility was established.

Before moving memory between harnesses, answer four loader questions:

1. Which files enter context automatically, and which remain discoverable but deferred?
2. How does the receiving harness discover deferred material rather than merely gaining filesystem access?
3. Which author, origin and revision survive the move, and how are conflicting or superseded memories represented?
4. Who may mutate or delete the imported memory, and how is that decision audited?

A local acceptance fixture can import a small tree containing core notes, one deferred fact and one conflicting revision. Check that the receiving harness sees the core, can deliberately retrieve the deferred fact, and preserves the conflict instead of flattening both into an authoritative statement. This tests your loader; it does not certify an evolving OMP draft.

UHP session files provide execution resources. They do not define memory-loading policy. Committed memory mutation identity covers the separate problem of proving which native record a mutation actually changed.

The one-sentence difference

UHP is a client↔server contract for executing and controlling a complete agent harness; Open Memory Protocol Initiative (OMPI) work targets a memory-portability contract for organizing persistent agent memory and deciding how it is structured, surfaced, retrieved and governed across harnesses or services.

They solve different interoperability problems and can be composed without either protocol depending on the other.

Product / IDE / service
        │
        │ UHP
        ▼
   Agent harness
        │
        │ OMP memory contract
        ▼
 portable persistent memory

The diagram is conceptual. No standardized UHP↔OMP binding was identified in the primary sources reviewed here.

Status first

Historical draft analysis: the remaining sections and comparison table preserve the earlier v0.1 review. Current proposal selection and recovered v0.2 evidence are scoped above; old metadata statements below are historical, not a renewed claim about the current draft family.

• UHP remains the public 2026-09-28 Draft with its own HTTP/SSE task, session, file, artifact and conformance surfaces.
• OMP/OMPI is pre-1.0 early public work, not a finalized 1.0 standard.
• The earlier repository snapshot had a version-boundary ambiguity: its stage banner called the textual spec/draft-v0.1.md the working draft, while the artifact list described a v0.2 PDF with expanded schema, provenance and lifecycle. The recorded v0.2 addition was 1 September 2026. Current paths and the inspected PDF boundary are shown above.
• The concrete four-rule harness loading contract described below is verified directly from the historical textual v0.1 working draft. The recovered v0.2 PDF was inspected separately for this closeout; its actual scope and conflicts are recorded above, rather than projected into this historical analysis.
• The OMP work tracked here is developed by the Open Memory Protocol Initiative (OMPI), hosted at the AI Disclosures Project. Its repository identifies Mozilla and IBM as formal in-kind partners, Letta as the draft-technology collaborator and Block/goose as an implementation collaborator.
• Those relationships are ecosystem/governance evidence for OMP. They do not establish native UHP adoption by those organizations or products.

UHP vs OMP

Table scope: current UHP execution boundary versus the preserved OMPI v0.1 review; consult the recovered-proposal table above for current OMPI artifacts.

Dimension	UHP	OMPI Open Memory Protocol
Primary boundary	Product/client ↔ UHP server ↔ complete agent harness	Harness/memory consumer ↔ portable agent-memory representation and memory-loading/lifecycle behavior
Main goal	Normalize execution, sessions, streaming, cancellation, files and artifacts across harnesses	Make persistent agent memory portable across harnesses/services
Evidence status	2026-09-28 Draft	Historical v0.1 textual review; current proposal family is not one ratified standard
Verified concrete abstraction	Harnesses, Responses/Tasks, Sessions, Containers, files, artifacts and events	v0.1: memory/ directory, root/core Markdown, nested/deferred Markdown and MEMORY.md discovery
In-context behavior	UHP does not prescribe an agent’s persistent-memory file layout	v0.1: root Markdown is loaded as core memory; nested Markdown is deferred
Deferred retrieval	UHP files/tasks are protocol resources; persistent-memory retrieval policy is not standardized by UHP	v0.1: harness must surface deferred memory and support selective reads
Broader draft direction	Not a persistent-memory standard	OMPI describes v0.2 as expanding schema, provenance and lifecycle definitions
Transport	HTTP/SSE contract	Current OMPI draft work is a memory portability layer rather than a UHP-like task transport
Conformance evidence	Public UHP suite and measured server results	Experimental Python loader/validator targets the v0.1 harness contract; no UHP-equivalent released conformance certification is claimed here
Relationship	Normative harness-execution protocol	Adjacent memory-portability layer; no standardized UHP binding verified

What the textual v0.1 draft actually standardizes

The v0.1 draft starts from a deliberately narrow assumption: agent memory is a directory of Markdown files. It divides that directory into core memory and external/deferred memory.

The v0.1 harness contract in the preserved textual snapshot had four rules:

1. Load root Markdown. Every .md file directly inside the memory root is included in the agent’s context.
2. Defer nested Markdown. Markdown in subdirectories is not automatically loaded.
3. Surface deferred memory. The harness must give the agent memory-specific discovery information sufficient to know deferred memory exists and find relevant files; ordinary filesystem readability alone is not enough.
4. Support selective reads. The agent must be able to load an individual deferred file when needed.

Every directory participating in the memory tree is expected to contain a MEMORY.md, which can hold directory-level context, act as an index, or do both. Subdirectories therefore become the draft’s mechanism for progressive disclosure: material can remain outside the prompt until it is relevant.

The v0.1 draft intentionally leaves storage backends, synchronization, version control and much of memory lifecycle/ownership policy outside this narrow directory/loading contract. Its root-memory size recommendation is guidance rather than a protocol guarantee.

The v0.2 boundary

The earlier review recorded the v0.2 addition on 1 September 2026, with README/commit metadata describing broader schema, provenance and lifecycle work. That historical description is preserved, but the recovered six-page PDF is now inspected and its narrower scope is documented above.

The old banner and later artifact list do not define a linear version upgrade across contributors. Keep the old four-rule analysis separate from the inspected Letta v2 and the IBM/federation proposals.

Why this matters to harness interoperability

Persistent memory is already a harness concern, but current products use incompatible conventions. The OMP repository explicitly calls out examples such as AGENTS.md, MEMORY.md, USER.md and HUMAN.md and frames the problem as moving stateful agents between harnesses without rewriting or re-ingesting accumulated context.

That is adjacent to UHP rather than redundant with it:

• UHP portability: a product can drive different complete harness runtimes through one external execution contract.
• OMP portability: a harness or memory service can consume common persistent-memory representations and behavior.

If both mature independently, a product could use UHP to select and operate a harness while that harness uses an OMP-compatible memory layer internally. Current evidence does not define how UHP discovery, sessions, files or artifacts should expose such memory, so that composition remains an implementation choice.

Experimental implementation evidence

OMPI’s repository includes an experimental Python loader/validator for the v0.1 contract. Its public example separates core_context from a deferred_index and allows selective reads of nested memory. The prototype README says its tests cover the draft’s valid and invalid memory configurations and deliberately omit storage, synchronization and context-window budgeting.

This is useful implementation evidence for the v0.1 draft, but it is not UHP conformance, a HarnessRouter backend, or proof that another harness natively implements OMP.

Current OMPI ecosystem signal

Historical ecosystem record: the following preserves the September review and is not evidence that every linked prototype or collaboration was re-executed during closeout.

On 5 September 2026, the OMP repository added a Markdown version of the Agent Memory System Card (AMS Card) contributed by Mila and Mozilla and pointed to a joint repository intended to go live on 9 September. The OMP README describes that card as a structured documentation format for memory systems. It is complementary ecosystem work rather than part of the v0.1 four-rule harness contract.

The repository also carries an older experimental ACP-based MCP memory-server prototype indexing sessions from multiple coding-agent harnesses. Its presence shows active exploration across existing interoperability surfaces; it does not make OMP an ACP extension, an MCP extension, or a standardized bridge between those protocols.

Important naming collision

“Open Memory Protocol (OMP)” is not currently a unique project name. A separate repository, ai-akashic/open-memory-protocol, independently describes an 1.0-draft protocol with a directory+JSONL package format and a REST runtime API.

That project is not the OMPI/AI Disclosures/Letta draft family tracked in the main comparison on this page. Their version numbers, schemas and protocol shapes must not be mixed. This page uses OMPI OMP when ambiguity matters.

What OMP does not establish

• It does not change UHP 2026-09-28 or the UHP conformance suite.
• It does not define a UHP endpoint, field, capability or conformance requirement.
• It does not establish HarnessRouter support for OMP.
• It does not establish native UHP adoption by Letta, Block/goose, Mozilla, IBM or other OMPI participants.
• It does not turn Agent Skills, MCP or ACP into memory protocols merely because the OMP work references or experiments with those adjacent surfaces.
• Neither the v0.1 text working draft nor the v0.2 updated draft PDF should be described as a finalized 1.0 standard.

Related pages

Read UHP vs MCP for tool/context interoperability, UHP vs ACP for editor/client-to-agent integration, Harness composition for internal runtime topology, and the ecosystem map for other adjacent standards.

Primary sources

• Open Memory Protocol Initiative — AI Disclosures Project
• OMPI Open Memory Protocol repository
• Current OMPI proposal directory
• Historical v0.1 text at its original revision
• Recovered Letta v0.2 PDF
• Commit a47259a adding the v0.2 draft
• OMPI experimental Python loader/validator
• 5 Sep AMS Card repository commit d4693dd
• Independent ai-akashic/open-memory-protocol repository
• Independent OMP 1.0-draft README