Skip to content
UHPUHPDeveloper Guide
Independent resource · Not affiliated with HarnessRouter · Site data checked 5 Sep 2026

Comparison

UHP vs Open Memory Protocol (OMP)

UHP standardizes how clients drive complete agent harnesses. The Open Memory Protocol Initiative's OMP work targets a different portability layer: persistent agent memory, including loading, structure, provenance and lifecycle concerns.

Verified: UHP: 2026-08-11OMP: pre-1.0 drafts

The one-sentence difference

Section titled “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

Section titled “Status first”
  • UHP remains the public 2026-08-11 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.
  • OMPI’s current repository has a version-boundary ambiguity that should be preserved rather than flattened: its stage banner still calls the textual spec/draft-v0.1.md the draft technology open for iteration, while its Key Artifacts section also publishes spec/draft-v0.2-packer.pdf as an updated v0.2 Agent Memory Specification with expanded schema, provenance and lifecycle definitions. The v0.2 PDF was added on 1 September 2026.
  • The concrete four-rule harness loading contract described below is verified directly from the textual v0.1 working draft. This page does not project uninspected v0.2 details beyond what OMPI’s own README and the v0.2 commit message state.
  • 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

Section titled “UHP vs OMP”
DimensionUHPOMPI Open Memory Protocol
Primary boundaryProduct/client ↔ UHP server ↔ complete agent harnessHarness/memory consumer ↔ portable agent-memory representation and memory-loading/lifecycle behavior
Main goalNormalize execution, sessions, streaming, cancellation, files and artifacts across harnessesMake persistent agent memory portable across harnesses/services
Current status checked2026-08-11 DraftPre-1.0 draft family; v0.1 text working draft plus v0.2 updated draft PDF
Verified concrete abstractionHarnesses, Responses/Tasks, Sessions, Containers, files, artifacts and eventsv0.1: memory/ directory, root/core Markdown, nested/deferred Markdown and MEMORY.md discovery
In-context behaviorUHP does not prescribe an agent’s persistent-memory file layoutv0.1: root Markdown is loaded as core memory; nested Markdown is deferred
Deferred retrievalUHP files/tasks are protocol resources; persistent-memory retrieval policy is not standardized by UHPv0.1: harness must surface deferred memory and support selective reads
Broader draft directionNot a persistent-memory standardOMPI describes v0.2 as expanding schema, provenance and lifecycle definitions
TransportHTTP/SSE contractCurrent OMPI draft work is a memory portability layer rather than a UHP-like task transport
Conformance evidencePublic UHP suite and measured server resultsExperimental Python loader/validator targets the v0.1 harness contract; no UHP-equivalent released conformance certification is claimed here
RelationshipNormative harness-execution protocolAdjacent memory-portability layer; no standardized UHP binding verified

What the textual v0.1 draft actually standardizes

Section titled “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 current v0.1 harness contract has 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

Section titled “The v0.2 boundary”

OMPI added spec/draft-v0.2-packer.pdf on 1 September 2026. The repository’s own commit message and current README describe it as an updated v0.2 Agent Memory Specification by Charles Packer (Letta) that expands schema, provenance and lifecycle definitions.

At the same time, the repository’s current-stage banner still points contributors to the v0.1 draft technology for iteration. Until OMPI resolves that presentation into one unambiguous canonical version surface, this guide treats OMP as a pre-1.0 draft family, uses v0.1 for directly verified textual harness-contract details, and reports v0.2 only to the extent supported by the repository’s own metadata.

Why this matters to harness interoperability

Section titled “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

Section titled “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

Section titled “Current OMPI ecosystem signal”

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

Section titled “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

Section titled “What OMP does not establish”
  • It does not change UHP 2026-08-11 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.
Section titled “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

Section titled “Primary sources”