MCP and the Unbundling of Agent Frameworks
How the Model Context Protocol enables decomposing monolithic agent frameworks into composable, replaceable services.
Every major agent framework today ships as a monolith. LangChain bundles tool calling with memory with orchestration with output parsing. CrewAI bundles role definitions with task routing with inter-agent communication. Microsoft’s Agent Framework bundles state management with plugin execution with conversation handling. If you want one piece, you take the whole stack.
This is the natural starting point for any platform. Web frameworks started the same way — Rails shipped with an ORM, a template engine, a mailer, a job queue, and an asset pipeline in one box. But web development didn’t stay monolithic. Standardized interfaces (HTTP, SQL, REST, GraphQL) allowed each concern to be handled by the best available tool. The ORM became a choice. The template engine became a choice. The job queue became a choice.
MCP is emerging as the kind of standardized interface that could do the same thing to agent frameworks. The architectural pressure is already visible in how practitioners are starting to mix tools from different ecosystems.
The bundling tax
The monolithic approach has real costs that compound as agent systems move from prototype to production.
Upgrade coupling. When your framework ships a new version, you get changes to memory, orchestration, tool calling, and evaluation all at once. A breaking change in the prompt templating layer forces you to update even if you only needed the fix in the tool calling layer. Teams running production agents learn to dread major version bumps.
Capability ceiling. Each framework makes opinionated choices about memory architecture, planning strategy, and state representation. These choices are reasonable defaults, but they become ceilings when your use case demands something the framework designers didn’t anticipate. Swapping out the memory layer means fighting the framework, not extending it.
Evaluation lock-in. Frameworks that bundle evaluation with execution create a subtle lock-in: your evaluation datasets, metrics, and pipelines become tied to framework-specific trace formats and data structures. Moving to a different framework means rebuilding your evaluation infrastructure from scratch — often the most expensive part of an agent system.
| Concern | What it handles | Cost of coupling |
|---|---|---|
| Tool calling | Schema definition, invocation, result parsing | Can’t mix tool providers across frameworks |
| Memory | Short-term context, long-term storage, retrieval | Locked to framework’s memory model |
| Orchestration | Agent loops, planning, task decomposition | Can’t use a better planner without full migration |
| State management | Conversation state, checkpointing, recovery | State format is framework-specific, not portable |
| Evaluation | Traces, metrics, quality assessment | Eval pipelines tied to framework internals |
None of this is a problem when you’re prototyping. The monolith is genuinely faster for getting something working. The tax arrives when you need to change one thing without changing everything else.
MCP as the unbundling layer
MCP was designed as a protocol for connecting agents to tools, but its architecture is more general than that. The protocol defines three primitives — tools, resources, and prompts — communicated over a standardized transport layer. Any client that speaks MCP can connect to any server that speaks MCP.
This standardization creates the conditions for unbundling. When every tool exposes the same interface, tool servers become interchangeable. When resources follow a standard schema, memory servers become interchangeable. When prompts are protocol-level objects, prompt management becomes a separable concern.
The critical shift isn’t technical — it’s organizational. MCP means a team can build a specialized memory server that works with LangChain, CrewAI, and a custom agent loop equally well. The memory team doesn’t need to understand the orchestration framework. The orchestration framework doesn’t need to understand the memory implementation. The interface contract handles the boundary.
MONOLITHIC UNBUNDLED (MCP-connected)
┌─────────────────────────┐ ┌──────────────┐
│ Agent Framework │ │ Agent Core │
│ ┌───────┐ ┌──────────┐ │ │ (orchestration│
│ │ Tools │ │ Memory │ │ │ + routing) │
│ ├───────┤ ├──────────┤ │ └──────┬───────┘
│ │Orchestr│ │ State │ │ │ MCP
│ ├───────┤ ├──────────┤ │ ┌──────┼───────────────┐
│ │ Eval │ │ Prompts │ │ │ │ │
│ └───────┘ └──────────┘ │ ┌────▼───┐ ┌▼─────────┐ ┌──▼──────┐
└─────────────────────────┘ │Tool │ │Memory │ │Eval │
│Servers │ │Server │ │Server │
Everything changes together └────────┘ └──────────┘ └─────────┘
Each component versioned independently What the unbundled stack looks like
The unbundling won’t happen all at once. Tool servers are already disaggregated — that’s what MCP was designed for. Memory, evaluation, and orchestration will follow, but each on its own timeline.
Tools: already unbundled
This is the layer where MCP has had immediate impact. Hundreds of MCP tool servers already exist for file systems, databases, APIs, code execution, and web browsing. An agent built on any framework can connect to any of these servers. The tool layer is effectively decoupled.
The implication is practical: stop building custom tool integrations inside your framework. If an MCP server exists for the capability you need, use it. If it doesn’t, build the integration as an MCP server so it’s reusable across projects and frameworks.
Memory: unbundling in progress
Memory is the next frontier. Today, each framework implements its own memory abstraction — LangGraph has its state graph, LangChain has its memory classes, and most custom agents roll their own combination of vector stores and key-value caches.
MCP’s resource primitive is the natural interface for memory servers. A memory server exposes stored context as resources that any MCP client can read, and accepts new memories through tool calls that any client can invoke. The memory implementation — whether it’s a vector store, a knowledge graph, or a structured database — becomes an implementation detail behind a standard interface.
Early examples of this pattern are already in production. Teams are building MCP servers that wrap their memory infrastructure, giving agents a clean read/write interface without coupling to a specific framework’s memory model.
Orchestration: the last monolith
Orchestration — the agent loop itself — is the hardest layer to unbundle and will likely remain framework-coupled longest. The orchestration layer decides what to do next: should the agent call a tool, query memory, ask the user for clarification, or declare the task complete? This decision logic is tightly coupled to state representation, which makes it hard to standardize.
But even here, MCP creates pressure toward decomposition. When tools and memory are external services, the orchestration layer simplifies to a decision loop that reads state, decides on an action, and dispatches it through MCP. The thinner the orchestration layer becomes, the less lock-in it creates.
If tools, memory, and evaluation are all MCP servers, then the “agent framework” reduces to an MCP router — a thin layer that decides which server to call next based on the current state. This is speculative, but the architectural direction is clear. The framework of 2027 may be primarily a routing and decision layer, not a full application stack.
Evaluation: the quiet unbundling
Evaluation is unbundling almost accidentally. As standardized trace formats like OpenTelemetry gain adoption in agent systems, evaluation pipelines can consume traces from any framework that emits them. The evaluation logic — “did this agent produce a correct answer?” — doesn’t need to know whether the agent was built with LangChain or a custom loop. It just needs the trace.
MCP accelerates this by standardizing the interface to evaluation tools themselves. An evaluation server that scores agent outputs can be connected to any agent through MCP, turning evaluation from a framework feature into an independent service.
The microservices parallel — and its warnings
If this sounds familiar, it should. The agent framework unbundling follows the same trajectory as the monolith-to-microservices transition in web development. And that transition carried real costs alongside its benefits.
| Dimension | Monolithic framework | Unbundled (MCP-connected) |
|---|---|---|
| Getting started | Fast — one install, one API | Slower — must configure multiple services |
| Debugging | Single process, linear traces | Distributed traces across services |
| Flexibility | Limited to framework’s abstractions | Mix best-of-breed components |
| Upgrade path | All-or-nothing version bumps | Upgrade individual components |
| Team autonomy | Everyone shares one dependency | Teams own their services independently |
| Operational overhead | Low — one deployment unit | Higher — multiple services to manage |
The web development community learned that microservices solve organizational problems (team autonomy, independent deployment) more than technical problems. Small teams with simple applications were often worse off after decomposition. The same will be true for agent systems.
If you’re a small team with a single agent handling a well-defined task, a monolithic framework is almost certainly the right choice. The unbundled architecture pays off when you have multiple agents, multiple teams, or requirements that exceed what a single framework provides. Premature decomposition adds operational complexity without delivering proportional value.
The debugging problem deserves special attention. In a monolithic framework, an agent’s execution trace is a single linear sequence. In an unbundled system, a single agent action might traverse three MCP servers, each with its own logs and failure modes. Distributed tracing — already standard practice in microservice architectures — becomes essential for agent systems the moment you move beyond a single framework.
Implications for practitioners
The unbundling is directional, not immediate. Here’s how to position yourself for it without over-engineering today.
Design for interface boundaries, not framework APIs. When you build a memory system, wrap it in a clean interface that could become an MCP server later. When you build evaluation pipelines, consume standardized traces rather than framework-specific data structures. This costs almost nothing today and preserves future flexibility.
Invest in MCP server development. The skill that transfers across the coming framework churn is building and operating MCP servers. Every integration you build as an MCP server is reusable regardless of which framework you use next year. Every integration you build as a framework-specific plugin is locked to that framework’s lifecycle.
Watch the memory protocol space. Tool calling over MCP is a solved problem. Memory over MCP is not. The teams and projects that define standard memory interfaces will shape how agent memory works for years. If you’re building memory-heavy agent systems, paying attention to emerging memory server patterns is high-leverage.
Keep your orchestration thin. The less logic you put in the orchestration layer, the less you lose when you change frameworks. Push complexity into tools (which are already MCP-portable) and memory (which is becoming portable) rather than into framework-specific orchestration code.
For every component in your agent system, ask: “Could I replace the framework underneath this without rewriting this component?” If the answer is no, that component is tightly coupled and represents migration risk. MCP-based components will increasingly pass this test; framework-specific components won’t.
What this means for the framework ecosystem
The monolithic agent framework won’t disappear. Rails didn’t disappear when the web ecosystem unbundled — it adapted, becoming more modular while retaining the convenience of an integrated stack. LangChain and its peers will likely follow the same path: maintaining a cohesive developer experience while opening standard interfaces for component replacement.
The winners in the unbundled world will be the teams building best-of-breed components behind MCP interfaces. A memory server that handles episodic, semantic, and procedural memory better than any framework’s built-in memory will find adoption across every framework. An evaluation server with superior scoring models will plug into any agent system that emits standard traces.
The most significant change will be in how practitioners think about agent architecture. Today, choosing an agent framework is a high-stakes, hard-to-reverse decision that shapes everything downstream. In the unbundled future, the framework choice becomes less consequential — a routing and orchestration preference, not a platform commitment. The real architectural decisions will be which memory model to use, which evaluation strategy to adopt, and how to compose capabilities across MCP servers.
That shift — from framework selection to component composition — is the real unbundling. MCP is the mechanism, but the end result is an agent ecosystem where the best tools win regardless of which framework they were built for.