en2026-03-22

Completing the Agent Stack: AMCP and Memory Continuity

Most agents look impressive right up until the session ends.

They can call tools. They can understand context. They can even collaborate with other agents.

But once the runtime changes, the client changes, or the session ends, memory usually resets inside the product that held it.

That is the gap AMCP is meant to close.

The missing layer

The agent infrastructure stack is starting to separate into three clearer categories.

MCP: tools
A2A: collaboration
AMCP: memory

MCP defines how agents connect to tools and data sources. A2A defines how agents delegate and collaborate with other agents. AMCP defines how agents preserve continuity across sessions, runtimes, and clients.

These layers do not compete with each other. They reinforce each other.

An agent can use MCP to access tools, A2A to work with specialists, and AMCP to remember what still matters later.

What AMCP standardizes

AMCP, the Agent Memory Continuity Protocol, is an open protocol for portable long-term agent memory.

It is not a model protocol. It is not a prompt format. It is not a reasoning framework.

It is a memory contract.

AMCP v0.1 defines:

a normalized memory record shape
standard record types
HTTP operations for remember, recall, sessions, export, import, and delete
scope and provenance fields
retention and deletion semantics
compatibility mapping for existing systems

The goal is not to force every memory system to rewrite itself. The goal is to create a stable interoperability layer that real systems can adopt.

A concrete example: Claude Channels + Nexus

The distinction becomes clearer in an actual workflow.

Claude Channels lets a running Claude session receive external events. That changes the interaction model. The agent no longer has to wait for a user sitting in front of a terminal. Messages can arrive asynchronously.

But Channels alone does not provide long-term memory.

We tested the combination of Claude Channels and Nexus with a simple flow:

start Claude with the official fakechat channel
send a message through the channel: "Remember this fact: the project keyword is blue-heron"
Claude calls nexus_remember and stores the fact in Nexus
Claude replies through the same channel
fully restart Claude
in the new session, ask: "What was the project keyword I asked you to remember earlier?"
Claude calls nexus_recall, retrieves the memory, and answers correctly: blue-heron

That proves two different things:

Channels provides reachability. External messages can reach a live session.
Nexus provides memory. The fact can be recalled after the session restarts.

Reachability and memory are not the same thing. Channels alone does not solve continuity. You still need a separate memory layer.

Why this matters now

Agents are moving from prototypes into production systems. In production, continuity matters.

users expect agents to remember prior conversations
teams need memory that works across tools
products need memory that does not stay locked inside a single vendor

Right now, most products build their own memory layer. It is temporary, incompatible, and usually closed.

AMCP offers an alternative: a shared standard for agent memory.

Closing

MCP gives agents tools. A2A gives agents collaboration. AMCP gives agents memory continuity.