Sound familiar?

Here’s what nobody mentions when they sell you on AI agents: model failures are rare. Most agents don’t fail because they’re stupid. They fail because the environment they’re running in wasn’t built for them. The gap between “this AI can do that” and “this AI does that consistently, without supervision” is a plumbing problem, not a model problem.

We hit all three failure modes building the receipt intake workflow for Housewire. In testing, the agent processed expenses, categorized transactions, and surfaced anomalies. In production, it answered with high confidence from the wrong context, fell apart on edge cases nobody anticipated, and checked for new receipts every hour on a cron job. None of it was a model problem. All of it was plumbing.

The field’s default assumption is that reliability improves when you improve the model. Better model, better prompt, different provider. SI’s position is the opposite: the model is rarely the constraint. The environment is. And it fails in three specific ways.

Dumb RAG

Most teams think about retrieval like this: give the agent access to the knowledge and it’ll figure out what it needs. That works in a demo. In production, it creates context rot.

Accuracy degrades when you load too much into an agent’s working context: entire databases, full document libraries, unstructured dumps. Not because the model can’t handle it. Because the signal gets buried. The agent keeps answering, with high confidence, from the wrong part of the context.

The pattern that works in production: just-in-time retrieval. The agent gets structured access to domain knowledge and pulls exactly what the task requires. The benchmark from teams running this in production: keep working context under 8,000 tokens for task-execution agents. That number forces precision about what goes in.

This is an information architecture problem, not an AI problem.

Brittle Connectors

Most software isn’t built for agents. It’s built for humans, which means APIs designed for web UIs, undocumented field behavior, rate limits that made sense for human-paced interactions, and custom field semantics that live in one senior developer’s head.

Point an agent at that facade and you’re asking it to navigate a floor plan it wasn’t designed for. The result: the agent works when everything goes right and falls apart the moment it hits an edge case nobody anticipated.

Agent-ready facades look different. Workflow-level tools where one tool handles one complete operation, not one API call. Descriptions that explain purpose and consequences, not just parameters. Error messages in plain language. “The expense category doesn’t match any active source rules” is actionable. “Error 422: Unprocessable Entity” is not.

We built the receipt intake workflow for Housewire twice. The first design exposed raw database operations to the agent. The second defined workflow-level operations. The difference in reliability wasn’t incremental. It was categorical.

The Inspection Tax

Autonomous agents need to react to things that happen in your system. New record created. Status changed. Threshold crossed. The default approach is an inspection schedule: check for new items every N minutes.

It seems reasonable. It’s quietly catastrophic.

You can’t run autonomous agents on request-response infrastructure. Running on a fixed inspection cycle introduces latency, burns compute on empty checks, and converts what should be an event-driven process into a slow batch job. An agent checking for new receipts every hour isn’t an autonomous system. It’s a scheduled job with extra steps, and the most common reason implementations feel unreliable without anyone understanding why.

The fix is straightforward: agents acting on real records need data under five minutes stale. That means webhooks, realtime subscriptions, state change triggers, not cron jobs asking whether anything changed. This is a solved infrastructure problem. The hard part is recognizing your inspection schedule is the bottleneck before you’ve spent six months debugging the wrong thing.

Three questions that tell you more than any benchmark

If you’re building or running an AI agent integration, start here:

1. What does your agent load into context, and what happens to that as your knowledge base grows?

2. Are the tools available to your agent workflow-level, or are they raw API calls it has to chain together?

3. When something changes in your system, does the agent find out through a webhook, or by asking?

Most implementations fail question two or three on contact. Fixing them isn’t glamorous. These are the load-bearing walls: what decides whether your agent runs in production or gets quietly retired.

The demo always works. What you’re actually evaluating is the plumbing.

Which of the three failure modes have you hit? Reply with the one that cost you the most time. I’m compiling patterns.

The plumbing is fixed. The context window still has a problem most teams have never heard named. Next issue: why retrieval isn’t the layer you need to fix, and what is.

Systems Intelligence is the honest trade publication for AI automation practitioners. No demos. No hype. Just what it actually takes to make AI reliable in production. Subscribe.

You’ve seen the checklist. Someone forwarded it, someone else reposted it, and now it’s sitting in three of your channels with a countdown attached. Patch these headers, remap these error codes, do it before the 28th or your integrations fall over.

If you run remote MCP servers in production, that message is built to make your stomach drop. So let’s start with what’s true, because plenty of it is.

This is the largest revision of the protocol since launch. The maintainers say so in as many words: the release candidate locked May 21, and the final spec publishes July 28 (blog.modelcontextprotocol.io). The changelog is long and none of it is cosmetic. OAuth hardening. JSON Schema 2020-12 for tool schemas. W3C trace context. HTTP+SSE transport deprecated. This is a genuine reset, and treating it as a non-event is its own kind of malpractice.

So the deadline is real. What’s fake is the cliff.

Real vs. theater

Here’s the line nobody forwarding the checklist is drawing for you: the day the news breaks is not the day anything breaks.

MCP’s lifecycle policy guarantees at least twelve months between deprecation and removal. Servers built on the 2025-06-18 and 2025-11-25 revisions keep working after July 28. Nothing gets deleted day one. And if you’re running local STDIO servers, most of this doesn’t reach you at all. The disruptive changes are a remote-HTTP concern, because that’s where the problem they solve actually lived.

There is a real reason to move: you want to be current before the runway closes, and you want to reason about the change while it’s fresh instead of under duress a year from now. That’s a deadline for adoption. It is not a fire alarm.

The checklist collapses those two things into one. It takes a protocol reset with a year of runway and repackages it as a config patch due Tuesday. And once you can see that move, you can see what it’s hiding, which is the only part that actually matters.

One change takes state out of the protocol

Sessions are gone.

That’s the change that leaves every request standing on its own, and it’s buried on page four of every checklist because it can’t be written as a step.

Two proposals do the work. SEP-2567 removes sessions. SEP-2575 removes the initialize/initialized handshake. Identity and capabilities now travel through _meta, with a new discovery method replacing the old negotiation. WorkOS, writing on the authentication changes, puts it plainly: the protocol is going stateless. Any request can now land on any server instance.

Sit with that for a second, because it is not a version bump. It’s an architecture decision someone already made for you.

A stateful protocol lets you assume continuity. The same client talks to the same instance, the handshake establishes who they are, and each exchange after leans on that. Stateless removes the assumption. Every request arrives cold. Which means the questions you thought were settled are open again. Where does state live now? How do you establish identity per-request instead of per-session? How does a load balancer route traffic it can no longer tie to a session?

The spec answers that last one directly. The Mcp-Method and Mcp-Name headers become mandatory (SEP-2243) so a load balancer can route without cracking open the request body. That isn’t a chore to tick off. That’s the protocol telling you it now expects to run behind infrastructure that treats every call as independent. Caching moves the same direction: ttlMs and cacheScope appear on results because in a stateless world the server can no longer remember what it already told you.

Read those details as tasks and you’ll patch them and move on. Read them as evidence and they say the same thing in unison. The model of what an MCP connection is just changed underneath you.

The specimen

The forwarded checklist is worth keeping: as a specimen, not a map.

It optimizes for looking responsive. Fifteen bullets, a deadline, a sense of motion. What it can’t do is tell you why any of it is happening, because the “why” isn’t a task you can complete. The posture treats a protocol reset as a config scramble, and a config scramble has one seductive property: you can finish it. You can close the tickets and feel done, having never once asked what stateless does to your routing, your identity model, or your cache.

That’s the trap. Migrate reactively to a list and you’ll rebuild your integration twice. Once now, in a hurry. Again in six months, when you realize removing sessions quietly rewrote your entire state and routing model while you were treating it like a header change.

One more for the “why” pile, since it also isn’t a step: Akamai has flagged that the new MCP Apps feature introduces a stored-XSS class of risk, and that cheap task creation opens a denial-of-service vector. Security researchers are reading the changelog as architecture. The checklist is reading it as chores.

The actual question

Adopt while it’s current. The reason isn’t to dodge a cliff that doesn’t exist. It’s that reasoning about a stateless protocol is the work, and doing it deliberately now costs less than doing it reactively later.

The deadline on your feed is answering the wrong question. The real one was never did I patch the headers before the 28th. It’s does my architecture still hold when any request can hit any instance and nothing remembers the last one.

One question before the next issue: where does your MCP server keep state today: in the session, in a database, or somewhere you’d have to go check? Reply with one sentence. I’m compiling how people answer, because it predicts almost exactly how much the stateless shift is going to cost them.

94% of those same enterprises say agent sprawl is their fastest-growing security risk.

12% have a governance system to manage it.

One survey. 1,900 IT leaders. The report called it “agentic AI going mainstream.” That’s one way to read it. Another: a structural guarantee that most of these programs end badly.

The speed is real. The demand is real. The governance infrastructure isn’t there yet. Deployment has already outpaced it.

How this happens

Every enterprise AI meeting has the same pressure: move faster, ship more, prove ROI before the next budget cycle. The agents that get approved are the ones that solve visible problems quickly. The question nobody asks in that meeting is “what happens when we have forty of these?”

The result is exactly what the data shows: agents deployed team by team, use case by use case. Different vendors. Different authentication patterns. Different assumptions about data access. An agent for HR, one for finance, one for customer success, one the engineering team spun up without telling anyone.

No one intended to build a security liability. They just didn’t build a system.

What sprawl costs

The 12% number is the one that matters.

It’s not that the other 88% aren’t trying. 97% are actively planning org-wide AI agent strategies. But planning and infrastructure are different things. You can’t governance-plan your way out of 88 ungoverned agents running on a hope that nothing goes sideways.

Gartner expects more than 40% of agentic AI projects to be canceled by 2027. Not failed. Canceled. The distinction matters.

Failed means it didn’t work. Canceled means it worked well enough to scale, then the organization couldn’t manage what it scaled into.

The mechanism is predictable. An agent gets access to more data than intended. Or it writes to systems it shouldn’t. Or the team that built it turns over and nobody knows what it’s doing anymore. Not by accident. Ownership was never assigned. These aren’t edge cases. They’re structural outcomes of building deployment velocity before building governance.

The 94% who flagged sprawl as a risk aren’t paranoid. They’re accurate. They just haven’t stopped deploying.

What a governance system actually is

Here’s what it isn’t: a platform. The 12% aren’t there because they bought a governance tool. Most governance platforms in this category are either too immature or too enterprise-priced to matter at this stage. They’re there because they treated “what governs these agents” as a first-class design question from day one, not an afterthought to be solved once the deployment count got uncomfortable.

That means three things.

Ownership. Every agent has an owner. Not a team. A person. Someone accountable when it behaves unexpectedly. Someone whose name is attached to the access rights it holds. Someone who gets paged when it fails. If you can’t name the owner of every agent in your stack, you don’t have a governance system. You have a hope.

Audit. Every agent’s actions are logged and reviewable. Not by default. By design. “What did this agent do between 2am and 4am?” should have a deterministic answer. If it doesn’t, you don’t know whether it’s working correctly or just working quietly. Those aren’t the same thing.

Scope. Every agent has explicit boundaries: what it can read, what it can write, what systems it can touch. Not what it’s supposed to do. What it’s technically permitted to do. That distinction is where the risk lives. Agents don’t malfunction on purpose. They operate at the edge of their permissions, wherever you put that edge.

Ownership, audit, scope. Not a product. A system. Three questions every agent deployment should be able to answer before it goes anywhere near production.

The math nobody wants to do

96% deployed is a headline. 12% governed is the story underneath it.

The organizations that are still running functional agent programs in 2027 aren’t the ones that deployed the most, the fastest. They’re the ones that built the system before they needed it.

Most didn’t. Most won’t. Not until an incident makes governance the priority it should have been from the start.

Governance isn’t the brake on your AI strategy. It’s the foundation that lets the strategy hold weight.

One question, and I read every reply: how many agents are running in your operation right now, and could you name the owner of each one? Hit reply.

Systems Intelligence covers AI architecture for operators who need it working, not just running. New here?

Subscribe now