The Coordination Layer

The week of April 2, several hundred developers gathered in New York to discuss the Model Context Protocol — a specification for how AI agents should communicate with the tools and data sources they depend on. The conversations were serious, the ecosystem is real, and the momentum is genuine. MCP is solving a real problem: how do you give an agent access to a calendar, a database, a code repository, without reinventing the integration every time?

But as the conversations unfolded, a different question kept surfacing in the corridors — one that the protocol itself does not answer. The question was not about how agents talk to tools. It was about what happens between conversations: where does the agent's understanding go when the session ends? What accumulates? What persists? What connects this interaction to the one from last Tuesday?

MCP standardizes the protocol layer. It does not standardize the memory layer. And for most serious deployments, the memory layer is the harder problem.

What MCP Actually Solves

Before MCP, every AI application that needed to interact with external tools had to build custom integrations. Want your agent to read from Notion? Write a Notion connector. Want it to query a database? Write a database connector. The result was a proliferation of proprietary integrations that worked for a specific model and broke when you switched models or tools.

MCP standardizes this. It defines a common protocol for how any client (an AI application) can communicate with any server (a tool, data source, or service). The benefit is real: write one MCP server for your calendar, and any MCP-compatible agent can use it. The interoperability problem — the “how do agents use tools?” question — has a credible answer now.

That is a meaningful infrastructure advance. It eliminates a class of integration work that was previously unavoidable. It creates a common surface area that tooling providers can target. It makes the AI tool ecosystem more composable.

What it does not do is address what the agent knows between sessions. MCP defines context exchange at the moment of interaction. It does not define context persistence across interactions. An agent that uses MCP to read your calendar today has no architectural mechanism — provided by MCP — to know what it learned about your scheduling preferences last week.

Protocol standardization solves interoperability. Memory architecture solves continuity. These are adjacent problems with different solutions — and confusing one for the other is the mistake most fleet deployments are making right now.

The Stack, Clarified

To understand where MCP fits — and where it stops — it helps to map the full infrastructure stack that a serious AI deployment requires:

The model layer is largely solved. Multiple capable providers exist, and the capability gap between them is narrowing. The protocol layer is solving rapidly — MCP's adoption trajectory is real, and within two years, tool integration via MCP will be the default assumption in serious AI applications.

The memory layer and governance layer are not being solved by MCP, and are not being solved by anything else at meaningful scale. This is the structural gap in the current AI infrastructure landscape — not “can models reason?” or “can agents use tools?” but “can agents accumulate, retain, and make accountable use of institutional context over time?”

Why Memory Is Not a Solved Problem

The common objection is that memory is solved — agents have context windows, retrieval augmented generation (RAG) exists, session state can be persisted in a database. These are all true at a narrow technical level. None of them solve the actual problem.

Context windows are large but not infinite, and more importantly, they are not persistent. The context available in a given session is exactly what you put into it at the start of that session. If you want the agent to know what happened last week, you have to find that information, retrieve it, and include it — every time. The agent contributes nothing to this process; it is entirely the application developer's responsibility.

RAG is a retrieval mechanism, not a memory architecture. It answers the question “given a query, what documents are relevant?” — a useful capability, but not the same as “what has this agent learned about this domain across the past six months of operation?” RAG retrieves what you stored. Memory accumulates what the agent learned.

Session persistence in a database is the closest to a real solution — but it is a primitive one. Storing chat histories gives you access to raw conversational records; it does not give you structured, queryable institutional knowledge. The difference is the difference between a stack of email archives and a knowledge management system.

Fleet Deployments Expose the Gap

For single-agent deployments — one agent, used episodically, by a single person — the memory gap is manageable. You can re-inject context at session start. The friction is real but tolerable.

Fleet deployments — multiple agents, operating continuously, producing outputs that depend on each other — make the memory gap structural. When Agent A's analysis informs Agent B's recommendation, and Agent B's recommendation informs a human decision, and that human decision needs to be audited three months later: the memory gap is not a friction problem anymore. It is a correctness problem and a compliance problem.

The questions that fleet deployments have to answer — and that regulators are now starting to require answers to — are not protocol questions. They are memory questions:

What did each agent know at the time it acted? What context was active, and how did it get there? When the analysis changed — when the agent updated its assessment — what was the previous assessment, and what caused the update? Which agents shared information with which others, and through what mechanism? Who reviewed the agents' outputs, and what did they see when they reviewed them?

These questions have no answers in a deployment built purely on the protocol layer. They require memory infrastructure — persistent, structured, auditable — that most fleet deployments do not have.

The organizations that are building serious AI deployments will encounter MCP as a protocol win and a memory problem. The ones that recognize the distinction early will build the memory layer deliberately. The ones that don't will discover it is missing in the worst possible circumstances.

The Architecture That Works

The correct architecture uses MCP and memory infrastructure as complementary layers, not substitutes. MCP handles the protocol question: how does the agent communicate with its tools in a standardized, composable way? Memory infrastructure handles the continuity question: what does the agent carry forward from prior operation, and how is that knowledge maintained, updated, and made available to human oversight?

Memory infrastructure, built properly, has four properties that RAG and session persistence do not provide. It is structured — organized as knowledge, not as conversational records, so that it can be queried by the agent and by auditors using the same interface. It is accumulative — it grows over time as the agent operates, incorporating new observations without replacing prior ones. It isversioned — every update to the memory state is recorded, so that the state at any prior point in time can be reconstructed. And it is attributable— every memory entry is traceable to the agent that created it, the session in which it was created, and the observations that supported it.

The versioning and attributability properties are not primarily useful to the agent. They are useful to the humans responsible for the fleet — and to the regulators who will ask, under the Colorado AI Act and EU AI Act, to see the record of how the agent's knowledge and decisions evolved.

What the MCP Ecosystem Needs Next

MCP is the right answer to the interoperability problem. The ecosystem being built around it — tool servers, client implementations, orchestration frameworks — is building the right layer. The next layer that the ecosystem needs is not another protocol; it is an infrastructure product that handles the memory problem with the same seriousness that MCP handles the integration problem.

That product needs to be composable with MCP, not competitive with it. Agents that access tools via MCP should be able to persist what they learned from those tool interactions into a structured memory layer — without the application developer having to build a custom memory system from scratch. The integration between the protocol layer and the memory layer should be as standardized as the integration between the agent and the tool.

The fleet problem and the accountability problem are not orthogonal to MCP's success — they are the problems that become visible once MCP succeeds. When every agent can talk to every tool, the question that surfaces is: what does the fleet remember, and who is responsible for what it decides?

Those are memory and governance questions. MCP pointed to them. The next layer of infrastructure has to answer them.