Building a 14-agent tool-use platform with MCP

// agentic systems

Single agents are easy. You give a model some tools, let it loop, and it gets useful work done. The difficulty arrives when one agent is not enough and you need a fleet of them to cooperate on a long-running goal. Mission Control is a platform I built for exactly that: fourteen agents, each with a role, coordinating through a shared substrate rather than a tangle of direct calls. This post is about the architecture, and about what turned out to be genuinely hard.

Why not one big agent

The temptation with a capable model is to keep stuffing more tools and more instructions into a single context. It works until it does not. Long contexts dilute attention, unrelated tools interfere with each other, and one mistake contaminates the entire run. Splitting the work into focused agents - each with a narrow role, a small tool set and its own context - keeps every individual decision tractable. The cost is that you now have a distributed system, with all the coordination problems that implies.

Mailbox messaging

The first decision was how agents talk to each other. Direct function calls between agents couple them tightly and make the system impossible to reason about once you pass a handful of participants. Instead, every agent has a mailbox. To collaborate, an agent writes a message addressed to another agent, and the recipient reads its inbox when it next runs.

This indirection buys a lot. Agents run asynchronously without blocking on each other. The full message history is a durable, inspectable log of who asked whom to do what, which is invaluable for debugging. And adding a fifteenth agent does not require touching the other fourteen - it just needs an address. The mental model is closer to an organisation passing memos than to functions calling functions, and that turned out to be the right abstraction for keeping fourteen moving parts comprehensible.

Persistent memory

Agents that forget everything between runs cannot pursue goals that outlast a single context window. Each agent has a persistent memory store it reads at the start of a turn and writes back to at the end. This holds working state, decisions already made, and facts learned along the way.

The hard part of memory is not storing it, it is deciding what is worth remembering. Writing everything back floods the context on the next read and reintroduces the dilution problem we split agents up to avoid. The discipline that worked was treating memory as a deliberate summary the agent maintains, not a transcript it accumulates.

Separating short-lived scratch reasoning from durable memory was the change that made long-running tasks actually reliable. An agent can think messily within a turn, then commit only the durable conclusions.

MCP tools

Every real capability in the system - reading data, calling services, taking actions in the world - is exposed through the Model Context Protocol. MCP gives a clean, uniform contract: a tool advertises its name, description and input schema, and any agent can discover and call it the same way.

The benefit at platform scale is that tools are decoupled from agents. A tool is implemented and tested once on an MCP server, then any of the fourteen agents can use it without bespoke wiring. It also draws a hard boundary between the model's reasoning and the system's real effects: the model can only act through declared tools, which is exactly where you want to put validation, permissions and logging. That boundary is what makes the whole thing auditable.

Human-in-the-loop

An autonomous fleet that can take consequential actions needs a brake. Certain actions are gated behind human approval: the agent prepares the action, explains its reasoning, and waits. A person reviews and approves or rejects before anything irreversible happens.

The design question is where to put the gates. Too many and the human becomes a bottleneck and stops reading carefully, which defeats the purpose. Too few and you have handed real authority to a system that will occasionally be confidently wrong. The answer was to gate on consequence, not on uncertainty: reversible, low-impact actions run freely, while anything irreversible or externally visible always pauses for a human, regardless of how confident the agent is.

What worked

The mailbox model. Decoupling agents through messages, with a durable log, made the system observable and made adding agents cheap.
MCP as the only path to action. One contract for every capability, reused across agents, with a clean place to enforce safety.
Memory as a maintained summary. Treating memory as something agents curate rather than accumulate kept contexts clean over long runs.

What was hard

Debugging emergent behaviour. When fourteen agents interact, a failure is rarely in one place. The message log was the single most important tool for tracing how a bad outcome actually unfolded.
Avoiding loops and stampedes. Agents can ping-pong messages or all pile onto the same task. This needed explicit coordination rules rather than hoping the models would sort it out.
Calibrating the human gates. Finding the line where a person adds safety without becoming a rubber stamp took iteration, and it is the part most specific to the deployment.

The honest summary is that the model reasoning was rarely the limiting factor. The engineering - messaging, memory hygiene, tool boundaries and the placement of human control - is what decided whether fourteen agents behaved like a team or like a crowd. Mission Control is a private client project, so this describes the architecture without any client data. If you want to see the underlying patterns in code, my open-source claude-fde-showcase demonstrates the MCP server, sub-agents and skills that the same ideas are built on.