MCP Just Went Stateless: How to Keep Your Agent's Memory Across Sessions (2026)

Sessions are gone at the protocol layer

The initialize/initialized exchange has been retired. Servers may optionally implement a new server/discover RPC for capability discovery, but it is not required. Nothing in the request path assumes a prior handshake, and nothing on the wire ties one request to the last one.

The specification is direct about what this does and does not mean: "Dropping the protocol-level session doesn't force your application to be stateless. If your server needs to carry state across calls, mint an explicit handle from a tool and have the model pass it back as an argument."

Read that twice. The protocol has handed state back to you, and it has told you the mechanism: an explicit handle, passed by the model, understood by your application. A handle is a pointer. Whatever the pointer points at is the part you still have to build.

What got added around statelessness

The release is not only a subtraction:

• Multi Round-Trip Requests (MRTR) let a server make requests back to the client mid-execution without a persistent connection.
• Header-based routing via Mcp-Method and Mcp-Name lets gateways filter and route without parsing JSON bodies.
• Cacheable list results add ttlMs and cacheScope to list and read responses, so clients can cache tools/list for as long as the server permits.
• Tasks graduated from experimental core into a formal extension, contributed by AWS, for reliable long-running work with poll-based operations.
• MCP Apps joined the same formal extensions framework.
• A twelve-month minimum deprecation window now applies, and Roots, Sampling, Logging, and Dynamic Client Registration entered deprecation.
• Tier 1 SDKs — TypeScript, Python, Go, and C# — shipped updated; the Rust SDK is in beta.

It is already live in Claude

Anthropic shipped support for the new specification across the Claude apps, the Claude Platform and API, and Claude Code on the same date, alongside MCP Apps for interactive UI in conversations, enterprise-managed authentication aligned to OAuth 2.0/OIDC for identity providers like Entra and Okta, observability dashboards for published connectors, and MCP tunnels in research preview. Claude's connector directory now lists over 950 MCP servers.

In other words, this is not a spec you can wait out. If your agent talks to Claude Code or a connector, the stateless core is already the ground it stands on.

A session was never a memory

An MCP session lasted as long as a connection: minutes, sometimes seconds. Your agent's amnesia operates on a different timescale entirely — tomorrow morning, next sprint, the third time a teammate asks about the same customer. Even in the old stateful world, closing the client dropped everything the session knew.

Session state was transport bookkeeping. Memory is the accumulated conclusions of your work. Conflating the two is why teams kept expecting persistence from a layer that never promised it.

What actually breaks

The patterns that genuinely relied on session state are narrower than the panic suggests: servers that accumulated intermediate state between tool calls in memory, handshake-derived caches keyed by session ID, and gateways that needed sticky sessions to keep a client pinned to one worker. Those need reworking — a remote server can now sit behind plain round-robin load balancing, which is the upside.

What does not break: anything that already stored durable state outside the connection. If your knowledge lived in a database, a file store, or a memory service, July 28 changed nothing about your recall and made your deployment simpler.

Where memory has to live now

The specification's answer — mint a handle, let the model pass it back — is correct and incomplete. It tells you how to reference state, not where state should live, what shape it should take, or how five different agents on three different models are supposed to share it. That is the layer you own now, and it is worth owning deliberately instead of accidentally.

Bigger context windows

Frontier models now advertise context windows measured in millions of tokens, and it is tempting to treat that as memory. It is not. A context window is what the model can read this turn; you still have to decide what to put in it, pay for those tokens every turn, and start empty the next time. See why RAG isn't memory for the same distinction applied to retrieval.

Each tool's built-in memory

Claude, ChatGPT, and most agent frameworks now ship their own memory features. Each one is genuinely useful and genuinely siloed. What your coding agent learned about the deploy pipeline does not reach the assistant drafting the incident report, and none of it follows you when you route a task to a cheaper model.

A handle plus a database you build yourself

This is the path the specification points at, and for some teams it is the right one. It also means writing extraction, storage, retrieval ranking, scoping, expiry, and multi-agent access control — and maintaining them while the surrounding protocol keeps evolving. Worth it if memory is your product. Expensive if memory is plumbing on the way to your product.

The durable version of the specification's advice is to put memory in a service that no session, restart, or model swap can take with it. MemoryLake is built for exactly that position: one memory layer your agents read from and write to over MCP or the API, independent of which client is connected right now.

Step 1: Create an API key

Generate a key and make your first request in about 30 seconds. Nothing in this step depends on a session — which is the entire point.

Step 2: Upload your first memories

Drop in the documents, images, and files your agents keep needing: architecture notes, runbooks, customer context, prior decisions. This is the state a handle should be pointing at.

Step 3: Connect your AI & agents

Give Claude, Codex, OpenClaw, and your other agents access to that memory via MCP or the API. Under the 2026-07-28 core, each call carries its own identity and reaches the same memory — no sticky routing, no session to keep warm. For a client-specific walkthrough, see how to add memory to Claude Code; if you are the one writing the server, memory for stateless MCP servers covers the implementer's side, and memory for MCP Tasks covers long-running work.

Do the arithmetic on re-explaining. Suppose your standing context — stack, conventions, current priorities, decisions already made — is 2,000 tokens, and you or your agents re-send it 20 times a day. That is 40,000 tokens daily, roughly 1.2M a month, spent restating things you already said. The token bill is the small part; the cost you actually feel is the four to five minutes of re-briefing at the start of every session, and the mistakes agents make when nobody bothers.

A persistent memory layer converts that from a per-session tax into a one-time write. It also makes multi-agent work coherent: when two agents share a memory instead of a transcript, the second one starts from the first one's conclusions. That problem is worth reading about separately in multi-agent memory.

Store conclusions, not transcripts

Raw logs grow without bound and retrieve badly. "We chose Postgres over Redis for chat history because queue mode broke in-process memory" is worth keeping. The forty messages that led there are not.

Key memory to the work, not the connection

Sessions are gone; do not rebuild them by accident. Scope memory to a project, repository, customer, or task — something that still means the same thing next month, regardless of which client is calling.

Prune and version deliberately

Stale memory is worse than no memory, because agents trust it. Give facts an owner and an expiry, and record when a decision superseded an earlier one instead of leaving both in the pool.

MCP going stateless on July 28, 2026 did not delete your agent's memory. It ended the illusion that the protocol was holding it. Sessions were transport, not recall, and the specification now says as much while handing you the mechanism — an explicit handle — and leaving the substance to you.

The teams that will feel this change as an upgrade are the ones whose memory already lives outside the connection: simpler deployments, the same recall, and agents that pick up where the last one stopped. The teams that will feel it as a loss are the ones who were counting on a session to remember for them. Building that layer once is cheaper than paying the re-explaining tax forever.