The Model Context Protocol working group published a specification release candidate dated 2026-07-28, and the headline change is that MCP is moving away from its stateful past. InfoWorld framed it as going stateless "to make scaling simpler"; The Register covered the same shift a week earlier as the protocol preparing to break with statefulness; Slashdot's read was blunter — this addresses the main barrier to enterprise adoption. Take the coverage at face value and it's the most consequential thing in this space in the last week, more so than any model release, because it lands directly on the layer most of you are already running in production.
Here's why it matters if you operate connectors. A session-oriented transport means a client's initialization, tool list, and subsequent calls all belong to one server process. That forces sticky routing, complicates rolling deploys, and makes autoscaling a coordination problem rather than a capacity problem. Teams have been working around it with sticky load balancers, session state pushed into Redis, or by simply running one fat MCP process per tenant and eating the blast radius. If the session requirement goes away, an MCP server becomes an ordinary stateless HTTP service — you scale it like any other, you deploy it like any other, and a pod restart stops being a user-visible failure.
The tradeoff moves elsewhere, not away. Whatever state you were implicitly keeping in the connection now has to live somewhere explicit. For retrieval-heavy servers, that's the interesting part: tool manifests, auth token exchange, index handles, embedding-model warm caches, and pagination cursors for large result sets. A stateless design means each call carries enough context to be routed anywhere, which usually means more per-call setup cost unless you're deliberate about caching at the process level and idempotency at the API level. If your MCP server fronts a vector index or an enterprise search API, expect to re-examine connection pooling and per-request auth overhead before you see the scaling win.
For agent memory specifically, this pushes in a direction most serious implementations were already heading. Memory that lives in a connection is memory you lose on failover. Memory that lives in a durable store — with explicit read and write tools, versioning, and its own retrieval path — survives the transport changing underneath it. If your design still assumes conversational continuity is a property of the channel, this is the forcing function to fix that.
What to do this week: read the release candidate rather than the coverage, since RC status means details can still move before final. Audit which of your MCP servers actually depend on session identity versus which just inherited it from the SDK defaults. The second group is probably larger than you think, and it's the cheapest migration you'll do this quarter.