MCP as the control plane: why the interesting agent work is now orchestration

For most of the last few years, the way we thought about AI coding tools was borrowed from autocomplete. Line-level at first: Copilot predicts the next few tokens, you accept or reject. Then task-level: you give Claude Code a prompt, it returns a diff, you review and merge. Bigger context window, better model, same mental model. One agent, one person watching, one pass to review.

That model fits a single task. It breaks when you try to run four tasks at once.

the control-plane problem

There is a useful distinction in networking between the data plane and the control plane. The data plane moves packets: it is fast, repetitive, and largely mechanical. The control plane makes routing decisions: it tracks state, enforces policy, and decides what gets forwarded where.

AI coding has an equivalent split. The data plane is code being written: an agent running in a worktree, making tool calls, generating diffs. The control plane is everything else: deciding which task to run next, handing context to a starting agent, approving or sending back a completed phase, tracking which worktrees are in flight, merging when the quality bar is met.

When you have one agent, you are the control plane. The overhead is low: paste context, read diff, approve. When you have four agents running in parallel, the control-plane work is the bottleneck. You are doing clipboard management at 11pm, trying to remember which branch had the migration, copying the same spec section into three separate sessions, and answering the same scope question four times in slightly different wordings. The agents got faster. The coordination did not.

why "more autonomy" does not solve it

The obvious response is to push the autonomy further. Let the agent plan, approve its own phases, merge on its own judgment. For a throwaway prototype on a Friday afternoon, fine. For a system you have to maintain, that approach fails in a specific and consistent way: it is confident, it is fast, and it has no stake in the downstream consequences. An agent left alone will optimize for "task done," not for "product still works," and the two diverge more than you expect.

Full manual review fails the other direction. Three agents each producing a 500-line diff in 20 minutes is not a review load a person can sustain carefully for long. The volume breaks the human attention model. So the two poles both fail: raw autonomy ships drift, full manual review does not scale. The interesting design space is in between, and it is about structure rather than autonomy settings.

what a control plane for agents looks like

When you want to hand the coordination job to a manager agent rather than a person, you need a real interface. Not a prompt. An interface, with the operations that coordination actually requires.

Those operations are a short list. Addressability: send a message or a stop signal to a specific running agent, not all agents. State inspection: read what stage each task is at, what the current diff looks like, whether the review passed. Control operations: start a task, approve a phase, send it back with a note, merge the PR when the gates are met. Backlog management: read the queue, create or modify tasks, prioritize what runs next.

These are not exotic requirements. They are the operations of any coordination layer. The reason they matter is that without them, a manager agent can only communicate over text, which means it cannot actually hold a quality bar. "Check whether the diff is acceptable" is not a stable instruction when the manager cannot read the diff. "Only merge if the review passed" is not enforceable when the manager cannot inspect the gate state. The control plane needs reads and writes, not just sends.

MCP is becoming that substrate

Model Context Protocol was designed around tool use and context injection: give an agent access to a filesystem, a database, an API call. A tool takes inputs and returns a result. That is the simple case.

As multi-agent systems mature, MCP is evolving into something more interesting: the protocol by which an agent addresses and drives another agent. "Start task X" is not a simple function call if task X triggers a pipeline of sub-agents, each running in a separate worktree, with gates between them that hold quality before the next stage begins. The MCP tool call is the control-plane operation. The execution behind it is a complex orchestrated process the manager does not need to know about.

This is the right abstraction level. The manager agent thinks in tasks and backlogs and approvals. The execution engine thinks in worktrees and stages and specialist reviewers. Neither needs to understand the internals of the other. The protocol defines what is exchangeable: start, inspect, approve, reject, merge. As long as both sides speak that language, the execution engine can be as sophisticated as it needs to be without leaking that complexity into the manager's decision-making.

the economics shift at scale

With one agent, the bottleneck is model speed. The coordination overhead from adding a manager is roughly the cost of the management, and for a single task that cost is not worth paying.

With four or six parallel agents, the math flips. The bottleneck is coordination. A manager that can drive all six, inspect their states, and hold the gates across them does not add cost proportionally. It multiplies effective throughput. The agent doing design review is not blocking the agent writing the authentication module. The manager routes the approval to the right place while everything else continues running.

The economic case for a control plane grows with agent count, and most teams running more than two parallel agents today are leaving most of that leverage on the table because the coordination is still manual.

what the gates are still for

A control plane that approves everything is not a control plane. It is automation with extra steps. The value of delegating coordination to a manager agent is that the manager handles the routine decisions and the gates still hold the hard ones.

This is the same distinction a good senior engineer makes: you do not read every line with equal attention. You focus on the decisions that are hard to reverse. A scope change that bleeds across three modules is different from a bounded fix in one function. A security surface is different from a UI label. The manager agent can learn to route those differently, approving the bounded work and escalating the cross-cutting changes back to a human. That is not full autonomy. It is sensible delegation, with the quality gates doing the work they were built to do.

defract runs each task through a fixed pipeline, from story through design and architecture into implementation and review, with specialist reviewers that check security and structure before a gated merge. The pipeline runs on local worktrees; you bring your own Claude subscription and your own GitHub.

In version 1.5.0 we added an MCP server that makes the control-plane interface explicit. An outside agent, Claude or any MCP-capable client, can drive the full pipeline over MCP: groom the backlog, start tasks, approve or send back implementation phases, inspect diffs, choose the model for a stage, message or stop a running agent, and merge the PR. It runs the same code path as the buttons in the app, so the gates do not move when the manager is an agent rather than a person. The control plane is real, not simulated. See also what the interface between a manager agent and a development pipeline actually needs and the broader pattern of agentic coding patterns that hold at scale.