Your Harness Will Change. Your Memory Shouldn't.

There's a growing conversation about agent memory, and I think it's asking the wrong question.

Sarah Wooders (CTO of Letta) recently wrote that "memory isn't a plugin — it's the harness." Harrison Chase (CEO of LangChain) followed up arguing that if you don't own your harness, you don't own your memory. Both are right about the problem. Both are wrong about the solution.

The Problem They Identified

The diagnosis is spot-on. Anthropic's Managed Agents puts everything behind an API — your agent's memory locked into their platform. OpenAI's Codex generates encrypted compaction summaries that are unusable outside their ecosystem. When model providers own your memory, switching costs become prohibitive.

Harrison tells a revealing story: his email assistant got accidentally deleted, and rebuilding it from the same template produced a dramatically worse experience. All the learned preferences, tone, context — gone.

This is a real problem. Memory is what makes an agent yours. Without it, any agent is trivially replaceable.

Where I Disagree

Sarah's solution: embed memory deeper into the harness. Harrison's solution: make the harness open source.

Both assume memory and harness are inseparable. I don't think they are. I think conflating two distinct responsibilities is what creates the lock-in problem in the first place.

When Sarah lists the "invisible decisions" a harness makes — what survives compaction, how context is loaded, what's queryable — she's describing two things at once:

Context management: what goes into the prompt, how to budget tokens, when to compact, how to present tool results. This is genuinely the harness's job.

Memory persistence and recall: storing knowledge across sessions, retrieving relevant history, maintaining continuity across tools and workflows. This can — and should — be a separate layer.

The harness decides what to remember. The memory layer decides how to store and retrieve it. These are different concerns with different lifecycles.

Why Separation Matters

Harnesses are ephemeral. Claude Code, Cursor, Windsurf, Codex, Aider — the landscape shifts every few months. If your memory is embedded in your harness, every migration means starting over. Harrison's deleted email agent is the mild version. The severe version is an enterprise that built six months of agent knowledge into a harness that gets deprecated.

An open-source harness doesn't fully solve this either. Deep Agents stores memory in Mongo/Postgres/Redis plugins — but the memory schema, the recall logic, the atom structure are all Deep Agents-specific. Migrate to a different harness and you're writing custom ETL to port your knowledge, assuming the target harness can even interpret it.

What you actually want is a memory contract that any harness can speak.

AMCP: The Memory Protocol

This is why I built AMCP (Agent Memory Continuity Protocol) — an open standard for agent memory, positioned alongside MCP (tools) and A2A (agent collaboration) as the third layer of agent infrastructure.

AMCP defines a vendor-neutral contract for how agents store and recall memory. One item shape. One recall interface. One export format. Any harness that speaks AMCP can read and write to any AMCP-compatible backend.

The spec is at github.com/goldberg-aria/amcp under Apache 2.0.

3122: Proving the Architecture

Theory is cheap. To prove that separated memory can be as deeply integrated as embedded memory, I built 3122 — an AMCP-native, model-neutral coding harness.

3122 makes a deliberate architectural split:

Continuity Runtime State (harness-owned, stays local):

• Session transcripts
• Trajectory state (goal → attempt → failure → verification → next-step)
• Handoff snapshots for model switching
• File-level working memory
• Skill candidate detection from repeated workflows

Portable Memory (AMCP-owned, transferable):

• Uses one AMCP item shape across all backends
• local-amcp: SQLite on your machine
• nexus-cloud: hosted backend over Nexus
• third-party-amcp: extension slot for any AMCP-compatible service

The harness makes all the context decisions Sarah describes — what to include in the prompt, how to budget tokens when sessions get long, what to keep during compaction. But the results of those decisions flow into AMCP as portable memory items.

Here's what that enables:

# Export your memory
3122 memory export --format amcp-jsonl --output my-knowledge.jsonl

# Move to a hosted backend
3122 memory migrate --from local-amcp --to nexus-cloud

# Delete the workspace, set up fresh, reconnect — memory intact
3122 memory recall 10

Your harness instance can die. Your memory survives.

The repo is at github.com/goldberg-aria/3122-harness.

Addressing the "Depth" Concern

The strongest version of Sarah's argument is that a separated memory layer can't be as deeply integrated as an embedded one. 3122's design specifically counters this.

Trajectory-aware recall: When you're mid-task, recall prioritizes atoms related to your active trajectory — the files you're touching, the errors you've hit, the verification steps you've run. This isn't generic similarity search. The harness's operational context shapes what gets recalled.

Budget-aware context: Long sessions degrade gracefully. As context budget shrinks, 3122 drops conversation recall first, then older memory, then recent history, then instructions — in that order. The memory layer doesn't need to be embedded to participate in this; it needs to receive budget signals.

Handoff continuity: When you switch models mid-session (/model claude-sonnet-4-20250514 → /model gpt-4.1), 3122 stores a handoff snapshot and gives the new model a temporary context boost on its first turn. The portable memory layer provides cross-session continuity; the harness provides within-session continuity. Clean separation, full coverage.

Compaction without loss: When the harness compacts context, it can emit what was dropped as a signal to the memory layer. Nothing is silently lost. The harness's "invisible decisions" become visible — and recoverable.

The Lock-In Argument, Inverted

Harrison argues that memory creates lock-in, and that's why you need open harnesses. I'd invert it: memory creates lock-in precisely because it's coupled to the harness.

Decouple memory from the harness, standardize the protocol, and lock-in disappears. You can use Claude Code today, switch to Cursor tomorrow, try Codex next week — and carry your accumulated knowledge with you. Not because all these harnesses are open source, but because they all speak AMCP.

This is the same pattern that made the web work. HTTP didn't require open-source browsers. It required an open protocol that any browser could implement. AMCP is that protocol for agent memory.

The Ecosystem

The current stack:

Nexus is the first hosted backend. But AMCP is designed so anyone can build a backend — or so any harness can become a client. The goal isn't to replace Claude Code or Deep Agents. It's to give every harness a memory layer that outlives it.

What I'm Building Next

The separation works. The next step is making the boundary richer:

• Trajectory auto-promotion: successful work patterns automatically become portable memory atoms, no manual save required
• Budget-negotiated recall: the harness tells the memory backend "I have 2000 tokens of budget, give me the most critical atoms" instead of fetching and truncating
• Compaction checkpoints: when the harness compacts, it tells AMCP what was dropped, making the invisible visible
• Capability advertisement: AMCP backends declare what they support, so minimal implementations still work while full implementations get the advanced features

Try It

• AMCP spec: github.com/goldberg-aria/amcp
• 3122 harness: github.com/goldberg-aria/3122-harness
• Nexus backend: coming soon at nunchiai.com

Memory should be yours. Not your harness vendor's, not your model provider's. Yours.