Agentic AI Is Micro-kernel Plus Lambda Architecture
Dean Jain
Senior Staff Software Engineer · Enterprise AI, Data & Cloud Architect
· 9 min read
Three old architecture styles and what each one became in the agent stack. The fourth row is the one with no ancestor.
On 28 July 2026, the MCP specification removed its own handshake. MCP is the protocol that connects tools to a language model. The initialize exchange is gone. The Mcp-Session-Id header is gone. Every request now carries its own version, identity, and capabilities. The spec says a server can now sit “behind a plain round-robin load balancer.”
We have made this exact change before. We made it to REST services about ten years ago. Make requests self-describing. Drop session affinity. Scale out on ordinary infrastructure.
So why did a protocol built for language models have to learn this again in 2026?
Because it is not a new kind of system. The agent stack is two old architecture styles rebuilt with new parts. Micro-kernel became the agent host. Lambda Architecture became the way models learn.
TL;DR
- The agent host is a micro-kernel. A small core you cannot change often, with plugins growing around it through one shared interface. That is the plugin style from IDEs like Eclipse and VS Code, and MCP is its interface.
- The way LLM learn is Lambda Architecture. Training is the batch layer: all the data, slow, stale. Retrieval is the speed layer: fresh, fast, approximate. Inference is the serving layer that merges them.
- The July 2026 MCP release proves the point. Stateless transport, an extensions framework, sandboxed plugin UIs, and a 12-month deprecation policy. Plugin ecosystems always hit those four milestones.
- Agents calling agents is a different style again. Host-to-tool is vertical and is micro-kernel. Agent-to-agent is horizontal and is SOA, which charges the usual SOA bill.
- New Ways. The plugin interface is written in English. Tool calls are chosen by chance, not by code. The merge between training and retrieval is learned, not written. That is where the new engineering is.
1. The agent host is a micro-kernel
The micro-kernel style, also called the plugin style, has one job. Keep a small core stable. Let independent plugins grow around it through one shared interface. Eclipse and VS Code are the examples most engineers already know.
It fits one situation. The core is expensive to change, and the capabilities need to grow every week.
That situation has never been sharper. A frontier model, meaning one of the large general-purpose models like GPT or Claude, costs millions to train and months to produce. You cannot patch it on a Tuesday. So all the speed moves to the edges. That is why this style won for AI, while microservices won the 2010s.
---
config:
theme: dark
fontSize: 17
themeVariables:
fontFamily: "Comic Sans MS, Comic Neue, Chalkboard SE, cursive"
---
flowchart TD
HOST["🤖 Agent host<br/>model + runtime<br/>(small core, costly to change)"]:::agent
HOST --> T1["🔧 MCP server<br/>filesystem"]:::server
HOST --> T2["🗄️ MCP server<br/>database"]:::server
HOST --> T3["🌐 MCP server<br/>SaaS / APIs"]:::server
HOST --> SK["🧩 Skills<br/>packaged behaviours"]:::good
HOST --> AG["🐝 Sub-agents<br/>capability as plugin"]:::good
REG["📚 Registry<br/>discovery + provenance"]:::gov -.-> HOST
GATE["🛡️ Permissions<br/>+ sandbox"]:::gate -.-> HOST
classDef agent fill:#FFE08A,stroke:#E8A33D,stroke-width:2px,color:#0F172A
classDef server fill:#A8E6D0,stroke:#2FA37C,stroke-width:2px,color:#0F172A
classDef good fill:#BFEFC8,stroke:#3FA34D,stroke-width:2px,color:#0F172A
classDef gov fill:#E0D6F5,stroke:#9B7EDE,stroke-width:2px,color:#0F172A
classDef gate fill:#D7C3F2,stroke:#8E5BD0,stroke-width:2px,color:#0F172A
Figure 1: The agent stack drawn plainly. A small core, independent capabilities, one shared interface, a registry for discovery, and a permission layer for isolation.
The mapping is not a loose analogy. It is one to one.
| Micro-kernel concept | What it is in the agent stack |
|---|---|
| Small core | The model plus the host runtime around it |
| Plugin | An MCP server, a tool, a skill, or a sub-agent |
| Shared plugin interface | MCP, spec version 2026-07-28 |
| Plugin registry | The official MCP Registry, live since Sept 2025 |
| Plugin isolation | Tool permissions and sandboxes that limit what a plugin can reach |
The July release did not just add features. It hit four standard plugin-ecosystem milestones at once. Each one has a clear ancestor.
- Stateless transport. Requests describe themselves, so any server instance can answer any request. This is the microservices lesson arriving late, because plugins stopped being local libraries and became remote services.
- An extensions framework. Two features, long-running tasks and plugin UIs, moved out of the core and into optional extensions. That is a standards group protecting the small core on purpose.
- MCP Apps. Servers can now ship interactive UX/HTML that the host renders in a sandboxed frame.
- A deprecation policy. A 12-month minimum window before anything is removed. Ecosystems adopt this once breaking changes start costing money.
2. The way models learn is Lambda Architecture
Lambda Architecture answered one question for big data. How do you get both completeness and freshness over a dataset too large to recompute quickly?
The answer was two pipelines. A batch layer that is slow, accurate, and processes everything. A speed layer that is fast, approximate, and only covers recent data. Then a serving layer that merges the two so callers never see the join.
I built one of these. Around 2016 I led a Hadoop-based data deduplication engine with exactly that split, a batch path and a real-time path, with a Spark platform feeding it. The cost of running two pipelines was real. So was the reason we paid it.
Now look at how any production AI system takes in knowledge.
---
config:
theme: dark
fontSize: 17
themeVariables:
fontFamily: "Comic Sans MS, Comic Neue, Chalkboard SE, cursive"
---
flowchart LR
DATA["🌍 The world's<br/>knowledge"]:::gov --> BATCH["🏋️ Training / fine-tuning<br/>all data · slow · accurate · stale<br/><b>= BATCH layer</b>"]:::obs
DATA --> SPEED["⚡ Retrieval / RAG<br/>fresh data · fast · approximate<br/><b>= SPEED layer</b>"]:::warn
BATCH --> SERVE["🎯 Inference<br/>merges weights + context<br/><b>= SERVING layer</b>"]:::good
SPEED --> SERVE
SERVE --> OUT["💬 Answer<br/>join is invisible"]:::neutral
classDef gov fill:#E0D6F5,stroke:#9B7EDE,stroke-width:2px,color:#0F172A
classDef obs fill:#AED6F1,stroke:#2E86C1,stroke-width:2px,color:#0F172A
classDef warn fill:#FFE6A8,stroke:#E0A106,stroke-width:2px,color:#0F172A
classDef good fill:#BFEFC8,stroke:#3FA34D,stroke-width:2px,color:#0F172A
classDef neutral fill:#ECECEC,stroke:#8A8A8A,stroke-width:2px,color:#0F172A
Figure 2: Lambda Architecture in its 2026 form. Training is the batch layer. Retrieval is the speed layer covering the gap. Inference is the serving layer that merges them.
- Training and fine-tuning are the batch layer. Slow, very expensive, uses all the data, and always stale. A model’s weights are a snapshot of the world from some months ago.
- Retrieval is the speed layer. This is RAG: fetch the relevant documents at question time and put them in the prompt. Fast and approximate. It covers exactly what training has not caught up to, such as your documents, today’s data, and this customer’s history.
- Inference is the serving layer. It merges slow knowledge from the weights with fresh context from retrieval. The user never sees the join.
Nobody planned this. The same two pressures, completeness against freshness, produced the same shape twelve years apart.
There is a fair objection here. Context windows are huge now, so why not put everything in the prompt and skip retrieval? Because it does not hold up under measurement. Chroma’s context rot study tested 18 models and found accuracy dropping unevenly as input grew, well before the stated window limit. Every model family did better with a short focused prompt than with a very long one containing the same answer. Relevance is not free. So the 2026 default is both layers: retrieve down to a focused window, then reason over that.
3. Agents calling agents is not micro-kernel. It is SOA.
Micro-kernel describes the vertical axis: one host, many tools underneath it. It says nothing about the horizontal axis, where agents call other agents as peers. A2A is the protocol for that second axis. It moved to the Linux Foundation in June 2025 and passed 150 supporting organisations by April 2026.
Peer services with published contracts, finding each other and negotiating work, is not micro-kernel. That is SOA, the service-oriented style that microservices grew out of.
---
config:
theme: dark
fontSize: 17
themeVariables:
fontFamily: "Comic Sans MS, Comic Neue, Chalkboard SE, cursive"
---
flowchart TB
subgraph V["⬇️ Vertical axis MCP · micro-kernel"]
H["🤖 Agent host"]:::agent --> P1["🔧 Tool"]:::server
H --> P2["🔧 Tool"]:::server
end
subgraph HZ["➡️ Horizontal axis A2A · SOA"]
A1["🐝 Agent A"]:::agent <--> A2["🐝 Agent B"]:::agent
A2 <--> A3["🐝 Agent C"]:::agent
end
V --> COST["💸 What you pay:<br/>chance-based calls + ~15× cost<br/>+ distributed debugging"]:::danger
HZ --> COST
classDef agent fill:#FFE08A,stroke:#E8A33D,stroke-width:2px,color:#0F172A
classDef server fill:#A8E6D0,stroke:#2FA37C,stroke-width:2px,color:#0F172A
classDef danger fill:#FFB3B3,stroke:#D14545,stroke-width:2px,color:#0F172A
Figure 3: Two axes and two different styles. MCP is micro-kernel. A2A is SOA. Treating them as one thing is how teams pay the SOA cost without getting the benefit.
This matters because SOA charges its usual bill. Anthropic reported its multi-agent research system using roughly 15 times the tokens of a normal chat. Tokens are the units a model is billed by, so that is close to a 15x cost increase. Cognition argued the other side: do not build multi-agent systems, stay single-threaded. They were half right, for the same reason most of us pulled back from microservices. Distribution buys parallelism and costs coherence.
The pattern the field settled on says a lot. One orchestrator owns the conversation. It spawns short-lived sub-agents that return a summary and never talk to each other. That is sub-agents as plugins, not as peers. A deliberate choice of micro-kernel over SOA.
4. Where the comparison stops working
So far everything has carried over. Three things do not. There is no compiler for intent, no branch in the code, and no merge function you can read.
| What broke | Before | Now | What to do about it |
|---|---|---|---|
| The interface | A schema a machine can check | English the model reads. The tool description is what drives behaviour | Treat descriptions and responses as untrusted input. Signing and code review cannot make a sentence safe. The attack has a name: tool poisoning |
| The dispatch | You clicked, code branched | The model predicts a likely next step, so the same input can give different calls | Instrument every step. The OpenTelemetry GenAI conventions give standard spans for agent steps and tool calls. Your debugger is now a trace |
| The merge | You wrote the merge function and could test it | The model decides how much to trust a retrieved document against its training | Score it, do not assert it. Evals replaced assertions test suites that score output across many examples instead of checking one answer |
Key takeaways
Architecture styles are not fashion. They are stable answers to stable pressures: an expensive core, capabilities that must grow, completeness against freshness. Those pressures do not care what decade it is or what the parts are made of.
| Your constraint | Use | The cost you accept |
|---|---|---|
| Knowledge changes daily | Retrieval / RAG (speed layer) | Retrieval infrastructure; approximate grounding |
| Deep domain skill, stable content | Fine-tuning (batch layer) | Staleness between refreshes |
| Both completeness and freshness | Fine-tuning plus retrieval (full Lambda) | Two pipelines to run, the old Lambda complaint |
| Capabilities must grow weekly | MCP tools (micro-kernel) | A plugin surface you secure and version forever |
| Work crosses org or vendor lines | A2A (SOA) | Every distributed-systems problem, plus non-determinism |
I wrote up these architecture styles a decade ago assuming they would age out. They got rebuilt instead.
Further reading
- MCP specification 2026-07-28 · the release post stateless core, extensions framework, deprecation policy
- MCP Apps sandboxed plugin UIs, the plugin-webview moment
- Chroma: Context Rot 18 models, and the measured case for keeping a retrieval layer
- Anthropic: multi-agent research system · Cognition: Don’t Build Multi-Agents both sides of the orchestration argument
- A2A Protocol the horizontal axis, at the Linux Foundation
- Questioning the Lambda Architecture Jay Kreps’ original argument against running two pipelines
- Software Architecture Styles + Lambda Architecture my 2016 write-up of the styles this stack was built from
- Productionizing MCP Part 1 · Part 2 the hands-on version, including MCP security