Zylos LogoZylos
2026-07-30

Agent Memory Portability: Wire Formats, Provenance Graphs, and the 2026 Standards Race

ai-agentsagent-memoryinteroperabilitystandardsmcpw3cietfdata-portabilityprompt-injectiongdpr

Executive Summary

Moving agent memory involves more than copying text. A receiving runtime must interpret scope, provenance, versions, access rules, and deletion state in compatible ways. The proposals examined here address that semantic gap: memorywire supplies backend adapters, Portable Agent Memory evaluates model-to-model transfer, and PAMSPEC describes authoritative state independently of compute. Their existence already rules out a blanket claim that memory is unexportable. The narrower question is which properties survive a particular migration, and what evidence demonstrates that they do.

Four efforts address different layers. memorywire defines operations and adapter behavior. Portable Agent Memory (PAM) proposes authenticated transfer and reports a pilot across three model pairs over 50 tasks; its 54-test SDK suite is separate evidence. PAMSPEC is an individual IETF architecture draft separating authoritative memory from derived indexes. The W3C AI Agent Memory Interoperability Community Group develops profiles and tests using SAIHM as its normative protocol reference; its output is Community Group Reports, not W3C standards. These are candidate specifications and research artifacts, not a demonstrated universal migration stack.

Several questions remain deployment-specific. Erasing a source record does not automatically remove summaries, embeddings, or other copies derived from it. A successful schema transfer does not prove that a new model uses the memory correctly. Conversational-memory benchmarks provide useful evidence, including temporal reasoning in LongMemEval, but do not by themselves establish secure migration, deletion propagation, or consistent behavior among independently writing agents. Imported memory also crosses a trust boundary: authenticated provenance can identify a source without making its content safe.

This article compares the layers, their evidence, and practical adoption boundaries. The research baseline is July 30, 2026; the Anthropic product-documentation example was refreshed on September 10, 2026 and is labeled below because live limits and preview features can change. No cross-vendor migration, deletion, or poisoning experiment was run for this article.

1. A Concrete Migration Boundary: Managed Memory Stores

Anthropic's documentation provides a concrete example of runtime-specific memory semantics. It is useful for explaining a migration boundary, but is not a survey establishing what every vendor lacks.

Product-documentation update, September 10, 2026. Anthropic's Managed Agents memory documentation describes workspace-scoped text documents, API access for import/export, version history with redaction, and session attachments with read_write or read_only access. It currently lists 100 kB per memory and 10,000 memories per store.

The Dreams documentation, checked in the same update, describes a research preview: a selected model asynchronously curates an input memory store using 1–100 session transcripts and writes a separate output store. It aims to consolidate duplicates, replace stale or contradictory entries, and find useful patterns. These are model-driven outcomes to review, not a deterministic guarantee that the newest statement always wins. Leaving the input unchanged supports comparison and discarding a poor output. The architectural pattern connects to memory consolidation and controlled forgetting.

The documented API supports moving content. That does not establish a lossless mapping from another system's provenance, permissions, or version semantics. Such a mapping requires a source/target contract and a round-trip test. This article does not claim that a native cross-vendor converter is absent from every vendor, or that copying files is impossible; the concern is preserving meaning and controls across implementations.

2. Four Efforts, Four Layers of the Same Stack

memorywire — the wire format layer. memorywire (also distributed as a Python package on PyPI, with a reference implementation on GitHub) defines the narrowest and most immediately implementable piece: a JSON-Schema 2020-12 vocabulary for five memory operations — remember (write), recall (read), forget (delete), merge (deduplicate), and expire (apply a TTL policy) — over four memory type classifications: semantic, episodic, procedural, and emotional. The architecture is a MemoryStore interface plus a fan-out router that can dispatch a single logical operation across multiple backends, and — notably — an optional HITL (human-in-the-loop) governance channel that lets a human approve a write before it's committed to long-term storage, directly addressing the "an agent's own writes shouldn't unilaterally become its own future ground truth" concern. The reference implementation ships five backend adapters (sqlite-vec, mem0, Letta, Cognee, pgvector) and reports strong numbers on a 100-fact/50-query test corpus: perfect recall@5 on 42 gold-id queries, 37.8ms p50 ingest latency, 40.6ms p50 recall latency, and 68 PASS / 12 SKIP / 0 FAIL across 80 conformance cells; the skips represent documented adapter limitations, not failed tests. These results and the recovery claim come from the repository manuscript pinned at 02ddcfcd, §5, available before this article's research date. In its PurgeBench experiment, the entangled class means a malicious directive embedded within an otherwise legitimate, trusted-source memory. Removing the whole record sacrifices its benign content, while retaining it preserves the poison. Automatic non-destructive procedures did not eradicate that class in the reported evaluation; quarantine for human review is a recovery path. This is a poison-removal versus utility tradeoff within a record, not a definition of causal dependence between separate memories.

Portable Agent Memory — the transfer/provenance layer. This is a different problem: not "what operations exist on a memory store" but "how do I move an agent's memory from one model/runtime to a different one, and prove nothing was tampered with along the way." Its core structure is a five-component memory model with content-addressable entries linked in a Merkle-DAG provenance graph — a structure that lets a recipient check consistency and signed provenance claims; it cannot prove that the original statements or claimed sources were truthful. Access control is capability-based, enabling selective, scoped disclosure (share only the procedural-memory subset, not the episodic one, for instance). The most operationally interesting piece is the injection-resistant rehydration protocol: importing memory into a target model isn't a raw content copy, it's an adaptation step designed to prevent recalled content from carrying an indirect prompt injection into the new context. Serialization is JSON-first with optional CBOR compaction for transport efficiency, and PAM v1 §5.1 reports a 50-task pilot: Claude 3.5 Sonnet → GPT-4 Turbo, GPT-4 Turbo → Gemini 1.5 Pro, and Gemini 1.5 Pro → Claude 3.5 Sonnet. The task set comprises 15 coding-continuation, 20 Q&A-recall, and 15 planning tasks. This is preliminary evidence for those pairs, not validation of Llama transfer or arbitrary model combinations. The 54 SDK tests described separately in §4.2 validate implementation behavior; they are not 54 cross-model transfer trials.

IETF PAMSPEC — the architecture/data-model layer. draft-infantado-agent-memory-architecture-00 is the most abstract of the four and explicitly scopes itself as architectural vocabulary rather than a wire protocol. Its central move is separating a Compute Plane (model inference, planning, tool execution — inherently ephemeral and swappable) from a Persistent State Plane (authoritative, versioned Memory Objects, provenance, lifecycle state, and an append-only Event Ledger) plus a layer of Derived Indexes (embeddings, lexical indexes, caches) that are explicitly non-authoritative and regenerable — meaning indexes are rebuilt from the available authoritative memory state, subject to retention and deletion rules. In §§7.6–7.7, canonical state includes objects, versions, metadata, provenance, snapshots, and ledger entries. The Event Ledger records operations and is distinct from object revision history; it need not hold all content needed to regenerate an index. It defines eleven conformance profiles from PAMSPEC-Lite (minimal) up to PAMSPEC-Evaluation (deterministic replay), doesn't mandate a specific transport (HTTP, MCP, or an embedded library binding are all acceptable), and bakes in explicit scope enforcement to prevent unscoped global semantic search by default — a governance concern showing up at the architecture level rather than left to policy. It carries the standard IETF individual-submission disclaimer (no working-group backing, no formal standing, expires January 2027). Its architectural compatibility with another proposal would still need a concrete mapping and tests; a conceptual overlap is not implemented interoperability.

W3C AI Agent Memory Interoperability CG — the governance/conformance layer. The adopted charter and July 29 notice retain draft-saihm-memory-protocol-01 as the normative reference. Profiles, use cases, and conformance tests build on that protocol rather than whichever wire format wins. The referenced scope includes post-quantum identity and cryptographic erasure; the group's deliverables are Community Group Reports, not W3C Recommendations. The July notice lifts only this group's own §2.1 restriction after SAIHM's Independent Submission consideration concluded. It explicitly leaves the group's above-protocol posture unchanged; it does not describe a field-wide prohibition being lifted. Its GDPR alignment goal is not a legal finding that the construction suffices for every erasure request.

3. Where They Overlap, and Where They're Actually Solving Different Problems

Laid side by side, the four efforts look more like a stack than four competitors, but only if someone eventually wires them together:

LayerEffortCore question it answers
Operations / wire formatmemorywireWhat verbs exist on a memory store, and what's the request/response shape?
Transfer / provenancePortable Agent MemoryHow do I move memory between different models and prove it wasn't tampered with?
Architecture / data modelIETF PAMSPECWhat is a Memory Object, independent of any specific vendor's implementation?
Governance / conformanceW3C AI Agent Memory Interop CGWhat does "interoperable" mean well enough to test for, and how do erasure and identity work across vendors?

Deletion exposes the different scopes. memorywire supplies a forget operation and studies poisoned-record recovery, including the entangled class just described. PAM supplies tamper-evident transfer, which by itself neither proves the truth of content nor erases all its descendants. PAMSPEC separates lifecycle and validation and explicitly requires independent propagation of derived-index deletion in §7.7. The W3C group's SAIHM-based profiles address cryptographic-erasure mechanisms. It is therefore incorrect to credit only that group with recognizing the distinction between a canonical record and derived information.

Where they genuinely diverge rather than overlap: memorywire and PAMSPEC are optimizing for different failure modes. memorywire is pragmatic and adapter-driven — it exists to let one agent talk to five different concrete backends today, and its conformance suite (68 PASS / 12 SKIP / 0 FAIL) identifies adapter limitations in the skipped cases. PAMSPEC is closer to a formal ontology — it's less interested in "can I call mem0 through this" and more interested in "is there a vendor-neutral definition of what a memory is that survives any single vendor's implementation choices going away." A system could plausibly speak memorywire on the wire while being internally organized along PAMSPEC's Compute Plane / Persistent State Plane split; that combination remains an integration proposal rather than a tested result here.

4. Erasure Must Follow Copies and Derivations

Cryptographic erasure can make ciphertext inaccessible when all usable copies of the protecting key are irrecoverably destroyed and the encryption construction remains secure. Its boundary is the data actually protected by that key. Recoverable key backups, plaintext copies, separately encrypted records, cached summaries, and independently stored embeddings require their own treatment. A tombstone or content-address blacklist may help prevent reuse within systems that enforce it; neither reaches arbitrary downstream copies automatically.

GDPR Article 17 sets out conditions and exceptions for erasing personal data. A protocol charter's alignment claim does not establish compliance for an implementation. The relevant question is what applicable personal data remains accessible across the actual processing system, not merely whether one key was deleted.

Some propagation can be engineered using reliable lineage. For example, a deployment could delete an affected retrieval index entry and regenerate a summary from retained, permitted sources. PAMSPEC's separate canonical and derived-state deletion rules explicitly recognize this work. The harder case is an unknown or inseparable influence: a fact mixed into an untraceable summary or learned in model parameters. A wire-level forget acknowledgment does not prove those effects have been reversed.

A practical erasure workflow therefore identifies the canonical record, its known derivatives, independent copies, and key backups; blocks future retrieval and derivation as appropriate; remediates the affected artifacts; and verifies the relevant stores. A regenerated summary should retain only permitted information and be reviewed for residual influence. Where lineage is missing, record that uncertainty and investigate instead of equating a successful source deletion with complete erasure. This is an engineering boundary analysis, not a tested compliance procedure.

5. Importing Memory Is Importing Attack Surface

Memory is retained for future use, so an injected instruction can outlive the interaction that introduced it. Persistence increases the duration of an attack opportunity; it does not make the content inherently trustworthy. Retrieval policies should distinguish remembered data, authoritative instructions, and unverified assertions.

Anthropic's own memory-store documentation states this plainly, in a warning that's unusually direct for API docs: a store attached with read_write access, if the agent processes untrusted input (user prompts, fetched web content, third-party tool output), can have malicious content written into it by a successful prompt injection — and later sessions then read that content as trusted memory. That's the exact mechanism the injection-resistant rehydration step in the Portable Agent Memory protocol is built to interrupt: when memory crosses a trust boundary (a different model, a different vendor, a different agent), the recall step needs to treat the incoming content the way a sane system treats any other externally-sourced input — subject to the same skepticism a fresh tool result would get, not elevated to "prior established fact" purely because it arrived via the memory channel rather than the tool-call channel. memorywire's optional HITL governance channel is the same problem attacked from the write side rather than the read side: put a human in the loop before an agent-generated memory becomes durable, rather than trying to sanitize it perfectly on the way back out.

A portable format can carry malicious text just as it carries benign text. In a deployment where migration previously required manual review, automating import could remove that review step unless it is deliberately retained. That is a conditional risk, not evidence that existing exporters provided a universal security barrier. Provenance checks, constrained interpretation, scoped access, and human review each address different parts of the problem; no one of them establishes complete protection.

6. The Skeptical Read: This May Be Premature Standardization, Not Premature Optimization

An interoperable request shape is useful even before every aspect of memory quality is settled. The adoption risk is confusing different forms of evidence. LoCoMo and LongMemEval v1 evaluate conversational memory; LongMemEval explicitly includes temporal reasoning among its five abilities and reports time-aware retrieval results in §5.4. It also covers knowledge updates and abstention, so dismissing it as simple fact recall understates its scope. Those evaluations do not by themselves test end-to-end procedural task execution after a vendor migration, cross-agent write consistency, or recovery from poisoned durable memory. A migration assessment needs additional, task-specific evidence for those properties.

The source scopes support a measured adoption decision: memorywire reports 68 PASS / 12 SKIP / 0 FAIL in its adapter matrix and a remaining entangled-poison recovery limitation; PAM reports a small transfer pilot; PAMSPEC is an individual Internet-Draft; and a W3C Community Group Report is not a W3C standard. These facts justify testing a chosen interface against a concrete use case while keeping the mapping replaceable. They do not support a prediction that one effort must win, or a fixed timetable for convergence. Multiple layers could coexist if implementations demonstrate compatible semantics.

7. What This Means for a Small, Multi-Runtime Agent Operation

Consider a hypothetical small operator with user notes, project facts, and session-derived summaries. Separating those categories can help route reads and writes, but a directory layout does not prove record-level provenance, lifecycle metadata, or export fidelity. A useful preparation sequence is:

  • Choose an actual migration task before adopting a specification. A bounded adapter experiment may be worthwhile; avoid making an untested draft the sole authority for persistent state. Keep the source data and mapping recoverable while evaluating the target.
  • Capture metadata at write time. Record the applicable user/project scope, known source identifier, author or generating process, timestamp, and lifecycle state. Distinguish an observed fact from an inferred summary. These are practical design recommendations, not a claim that all four proposals mandate identical fields.
  • Handle legacy provenance honestly. Consolidation may attach verifiable sources that still exist, preserve explicit links from outputs to inputs, and flag unknown history. Summarizing old text cannot reliably reconstruct missing sources or permissions. Do not manufacture confident lineage to make an export appear complete.
  • Test what survives a round trip. Export a bounded set, import it into the proposed target, and compare content, scope, versions, access rules, and deletion behavior. Then evaluate the agent's ability to use the migrated material on the intended tasks. List fields the target cannot represent; a successful JSON parse is insufficient evidence.
  • Review consolidation and imported content at the trust boundary. A signature verifies an authenticated assertion, not safe instructions. Treat recalled external text as data, constrain write access, and preserve the ability to quarantine a poisoned record. Track derived artifacts so later correction or deletion can reach them.

An operator can adopt these practices without waiting for a universal format. Whether to implement one of the proposals depends on demonstrated compatibility with the required source and target, not on the number of standards-related initiatives in the field.

References / Sources