Stateless MCP: Where Agent Memory Lives Now
TL;DR
- The 2026-07-28 MCP release candidate (locked 2026-05-21; final expected 2026-07-28) makes the protocol stateless: sessions, the
Mcp-Session-Idheader, and the handshake are deleted.- Cross-call context moves to explicit handles the model carries as ordinary arguments — what the spec calls "a
basket_id, abrowser_id."- A handle is transient continuity for one workflow; separate, durable memory for cross-session remembering still lives outside the protocol.
- Both MCP (by transport mechanics) and A2A (by opaque-agent principle) now externalize state, making a dedicated, addressable memory layer the presumed primitive.
What a protocol chooses to delete tells you more than what it adds. On 2026-05-21 the MCP maintainers locked a release candidate that does exactly that: it removes session state from the protocol layer. The RC, whose final specification is scheduled for 2026-07-28, declares: "The headline change is that MCP is now stateless at the protocol layer."¹ That single sentence moves agent-memory externality from a missing feature people lamented to a codified architectural decision.
A stateless protocol carries no server-held session state between requests; each message is self-contained, and the server treats every interaction as independent. A state handle is an explicit identifier a client passes as an ordinary argument — like a shopping-basket ID — so the server can resume context without storing anything in transport metadata. These two concepts sit at the center of the RC, and the difference between them is the difference between "continuing a task" and "remembering across sessions."
What the stateless MCP release candidate removes
The current stable specification is 2025-11-25. The session mechanics it carries forward are stated on the 2025-06-18 Streamable HTTP transport page: "A server using the Streamable HTTP transport MAY assign a session ID at initialization time, by including it in an Mcp-Session-Id header," and servers that require a session "SHOULD respond to requests without an Mcp-Session-Id header (other than initialization) with HTTP 400 Bad Request."² The RC deletes all of this.
- The
Mcp-Session-Idheader is removed. - The
initialize/initializedhandshake is removed. - Protocol version, client info, and capabilities travel in a
_metafield on every request; a newserver/discovermethod lets clients fetch server capabilities.¹
The practical effect: "any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments needed before are no longer required at the protocol layer."¹
The change was a deliberate direction, not a surprise. Five months before the RC was locked, in a transport-exploration post, the team wrote: "We envision a future where agentic applications are stateful, but the protocol itself doesn't need to be… We are looking at moving sessions to the data model layer, making them explicit rather than implicit."³ The RC is the concrete artifact of that intent.
MCP had already begun moving durable operations into explicit data. The 2025-11-25 release introduced an experimental Tasks primitive for work that starts now and is fetched later, recorded in the 2025-11-25 changelog.⁸ Durable work was pushed into the data model, not the transport — the same principle the RC now applies to sessions.
Explicit handles are not durable agent memory
The spec's prescribed replacement for cross-call context is stated directly:
"Servers that need to carry state across calls can do what HTTP APIs have always done: mint an explicit handle (a
basket_id, abrowser_id) from a tool and have the model pass it back as an ordinary argument on later calls."¹
A handle solves within-workflow continuity: one browser session, one checkout flow, one long-running data extraction that spans three tool calls. The server creates the handle, the model manages it, and the workflow stays coherent. But the handle is transient — it breaks when the workflow ends, when the handle expires, or when the model moves to a different scope.
Durable agent memory is the next layer. It persists across sessions, keyed by a stable identity (a user, a tenant, or the agent itself). It stores what the agent learned two weeks ago, the user's preferences, or the intermediate results of a half-finished plan that needs to survive a restart. The RC explicitly does not address this: it pushes session state to the data model through handles, but it leaves the storage, addressability, and retrieval of cross-session memory entirely to tools and external stores.
| State type | Purpose | Typical address | Expected lifetime |
|---|---|---|---|
| Request state | Complete one tool call | Request fields | One request |
| Workflow state | Continue work across calls | Explicit handle such as basket_id | One workflow or resource lifecycle |
| Durable agent memory | Recall knowledge across sessions and processes | Stable user, tenant, agent, or memory key | Independent of one MCP transport session |
Sathish Raju made the same distinction from a builder's standpoint: "When the model can see a handle, it can compose handles across tools, reason about them across steps, and hand them off between sub-agents. State hidden inside transport metadata never allowed any of that."⁴ Handles are a visibility win, but visibility does not equal durability.
Why MCP and A2A both leave memory outside the protocol
MCP is not alone in this direction. A2A v1.0.0 (tagged March 2026) defines agents as opaque peers: "Securely exchange information to achieve user goals without needing access to each other's internal state, memory, or tools."⁵ Its core assumption is "Opaque Execution: Agents collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations."⁵
The asymmetry is instructive. MCP now externalizes state by transport mechanics; A2A externalizes memory by principle. The RC physically removes the server-side bits that held state; A2A never assumed access to another agent's memory in the first place. Both roads converge: the protocol layer carries no durable memory, so that memory must be a separate, addressable primitive both sides reach through defined interfaces. That does not make the protocols incomplete. It defines their scope. The agent-memory interop gap describes what still needs to be standardized; the RC declares, by deletion, that MCP will not be where that standardization happens. How the two protocols compose along different axes is mapped separately in A2A vs MCP.
Operational consequence: memory becomes a tool-addressable store
Before the RC, running MCP horizontally meant either pinning sessions to specific instances (sticky routing) or building a shared session store that all instances could query. Both patterns created infrastructure coupling: the transport layer knew about state, and scaling decisions were constrained by state location.
After the RC, those constraints disappear. A request carrying only a handle and a _meta block can be served by any instance. The handle resolves to whatever data the server needs — but that data no longer sits in a session object tied to a particular process. It lives in a store the server queries when it receives the handle. Durable memory follows the same pattern: a stable identity key (not a transient handle) retrieves the accumulated context across any number of workflows and any span of time.
Serverless infrastructure is already aligned with this model. Cloudflare's Agents documentation treats a stateless MCP transport as the default; stateful behavior requires opting into Durable Objects, an explicit external store.⁶ Microsoft's Azure App Service team published a post titled "MCP Just Went Stateless — What the 2026 Spec Changes About Scaling on App Service."⁷ A serverless world where any request lands on any instance is a world where durable memory cannot live inside the protocol.
The analogy to HTTP cookies is useful but incomplete. In HTTP, a cookie carries a session ID; the server looks up server-side state. Stateless MCP pushes responsibility one step further: the value of the state handle is opaque to the protocol. It might be a database key, a signed token, or a reference to a memory snapshot — the protocol doesn't care. This is the architecture the December 2025 transport post previewed: "This direction mirrors standard HTTP, where the protocol itself is stateless while applications build stateful semantics using cookies, tokens, and similar mechanisms."³ The RC realizes the first half of that vision; durable cross-session memory built on the same handle-and-external-store pattern is the natural second half.
Common questions
Is MCP stateless now?
As of the release candidate (locked May 21, 2026; final expected July 28, 2026), MCP is stateless at the protocol layer. The final specification has not yet been published, and the release candidate can still change.
Did MCP remove sessions and the Mcp-Session-Id header?
In the release candidate, yes. The Mcp-Session-Id header, the protocol-level session, and the initialize/initialized handshake are all removed. Any request can land on any server instance.
If MCP no longer holds session state, where does agent memory live?
Outside the protocol. A server mints an explicit handle (like a basket_id) as an ordinary tool argument, and the model passes it back on later calls. Durable cross-session memory lives in a separate, addressable external store.
What is the difference between a state handle and durable agent memory?
A handle provides transient within-workflow continuity — it lets you resume a single logical task across multiple calls. Durable memory persists across sessions, keyed by a stable identity (user, tenant, or agent). The release candidate solves the first problem; it does not solve the second.
How do agents remember across sessions if the transport is stateless?
They use an external memory layer addressed by a stable key. The protocol itself supplies no shared session store.
Does A2A provide shared memory between agents?
No. A2A v1.0 specifies opaque execution: agents collaborate without access to each other's internal state, memory, or tools.
Sources
- MCP blog, "The 2026-07-28 MCP Specification Release Candidate," 2026-05-21. https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
- MCP Specification, Streamable HTTP Transport (2025-06-18). https://modelcontextprotocol.io/specification/2025-06-18/basic/transports
- MCP blog, "Exploring the Future of MCP Transports," 2025-12-19. https://blog.modelcontextprotocol.io/posts/2025-12-19-mcp-transport-future/
- Sathish Raju, "MCP Killed the Session — Here's Why That's a Big Deal," Medium, 2026-06-02. https://medium.com/@sathishkraju/mcp-killed-the-session-heres-why-that-s-a-big-deal-4e484b331c27
- A2A Specification v1.0.0 (tagged March 2026) and v1.0 announcement. https://a2a-protocol.org/latest/specification/ · https://a2a-protocol.org/latest/announcing-1.0/
- Cloudflare Agents docs, MCP Transport, ~2026-06-03. https://developers.cloudflare.com/agents/model-context-protocol/transport/
- Microsoft Azure App Service blog, "MCP Just Went Stateless — What the 2026 Spec Changes About Scaling on App Service." https://techcommunity.microsoft.com/blog/appsonazureblog/mcp-just-went-stateless--what-the-2026-spec-changes-about-scaling-on-app-servic/4530222
- MCP blog, 2025-11-25 anniversary release, and MCP Specification 2025-11-25 changelog. https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/ · https://modelcontextprotocol.io/specification/2025-11-25/changelog
Related
- Agent-memory interop gap
- A2A vs MCP: how they differ and compose
- Memory-MCP: five questions to evaluate a memory server
- Shared memory for multi-agent systems
- Memory MCP servers compared
- MCP Federation in 2026: gateways, auth, and topology
Edward Izgorodin · Mnemoverse Library · last updated 2026-07-21