agents managing agents: what changes when your orchestrator is itself an agent

For about two years the whole industry has been optimizing one thing: how fast a single coding agent can go from a prompt to a diff. Better models, bigger context windows, tighter edit loops, faster tool calls. That work paid off. The individual agent is no longer the slow part. On a well-scoped task, one good agent now writes correct code faster than most of us can review it.

Which is exactly the problem. Once the writing is cheap, the bottleneck moves. It moves to the thing that was always the real work: deciding what to build, running several pieces of it at once without them colliding, and trusting the result enough to ship it. That is not a model problem. It is a coordination problem. And coordination is the part we have barely started on.

the bottleneck moved and nobody rebuilt for it

Think about what a senior engineer actually does on a team. Not much of it is typing. They break a vague request into tasks. They decide which three can run in parallel and which one has to go first. They read a diff and ask the question the author did not think of. They say "not yet, fix this first" and mean it. They keep a mental model of why the system is shaped the way it is, so the next change does not quietly undo the last one.

That is management, in the honest sense of the word: keeping several threads of work coherent and holding a quality bar. When you run three or four coding agents at once, somebody has to do that job. Right now that somebody is you, in a terminal, flipping between panes, re-pasting context, and trying to remember which worktree had the migration. The agents got faster. The coordination layer is still a human doing clipboard work at 11pm.

why "more autonomy" is the wrong fix

The tempting answer is to turn the autonomy dial up. Let the agent plan, write, test, and merge on its own. Walk away. And for a throwaway script or a weekend prototype, fine, do that. But for anything you have to maintain, raw autonomy fails in a specific and predictable way: it is confident, it is fast, and it has no stake in being right. A single agent left alone will happily merge code that passes its own tests and still breaks the system, because it optimized for "task done," not for "product still works."

You cannot review your way out of that either, not at agent speed. If three agents each produce a 600-line diff in twenty minutes, "I will just read everything carefully" is a lie you tell yourself for a week before you stop reading carefully. The volume breaks the human review model. So the two obvious options both fail: full autonomy ships slop, and full manual review does not scale. The interesting answer is in between, and it is structural.

an agent that manages, not an agent that codes

Here is the shift worth paying attention to. Instead of making the coding agent more autonomous, you add a different kind of agent on top: one whose whole job is to manage the others. Not to write the feature. To groom the backlog into real tasks, decide what runs now, watch the diffs come back, send work back when it is not good enough, and only merge when a gate is actually met.

This is not a cosmetic relabeling. A manager agent is doing a genuinely different job from a coding agent, and it wants different things. It wants a stable process to drive, not a blank terminal. It wants explicit stages with checkpoints, so "approve" and "send back" are real operations and not vibes. It wants to see diffs and test results, not just a cheerful summary. It wants the authority to say no. When you give an agent those affordances, it can hold the coordination load that is currently falling on you, and it can do it across more parallel work than you could track by hand.

The important part is the gates. An agent managing agents with no gates is just a bigger, faster way to merge bad code, now with an extra layer of plausible-sounding confidence. The value is not in removing the human. It is in moving the human from "read every line of every diff" up to "set the bar and handle the exceptions." The manager agent runs the routine coordination. You own the policy and the edge cases. That is a job a person can actually keep up with at agent speed.

process is the trust mechanism

We tend to talk about trusting AI as if it were a property of the model. It is not. On a human team you do not trust a senior engineer because they are smart. You trust them because of the process around them: they write a plan you can object to, their work goes through review, there is a gate before it hits main, and there is a record of why things were decided. The process is what lets you delegate to someone you cannot personally double-check on every line.

Agents are no different. An agent you trust is not a better model. It is an agent operating inside a process with real checkpoints, where the risky steps are gated, where the diff is inspectable, and where "send this back" is a button that works. Once that scaffolding exists, it does not matter much whether a human or another agent is pressing the buttons. The checkpoints do the work. That is the quiet realization underneath "agents managing agents": if your process is good enough to let an agent drive it safely, it was probably good enough to trust in the first place. And if it is not, adding autonomy only makes the failure faster.

what this looks like in practice

This is the problem defract has been built around, so take the next paragraph as one concrete implementation rather than the only one. defract runs each task through a fixed lifecycle, story then design then architecture then implementation then review then release, with parallel git worktrees so several tasks run without stepping on each other, and specialist review agents that check security and structure before a gated merge. The code and the terminal transcripts stay on your machine; you bring your own Claude Code subscription and your own GitHub.

In 1.5 we added an MCP server, which is the part that makes the "manager" idea literal. An outside agent, Claude or ChatGPT or Codex, can drive the whole thing over MCP: groom the backlog with full create-read-update-delete, start a task, approve or send back each implementation phase, inspect the diffs, pick the model for a stage, message or stop a running stage agent, and merge the pull request. It runs the exact same code path as the buttons in the app, so an agent-driven run behaves identically to one a person clicked through. The gates do not move. The manager agent gets the affordances a manager needs, and the checkpoints still hold.

You do not have to use any of that to take the point. The point is that the next hard problem in AI development is not a faster writer. It is a trustworthy coordinator, and trust comes from process, not from autonomy. The teams that get ahead over the next year will not be the ones whose agents type fastest. They will be the ones who build the checkpoints first, and then let either a person or an agent drive them. Build the process you would trust a new senior hire to run. Then it will not matter who, or what, is holding the clipboard.