MCP Removed the Session. Your Agent Runtime Still Has One.

The Model Context Protocol team shipped beta SDKs this week for the 2026-07-28 release candidate. Python, TypeScript, Go, and C# all have early support. The big change is simple: MCP is going stateless. The initialize handshake and protocol-level session are going away. Servers expose discovery. Requests carry what they need. Gateways can route on headers such as Mcp-Method and Mcp-Name without opening JSON bodies.

That may sound like plumbing. It is bigger than that. For teams building agent systems that run in production, this change decides where the hard parts sit for the next year.

The easy read is that stateless MCP makes servers simpler to scale. Put them behind a round-robin load balancer. Stop tying a client to one instance. Use ordinary HTTP patterns. Good. That helps.

The sharper read is this: MCP is dropping one kind of session, but your product still has plenty of them. User intent is a session. Tool consent is a session. A half-finished workflow is a session. A chain of delegated agent decisions is a session. An audit trail is a session. If the protocol no longer owns that state, your runtime has to own it on purpose.

Stateless does not mean memoryless

Agent builders often confuse protocol state with product state. A tool call succeeds, so the workflow is “in progress.” A client connection stays open, so the user is “still here.” A long-lived stream exists, so the system must have continuity.

That was always brittle. Stateless MCP makes it obvious.

Take a common client project: an agent reads a repo, asks the user whether to apply a migration, edits files, runs tests, then opens a pull request. In the new model, the MCP server should not be where that workflow quietly lives. Any server instance may get the next request. The user approval, migration plan, files touched, and rollback path need to live in your agent runtime, job ledger, or product database.

That is a good constraint. It gives the system a cleaner boundary. MCP servers expose capabilities. Agent runtimes manage work.

At Kerber AI, this matches how we already design production agent teams. The model call is rarely the hard part. The harder part is the operating layer around it: task ownership, tool permissions, human checkpoints, retry policy, run logs, escalation, and cleanup when an agent gets halfway through a job and stops. Stateless MCP fits that shape better than tool servers that hold workflow state.

The migration test is your architecture test

The beta SDKs are worth trying now because they will flush out lazy assumptions. If your MCP integration breaks when a request lands on a different server instance, the beta is not the problem. The problem is that your tool layer was holding workflow state it should never have owned.

I would test three things before July 28.

• Routing: Put the server behind the same gateway or load balancer you use in production. Check that method-level routing, rate limits, and tenant isolation work with the new routable headers.
• Consent: Exercise Multi Round-Trip Requests with real approval flows. If a tool asks for input midway through a call, make sure the answer is attached to the right user, run, and permission scope.
• Recovery: Kill the server mid-workflow. The next request should resume from product-owned state, not from whatever was sitting in process memory.

The auth changes matter as well. The release candidate tightens issuer validation, application type, step-up scope accumulation, and credential binding. That sounds dull until desktop agents, CLI agents, and background workers all touch the same company systems. Then it becomes the difference between “the agent can do its job” and “the agent picked up a permission shape nobody can explain.”

Build the agent ledger

The practical move is not to wait for final SDKs and bump a dependency. The move is to decide where state belongs.

Every production agent system needs a ledger outside the model and outside the tool server. Not a pretty observability screen. An operational record: who asked for the work, what authority the agent had, which tools were discovered, what was approved, what changed, what failed, what was retried, and what still needs attention.

With that in place, stateless MCP is a win. Tool servers get simpler. Scaling gets less strange. Gateways do real work. You can swap implementations without losing the run history that matters.

Without it, stateless MCP will feel like a step backward. Your agents will be harder to debug because the hidden state did not vanish. It moved into logs, process memory, prompts, and guesses.

This layer of agent infrastructure does not make for a flashy demo, but it determines whether a company can run agents every day. The protocol is growing up. The systems built on it need to do the same.