Why Stateless MCP Is Better for AI Agents

Ask why an AI agent setup gets hard to grow and you'll usually hear about traffic — too many requests, coming in too fast.

That's almost never it. The real limit is far smaller, and much stranger. You can see the whole thing in one customer question.

One question, four tool calls#

An AI support agent gets asked something simple: where is my order?

Simple to ask. Not simple to answer. To reply, the agent has to look up the customer's account, pull up the order, check the shipping, and update the ticket. Four tool calls for one sentence.

Now a thousand people ask at once. That's four thousand tool calls in a few seconds.

That sounds like the scary part. It isn't. Websites have handled traffic like that for decades — you put more machines behind a traffic director, and it sends each request to whichever machine is free.

But that trick has one requirement.

Every machine has to be able to answer any request.

Break that, and adding machines stops helping.

The problem was memory#

Not memory as in RAM. Memory as in: this one server is holding something about you that the others don't have.

That's how MCP used to work. The agent said hello once, and the server handed back a session ID — a little ticket. After that, every request had to bring that ticket back to the same server, because only that server knew what it meant.

So the traffic director can't do its job anymore. It has three options, and all three are worse than they look:

Always send this agent back to Server B. Works right up until Server B restarts, or you update your app, or the system shuts a machine down to save money — all things you do on purpose, all the time.

Put the session somewhere all the servers can read it. Now every single tool call makes an extra trip to fetch it, and if that shared store goes down, so does everything.

Teach the traffic director to read MCP and send each request by hand. Now the traffic director has to understand your app to do its job.

Each one is a way of buying back the thing you already wanted: any server, any request.

What stateless actually means#

It's blunter than the word suggests. Every request brings everything it needs. Nothing is looked up. Nothing was supposed to be remembered.

Put the two side by side and the picture makes the argument on its own:

That padlock is the whole problem in one symbol. Take it off, and the next request can go to a completely different server — because there was never anything on the first one worth going back for.

Two reasons that actually pays off#

Reason 01 — scalability. Because no request depends on one server remembering anything, the work can spread across as many servers as you like. More agents, more requests? Add more servers. The system grows with demand instead of fighting it.

Reason 02 — flexibility. No request is tied to one specific machine, so whichever server is free can pick it up and finish the job. That matters most in exactly the place agents actually live — cloud setups where machines come and go all day long.

In July 2026, this became the rule#

Servers were always allowed to work this way. You just had to know to do it.

Then MCP made it the only way. In the version dated 28 July 2026 — two days before this video went up — sessions and session IDs were taken out of the rules completely. A modern server is now told to ignore an old session ID and never hand one out.

Everything built on top of the old idea went with it: the extra line held open on the side, the "pick up where we left off" feature, and the introduction at the start.

The state doesn't disappear — it moves#

This is the part most explanations skip, and it's the most useful bit.

Taking sessions away doesn't remove the things your work genuinely has to remember. A half-finished upload is real. A long list you're partway through is real. What changed is that the protocol won't quietly hold it for you anymore — so it has to sit somewhere you picked.

The official answer is deliberately boring. If a server really does need to remember something between calls, it gives you a receipt — an id for the upload, the list, the draft — and you hand that back with your next request, like any other detail.

The difference between a receipt and a session isn't cleverness. It's that you can see a receipt. You can save it, expire it, hand it to a different server, and know exactly what happens if you lose it. A session was a promise you couldn't look at.

And most of what sessions held was never really memory anyway. It was a detail nobody wanted to send twice.

What you give up#

Two honest costs, because a post that only lists wins isn't worth reading.

If the connection drops mid-call, there's no picking up where you left off. You send the whole thing again. That's simpler to think about — but it's now your job, not the protocol's.

Every request is slightly bigger, because it repeats a few details each time. Against a tool call that's about to go and hit a database, that's nothing. But it is the price of everything above.

Why this suits agents so well#

Here's the part that makes it click.

The agent was already working this way.

Every time an AI model takes a turn, it's sent the whole conversation again — the instructions, the question, every result so far. The model doesn't remember you between turns. That's not a flaw. It's the reason you can put a model behind as many machines as you like.

So the agent was already re-sending everything to one service on every step — and then, in that same step, asking a second service to please remember last time they spoke.

The tool layer was the only part of the loop with a memory. Which made it the only part you couldn't grow by adding machines.

The verdict#

So — why is stateless MCP better for AI agents?

• Every request is self-contained. Which means it can be answered by anything, and that's what turns "add more servers" into a complete plan.
• Nothing to remember, nothing to reconnect to. A machine dying, an update going out, a call timing out — none of it is special anymore.
• You scale by adding servers, not complexity. The architecture doesn't change as you grow. You just add more of it.
• And what you really do need to remember becomes visible — a receipt you can look at, instead of a session you never could.

The scary number was never the four thousand requests. It was one small fact, sitting in one machine's memory, quietly deciding that only that machine was allowed to answer.

Take that away, and the rest is just normal web traffic.