AI Agent Memory Should Be Portable Before It Is Hosted#

Most teams add memory to an agent the same way they add any other early feature: they pick the simplest thing that works and keep moving. A conversation summary table in Postgres. A preferences blob on a user record. A workflow_state document in a hosted backend. A customer_summary.json file written by the app itself.

That is the right call at prototype time.

The trouble starts when the durable state needs to move. A second agent needs the same customer record shape. A template wants to declare the memory structure it expects. A Python app installs an agent package and wants to inspect its memory dependencies. Another team wants to adopt the same workflow and needs to know what records they are supposed to create before anything can run.

Then the hidden assumptions show up. Field names were never documented. Scope keys like user, conversation, or repository exist only in code. Lifecycle behavior lives in a wiki page or in someone's head. A schema update that looked harmless last week turns stored state into unreadable baggage this week.

Before memory can be portable, its shape has to be portable.

When agent memory escapes the app that made it#

Agent memory usually starts as app-local state because that is the fastest path to something useful.

It often looks like this:

customer_summary.json
conversation_state table
last_seen_context field
preferences blob
support_notes column
workflow_state record

Every one of those is a reasonable starting point. None of them explains itself to a third party.

The problem appears the moment memory crosses an app boundary. A second agent needs the same durable state and has to guess the schema. A template wants to declare the memory shape it expects, but there is no declared shape. An SDK app loads an installed agent and finds a dependency on memory, but there is no contract to inspect. A team wants to version the schema and has no baseline to version against. Two apps keep reading and writing "the same" state. Assumptions drift. Nobody notices until something breaks.

This is not theoretical. Teams that run long-lived agent workflows discover quickly that stored state written yesterday can become unreadable tomorrow if schema changes are not versioned and bounded.[5] Add one field to a table that three agents depend on, change the meaning of another, and in-progress work stops behaving predictably. The storage backend did its job. The contract layer never existed.

The failure is not that a team used JSON, Postgres, Redis, or a document database. The failure is that the memory only made sense inside the app that created it.

Agent memory that only makes sense inside one app is not portable memory. It is app-local state.

A memory store saves records; a memory contract explains what they mean#

Storage and contract are different concerns. Early agent systems often blur them because a single app can get away with it.

A memory store answers operational questions:

• where records live
• how they are written
• how they are fetched
• how they are indexed
• how they are deleted
• what backend is being used

A memory contract answers structural questions:

• what record types are valid
• what each record type means
• what scope keys are expected
• what spaces organize records
• what retention rules apply
• what lifecycle operations are expected
• what governance annotations matter
• what schema downstream code can rely on

Those are not the same questions.

Storage variety is fine. It is expected. Teams use Postgres, document databases, object stores, vector stores, framework-managed state, and hosted memory systems. None of that conflicts with portability. The portability question sits above the backend question: whatever stores the records, can another system understand what those records are supposed to mean?

The gap is visible across the field. In May 2026, a W3C community group was proposed around AI agent memory interoperability, with scope covering memory cell shape, sharing contracts, identity binding, and cryptographic erasure.[1] Around the same time, research on portable agent memory proposed a protocol for cryptographically verified transfer across heterogeneous agents.[2] A survey of LLM agent externalization patterns — covering memory, skills, protocols, and harness engineering — shows the same gap from a research lens: memory structure remains an active, unsettled layer.[4]

None of that means the industry has converged on an answer. The problem is real enough that multiple groups are circling it from different directions.

A support agent makes the distinction concrete. The storage layer might be a Postgres table. Fine. The contract should still say something like this:

record type: customer_state
scope: organization + customer
space: support
fields: plan, lifecycle stage, known issues, escalation history, last contact summary
retention: keep while customer relationship is active
lifecycle: create, update, summarize, archive

The exact field list is not the point. A second system should be able to read the contract and know what it is looking at without reverse-engineering the original application.

The first portability problem in agent memory is not where records are stored. It is whether another system can understand what those records mean.

When AI agents share memory without a contract#

The contract problem gets sharper in multi-agent and cross-team systems.

Once more than one agent reads or writes durable state, memory stops being a private implementation detail. It becomes shared infrastructure whether the team planned for that or not. Research on multi-agent memory architectures identifies the same tension: shared memory makes knowledge reuse tractable, but without coherence support, agents end up overwriting each other, reading stale state, or depending on inconsistent versions of shared facts.[3]

That is a runtime consistency problem. It is also a legibility problem before runtime: if the receiving app cannot inspect the contract, it cannot determine which record types, scope keys, or retention rules apply before a single record is written.

Tool interoperability got better when systems stopped treating tool contracts as implicit. MCP made tool access explicit. A2A made inter-agent communication explicit. Memory structure still falls outside what any of those protocols express. The pattern holds: making implicit agent contracts explicit keeps paying off, and memory shape is the layer still lagging.

A database table tells you where memory is stored. A memory contract tells you what the agent believes that memory represents.

Durable agent memory belongs in the artifact graph#

If durable state affects how an agent behaves, its expected shape should be visible in the artifact graph.

The artifact model:

Tool        = executable capability
Skill       = procedural know-how
Knowledge   = prepared retrieval context
Memory      = durable state contract
Agent       = composition and orchestration
Template    = starter system

Engineers already understand why tools deserve a package boundary. The same logic extends cleanly once procedure, context, and state become reusable dependencies instead of app-local details.

If memory is absent from the graph, the receiving app has to guess:

• what record types to create
• what schemas to use
• which scopes matter
• what lifecycle states exist
• what retention rules are expected
• what parts of state are durable

Lockfiles make the point sharper. If a lockfile records tools, skills, knowledge, and agents, it can record memory too. An installed agent's memory expectations should be inspectable, not buried in an install directory. The expected memory shape belongs in the same install surface as everything else the agent depends on.

If a dependency matters, it should be visible. If durable state matters to the agent, its contract should travel with the agent.

Packaging agent memory: a boundary, not a backend#

The first useful move is to package memory, not to host it.

That is what Memory Blueprints are for in AgentPM. They package the contract layer that durable state depends on:

• scopes
• record types
• spaces
• retrieval modes
• retention rules
• constraints
• lifecycle operations
• triggers
• governance annotations
• generated resolved record contracts

The list is not the point. AgentPM gives each of these things a lifecycle:

authored → validated → built → inspected → published → installed → locked → loaded

That lifecycle turns a memory convention into a reusable dependency. In AgentPM, that means:

• agentpm init --kind memory scaffolds a starter blueprint
• agentpm memory build generates resolved record contracts from authored schemas
• agentpm memory inspect reports whether a package is fresh, stale, invalid, or not built
• agentpm publish rejects stale or missing generated output
• Node SDK apps can call loadMemory() and loadMemoryContract()
• Python SDK apps can call load_memory() and load_memory_contract()
• agents and templates can declare Memory dependencies that get resolved, locked, installed, and inspected like the rest of the artifact graph

Memory Blueprints are not a hosted store. They are not a CRUD surface. They are not a managed persistence layer. They are not a lifecycle execution engine. The CLI builds the contract. The registry stores and surfaces it. The SDK loads it. Where records actually live is still the host application's decision.

That is the point.

AgentPM Knowledge packages retrieval corpora without trying to become a hosted retrieval platform. Memory Blueprints follow the same discipline: they package durable state contracts without pretending AgentPM owns the storage layer.

Add Memory and the artifact model is complete:

Tools package actions.
Skills package procedures.
Knowledge packages context.
Memory packages durable state contracts.
Agents compose those artifacts.
Templates bootstrap working systems from them.

Portable agent systems need more than portable tool calls. They need portable procedure, portable context, and portable memory shape. Memory should be portable before it is hosted, because durable state is part of the agent system, and before memory records can move cleanly across agents, apps, runtimes, or teams, their shape has to move first.

Sources#

1. W3C AI Agent Memory Interoperability Community Group. https://www.w3.org/community/ai-agent-memory-interop/

2. Portable Agent Memory: A Protocol for Cryptographically-Verified Memory Transfer Across Heterogeneous AI Agents. https://arxiv.org/abs/2605.11032

3. Multi-Agent Memory from a Computer Architecture Perspective: Visions and Challenges Ahead. https://arxiv.org/html/2603.10062

4. Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering. https://arxiv.org/html/2604.08224v1

5. Why AI Agent Memory Architectures Break in Production and How Engineering Teams Fix Them. https://www.javascriptdoctor.blog/2026/07/why-ai-agent-memory-architectures-break.html