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, anddelete - 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
fakechatchannel - send a message through the channel: "Remember this fact: the project keyword is blue-heron"
- Claude calls
nexus_rememberand 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.
More than a document
A protocol is not real just because it is written down. It becomes real when people can implement it, verify it, and compare behavior across systems.
AMCP already has working reference pieces:
- Nexus: the reference server
@nunchiai/amcp-sdk: SDK for direct integration@nunchiai/nexus-mcp: MCP bridge@nunchiai/reference-agent: reference client
Standards are not proven by text alone. They are proven by running systems.
Closing
MCP gives agents tools. A2A gives agents collaboration. AMCP gives agents memory continuity.
If you are building agents that need continuity across sessions, runtimes, and clients, AMCP is the missing layer the stack has needed.