Model Context Protocol standardized how agents reach tools. It was never designed to answer what an agent remembers once the session ends — and that gap is where most "unreliable agent" complaints actually live.
MCP has crossed roughly 97 million monthly SDK downloads as of March 2026. In December 2025, it was donated to the Agentic AI Foundation, a Linux Foundation project. Public directories now list more than 20,000 MCP servers, and a Zuplo survey of technical leaders found 72% expect MCP usage to keep growing. By any adoption metric, MCP won.
So why does working with an agent still feel like working with someone who has no memory of yesterday?
What MCP Actually Solved
Give credit first. Before MCP, every tool integration was a one-off: a custom adapter per tool, per framework, multiplied across every team building agents. MCP collapsed that into one protocol — one server per tool, any compliant client can talk to it. It's the same kind of standardization that made USB-C useful: not because any single device needed it, but because it stopped every device from needing its own cable.
That problem — how does an agent reach a capability — is basically solved. It's a real engineering win, and it deserves to be called one before anyone picks apart what it didn't do.
The Question MCP Never Tried to Answer
MCP standardizes access within a session. It says nothing about what persists once that session ends, and that's not a design flaw — it's simply a different layer of the problem that nobody has standardized yet.
Consider what "using a tool" actually produces for an agent working a real task: it doesn't just get an answer, it builds up situational knowledge — which function is safe to touch, which API was deprecated last sprint, which decision the team already made and doesn't want re-litigated. MCP gives the agent access to the tools that let it discover all of that. It gives the agent no mechanism for carrying any of it into the next session. The tool connection survives. The judgment built during the session does not.
This matters because the industry's own direction has started to reverse on the "just make the window bigger" instinct. Multiple 2026 benchmarks on long-context recall show accuracy on facts placed in the middle of long prompts dropping noticeably compared to facts near the start or end — a pattern researchers call context rot. Bigger windows didn't eliminate the forgetting problem. They mostly made it more expensive to run into.
Why More Context Isn't the Same as Better Memory
Here's the trap: a longer context window is not the same thing as correct context. As more information competes for a model's limited attention, not every token gets equal weight — relevant facts further from the start or end of a long prompt are measurably harder for the model to retrieve and reason over, even when they're technically "in context." That's a real, benchmarked effect, not a metaphor.
So feeding an agent ten sessions of raw transcript doesn't produce a wiser agent. It produces one that can't easily tell which of last week's conclusions are still true after something changed since then.
Raw history is not memory. Memory means deciding what's still valid — a filtering and validation problem, not a storage problem. Most "long-term memory" bolted onto agents today skips that step entirely: store everything, hope retrieval sorts it out later. A 2026 developer survey of more than 1,100 engineers found 96% don't fully trust AI-generated output, and fewer than half always verify it before committing. An unfiltered memory layer doesn't close that trust gap. It gives the agent one more place to confidently repeat something that's no longer true.
What a Memory Layer Actually Needs
If MCP standardized reach, the next layer needs to standardize retention — and retention requires more than a bigger database.
Structure. A flat transcript log treats every interaction as an isolated fragment. Useful memory needs some notion of entities and relationships — this service depends on that one, this decision superseded an earlier one — so an agent can retrieve what's relevant to the current task instead of just what's recent.
Provenance and validity. Not everything an agent "learned" stays true. A memory system that never revalidates what it's holding will hand back stale conclusions dressed up as current facts — which is arguably worse than having no memory at all, because a confidently wrong agent is harder to catch than one that admits it doesn't know.
Conflict resolution. When two memories disagree — an old API contract and a new one, an old team decision and a reversed one — something has to decide which one the agent should trust, and on what basis.
None of this is exotic. It's solvable, active engineering territory. But there's no MCP-equivalent standard for any of it yet. Every team building persistent agents is solving it independently, in incompatible ways, which is exactly why an agent that settles something on Monday has no way to carry that forward by Wednesday unless someone built a bespoke system to make it possible.
My Bet
I don't think the next "interoperability" story in this space will be about connecting agents to more tools — that race is close enough to over that Gartner is already predicting 40% of agentic AI projects get canceled by 2027 over inadequate risk and reliability controls, not lack of tool access.
My bet is that the next real interoperability conversation will be about what an agent is allowed to remember, how that memory is represented, how its validity is tracked, and how another agent — or another session of the same agent — can safely consume it. Right now, that layer doesn't have a protocol. It barely has a name.
MCP made agents better at reaching things. The next unlock is making them better at not forgetting what they learned the last time they did — and knowing when to stop trusting what they remember.
Top comments (2)
The USB-C analogy is the right frame — MCP solved reachability, not retention, and conflating the two is where a lot of "unreliable agent" reports actually come from.
One thing I'd add from running agents on a schedule: the memory you most need to persist isn't the facts, it's the negative knowledge. "This API deprecated last sprint," "we already decided not to do X," "that retry path double-posts." Facts you can re-fetch cheaply; hard-won don't-do-this lessons you can't, and those are exactly what a fresh context window throws away first.
We ended up writing those as small durable notes keyed by a stable slug, loaded back in at session start — basically a hand-rolled memory layer sitting beside MCP rather than inside it. Crude, but it stopped the agent from re-litigating settled decisions every morning.
Curious where you'd draw the line between what belongs in a persistent memory store vs. what should stay ephemeral — because persisting too much reintroduces the context-rot problem you're trying to escape.
That’s exactly where I think the distinction between memory and history becomes important. I’d also prioritize negative knowledge because it captures constraints, failed approaches, and decisions that shouldn’t be repeated.
For me, persistent memory should be reserved for information that can change future decisions: validated facts, durable decisions, constraints, dependencies, and lessons learned. Temporary observations and session-specific reasoning can remain ephemeral.
The harder part is keeping that persistent layer valid as the system and environment change.