Stateless MCP: Where Agent Memory Lives Now
TL;DR
- The final 2026-07-28 MCP specification makes modern requests stateless: protocol sessions, the
Mcp-Session-Idheader, and the initialization handshake are removed.- 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. The final 2026-07-28 MCP specification removes protocol-level sessions and makes modern requests stateless and self-contained.¹ That turns agent-memory externality from a missing feature people lamented into a codified architectural boundary.
A stateless protocol carries no server-held protocol session between modern requests; each request declares its version and capabilities in _meta. A state handle is an explicit identifier a client passes as an ordinary argument — like a shopping-basket ID — so the server can resume application context without storing it in transport metadata. These two concepts sit at the center of the final revision, and the difference between them is the difference between "continuing a task" and "remembering across sessions."
What the final stateless MCP revision removes
The previous 2025-11-25 revision carried forward session mechanics documented in the 2025-06-18 Streamable HTTP transport: a server could assign an Mcp-Session-Id during initialization and require it on later requests.² The final 2026-07-28 revision deletes that protocol-level session model.
- The
Mcp-Session-Idheader is removed. - The
initialize/notifications/initializedhandshake is removed for modern requests. - Protocol version, client info, and capabilities travel in a
_metafield on every request; a newserver/discovermethod lets clients fetch server capabilities.¹
The practical effect is that modern requests no longer depend on a protocol session tied to one server instance. Sticky routing and shared session stores may still exist for application data, but MCP no longer requires them as transport mechanics.¹
The change was a deliberate direction, not a surprise. A December 2025 transport-exploration post proposed moving sessions from implicit transport metadata into the data model as explicit application state.³ The 2026-07-28 specification is the concrete artifact of that intent.
MCP had already begun moving durable operations into explicit data. The 2026-07-28 revision moves Tasks out of the core protocol into an official opt-in extension with pollable task handles.⁸ Durable work is represented in the data model, not a hidden transport session — the same principle the final revision applies to cross-call application state.
Explicit handles are not durable agent memory
For cross-call application state, the final changelog points servers to explicit, server-minted handles passed back as ordinary tool arguments.¹
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 final specification explicitly supports application-managed 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. MCP 2026-07-28 removes the protocol-level session from modern requests; 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 final MCP revision makes clear that durable memory is not hidden transport state. 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 2026-07-28 revision, running session-based 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.
Under the modern 2026-07-28 protocol, those constraints disappear at the protocol layer. A request carrying per-request _meta and any application handle can be served by any compatible instance. The handle resolves to whatever application data the server needs — but that data no longer sits in an MCP session object tied to a particular process. Durable memory follows the same explicit-state pattern: a stable identity key (not a transient handle) retrieves accumulated context across workflows and 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 can carry a session ID; the server looks up server-side state. Stateless MCP pushes responsibility one step further: the value of an application handle is opaque to the protocol. It might be a database key, a signed token, or a reference to a memory snapshot — the protocol does not care. The December 2025 transport post previewed the same separation between a stateless protocol and stateful application semantics.³ The final revision realizes the protocol half of that design; durable cross-session memory built on explicit handles and stores is the application half.
Common questions
Is MCP stateless now?
Yes for the modern 2026-07-28 protocol revision. Requests are stateless and self-contained, with protocol version and capabilities carried per request. Earlier revisions remain initialization-based, and dual-era implementations may support both.
Did MCP remove sessions and the Mcp-Session-Id header?
Yes in the 2026-07-28 revision. The Mcp-Session-Id header, protocol-level sessions, and the initialize/notifications/initialized handshake are removed from modern requests.
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 2026-07-28 revision makes the first mechanism explicit; it does not standardize the second, and The AI Agent Memory Crisis explains why bigger context windows do not solve it either.
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 Specification, "Key Changes" for the final 2026-07-28 revision. https://modelcontextprotocol.io/specification/2026-07-28/changelog
- 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 Tasks extension, 2026-07-28. https://modelcontextprotocol.io/extensions/tasks/overview
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-08-29
— Mnemoverse is a persistent-memory API for AI agents. Free key: console.mnemoverse.com · Plans and limits · Docs: Getting Started