The thread worth paying attention to right now is not a model release. It's the Model Context Protocol specification dated 2026-07-28, and the follow-on guidance that has accumulated around it — InfoWorld framed the change plainly in late July as MCP going stateless to make scaling simpler, and Google's developer blog published an infrastructure-oriented post on scaling agent deployments against the stateless updates in early August. The MCP maintainers have since published a refreshed roadmap. If you run connectors into an internal knowledge base, this is the change that touches your architecture.
Why statefulness was the wrong default for connectors
The original transport model assumed a long-lived session between host and server. That's a comfortable assumption when you're running a local server against a developer's filesystem. It's a bad one when a single MCP server fronts Confluence, a ticketing system, and a warehouse for a few thousand concurrent agent sessions. Long-lived sessions mean server affinity. Server affinity means you can't put a plain load balancer in front of a horizontally scaled fleet, you can't drain a node without killing conversations mid-flight, and every deploy is a correctness event rather than a routine one. Anyone who has tried to put an MCP connector behind standard serverless or autoscaled infrastructure has hit this.
Stateless operation moves the session boundary. The server becomes closer to a request-response retrieval endpoint, and whatever continuity the agent needs has to live somewhere the host controls.
Where the state actually goes
It doesn't disappear. This is the part teams underestimate. If your connector was quietly holding a cursor, a warmed permission cache, a resolved tenant identity, or an incremental sync position, that now has to be explicit — passed in the request, or held in a store the host owns.
Practically, three things get harder and one gets easier. Harder: per-user authorization caching, since you can no longer amortize an expensive permission resolution across a session and may need to re-resolve per call. Harder: pagination and long retrieval walks, which now need externalized cursors that survive routing to a different node. Harder: anything that treated the connector as de facto short-term memory. Easier: scaling, testing, and failure recovery, because a stateless retrieval call is idempotent and replayable.
The design implication is that agent memory and knowledge-base session state consolidate in the host, not the tool layer. That's the correct separation — connectors should retrieve, not remember — but it means the memory store you may have deferred building becomes load-bearing.
Who this matters to: anyone shipping MCP servers over enterprise data behind autoscaled infrastructure. Audit your servers for implicit session state before you migrate, not after.