Stateless MCP Changes How Agents Get Built

Your agents work in the demo. That is the easy part. The hard part is what happens when two of them edit the same file at 3 am, when one forgets what a human told it last Tuesday, and when nobody can prove what it actually did. The plumbing under agentic features just got a lot more serious. Let me catch you up.

The deep cut

• Agent reliability is a plumbing problem, not a prompt problem. File collisions and stale context break parallel coding agents, and better prompts do not fix it.
• Prompt guardrails leak under pressure. IntentFlow moves the rules outside the model so an auditor can prove a run stayed in bounds.
• Memory is a dose, not a switch. IBM found gpt-oss-120b gained 16.1 points with a small curated set, while GLM-5 gained nothing.

The protocol stopped being a session

The Model Context Protocol just shipped its biggest change since launch, and the new spec is an architecture migration, not a version bump. The protocol is now stateless. The old session handshake is gone. Every request carries its own version, method, and identity.

That helps you scale. A stateless server runs behind a normal load balancer with no sticky routing. But stateless does not mean you store nothing. Your app is still stateful. Long-running work now moves into durable Tasks, which need a real database, ownership checks, and cleanup. A task ID is a resource identifier, not a secret. Possession of the ID must not be enough to act on it.

Your backend API is not your agent's API

Once you have dozens of tools across Salesforce, GitHub, Jira, and more, dumping every schema into the model wastes context and makes tool selection worse. The MCP-as-platform argument is that the tool catalog itself becomes something you engineer.

Two moves matter here. First, tool transformation: a raw operation like salesforce_account_query_v2_internal with a tenant_uuid argument becomes a clean find_customer_account. If the model should not control a value, keep it out of the schema. Second, tool search: instead of showing 300 schemas, expose a search_tools call that returns the four relevant ones. One security rule carries over. Search only the catalog the user is allowed to discover, or you leak admin tool names even when execution is blocked.

Prompts are not a governance layer

You can write "never close the issue" in a prompt and the agent closes the issue anyway. IntentFlow's argument is that governance written in prompt wording leaks under real pressure. It moves the rules into a small declarative file, enforced outside the model by a gate that never reads model output. Every run produces a hash-chained trace, so an auditor can prove the run stayed inside its rules using only the source and the trace.

That matters more now that agents act on their own. Anthropic updated Claude's Google Workspace connector so it can send and reply to Gmail without asking first. Approval is still the default, but users can turn it off. The moment your agent takes real actions, "trust the prompt" stops being a plan.

Memory is a dose you calibrate

Giving an agent everything it has learned sounds obviously good. IBM Research found it depends entirely on the model. Strong models with headroom used the full guideline set. Weaker models got drowned by it and did best with a compact core plus a few retrieved lessons. Saturated models gained nothing.

The numbers are concrete. gpt-oss-120b jumped 16.1 points in task completion with curated retrieval at only 5 percent more tokens. DeepSeek-V3.2 climbed 9.5 points with the full set but paid 78 percent more tokens. So the cheapest option can also be the most accurate for weaker models. And there is a separate problem: corrections do not persist. Lessonweaver mines traces for repeat failures, routes them through human review, and exports only approved lessons into instruction files. No LLM in the loop.

Parallel agents fight without a traffic system

Running four coding agents at once feels like a team appeared in your terminal. Then two edit the same config, three fight over port 3000, and a reviewer approves code that breaks on merge. The deconfliction guide names the missing layer: ownership, resource leases, state freshness checks, and merge gates.

Worktrees solve one slice, file isolation, but they push conflict discovery to the merge step where it is expensive. The harder failure is stale context. One agent changes a function signature while another writes a caller against the old one. Both branches pass alone and break together. The fix is a read-set manifest: record which files an agent read and their hashes, then re-check before merge. If a dependency moved, the agent rebases and reruns. A branch that passes tests is a candidate, not a finished job.

The through-line across all of this is boring and expensive. The five-tool stack writeup puts it plainly: the gap between a notebook demo and production is not the model, it is the five layers underneath. Durable state, sandboxed execution, memory, tracing, and hosting. Wire observability in from your first shipped version, not after the first incident.

Three questions for your team

• Where does our agent governance actually live right now, in a prompt or in an enforced layer we can audit after a run? If it is a prompt, what happens when it leaks?
• If we run more than one agent on the same repo, what stops two of them from shipping incompatible changes that both pass tests alone? Do we have a merge gate or just hope?
• Are we calibrating memory per model, or feeding every agent the same guideline set and paying for tokens that buy us nothing?