Most agents look impressive right up until the session ends.
They can call tools. They can reason over the context they were given. They can even collaborate with other agents. But when the runtime changes, the client changes, or the session ends, memory often stays trapped inside the product that held it.
That is the gap AMCP is meant to close.
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.
The missing layer
The agent infrastructure stack is starting to look more clearly layered.
- MCP is the standard for tools
- A2A is the standard for agent collaboration
- AMCP is the standard for memory
MCP helps agents connect to tools and data sources. A2A helps agents delegate work and collaborate with other agents. AMCP helps agents preserve continuity across sessions, runtimes, and clients.
These are not competing layers. They reinforce each other.
An agent can use MCP to access tools, A2A to work with specialist agents, and AMCP to keep the memory that still matters later.
Why memory needs its own protocol
Most agent memory today is still trapped inside a specific product.
The result is familiar:
- memory stays locked inside one client
- context disappears when the session ends
- continuity breaks when you move to another system
- users have to repeat the same preferences and decisions
The problem is not that agents are not smart enough. The problem is that memory is not portable.
AMCP is meant to standardize the part that keeps breaking.
- canonical memory records
- remember / recall operations
- scope and provenance
- retention and delete semantics
- export / import portability
What AMCP standardizes
AMCP v0.1 defines a small but practical baseline.
- a canonical memory record shape
- standard record types
- HTTP operations for remember, recall, sessions, export, import, and delete
- soft delete semantics
- compatibility mapping for existing systems
The goal is not to force every memory system to rewrite itself immediately. The goal is to create a stable interoperability layer that real systems can adopt.
A simple example
Imagine an agent planning a trip.
- The agent recalls the user's prior preferences through AMCP.
- It calls search or booking tools through MCP.
- If needed, it delegates a subtask to another agent through A2A.
- It stores the outcome back through AMCP.
In that flow:
- MCP handles tool access
- A2A handles collaboration
- AMCP handles continuity
That is the role AMCP is supposed to play.
It should not stay as a document only
A protocol becomes real only 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 and install path@nunchiai/reference-agent: reference client
That matters because standards are not proved by wording alone. They are proved by running systems.
What is public now
The public AMCP repository includes:
- the protocol draft
- current implementation status
- the OpenAPI surface
- an adoption guide
- reference implementation notes
- examples and compliance guidance
What comes next
What matters now is not another declaration. It is making adoption easier.
That means:
- better examples
- stronger compliance tooling
- more outside implementations
- community feedback on the public draft
If OAuth helped standardize authentication and authorization, AMCP can help standardize continuity for agent memory.
Closing
MCP gives agents tools. A2A gives them collaboration. AMCP gives them memory.
If you are building agents that need continuity across sessions, runtimes, and clients, AMCP is designed for exactly that.