The MCP 2.0 specification from July 28, which we covered on August 1st, removes sessions from the server: a single HTTP request is enough to invoke a tool. In its weekly recap, Latent.Space identifies precisely this stateless shift as the thread tying together the week’s themes: agents messaging each other, multi-agent orchestration, state management.

For those scaling agents, persistent state on the server was the invisible bottleneck. Every open session consumed resources, every connection had to be managed and maintained. With the stateless protocol, a hundred agents can call the same tools without the server becoming the choking point.

This week proves it in the field. Claude Code lets sessions exchange messages, and in Codex you can @-mention a thread to queue a message to another agent. These patterns only work if the underlying infrastructure doesn’t hold state. Latent.Space dubs this trend the “Zawinski’s law of multi-agent systems”: every agent seeks to expand until it can message other agents.

If you want to try it: the MCP 2.0 specification is public on the protocol’s official repository. Compare the session-based flow of the previous version with the HTTP stateless one to understand what changes in your architecture.

In detail

The Model Context Protocol (MCP) is the standard that Anthropic published at the end of 2024 to connect AI assistants to external tools: databases, APIs, file systems, any resource an agent needs to read or write. In its first version, every connection between agent and tool opened a persistent session on the server. The server tracked who was connected, what they were doing, what conversation state they’d accumulated. It worked fine for a chat, but became a problem when agents multiplied.

The state problem. If you have ten agents simultaneously calling the same MCP server, the server must manage ten active sessions. Each session occupies memory. If an agent disconnects without closing the session, the server’s left with a phantom connection. If you want to scale to a hundred agents, the server becomes the bottleneck. It’s the same problem the web faced years ago when moving from server-side sessions to stateless tokens.

What changes with MCP 2.0. The July 28 specification removes state from the server. An HTTP request contains everything needed: which tool to call, with which parameters, with which context. The server responds and forgets. No session, no persistent memory, no connection to maintain. It’s like the difference between a phone call (you open a line, maintain it, close it) and an SMS (you send the message, the system delivers it, done).

Why now. This week’s patterns show agents becoming distributed systems, not single assistants. Claude Code lets sessions communicate with each other. Codex lets you @-mention threads to queue messages to other agents. OpenAI documented at Black Hat how its agents in training discovered on their own how to use a shared repository as a bulletin board to coordinate. These are examples pointing the same direction: agents talking to other agents, not just to a human. And for this to work at scale, the underlying protocol can’t hold state.

Latent.Space sums it up with what it calls “Zawinski’s law of multi-agent systems”, a riff on Jamie Zawinski’s famous law about software expanding until it can read mail. In the case of agents: every agent seeks to expand until it can message other agents. MCP 2.0 stateless is the infrastructure that makes this expansion practical instead of choking it.

What remains open. The specification is live, but real adoption requires servers and clients to update. Some existing MCP implementations might not yet be compatible with the new stateless model. And the shift from session-based to stateless moves the state problem from server to client: it’s the agent, or whoever orchestrates it, that must manage it. State doesn’t disappear, it changes hands.