I am the bottleneck

A month ago, my setup looked like this: VS Code, Claude Code in one pane, Codex in another, and a dev server in the terminal. Codex reviewed my drafts, Claude edited them, and I carried every review from one pane to the other.

Last week I moved to Herdr, an open-source multiplexer built for coding agents. It’s a far more agent-forward environment than an IDE: a space per repo, every agent’s state in one sidebar, and agents that can drive the app and rewrite its own configuration. I vibe coded my current layout onto a live instance in a single evening.

Here it’s running an optimizer-critic loop on my agent harness. In one pane, Claude Code runs an optimizer swarm: seven profiling agents, each auditing one part of the harness and writing a report on what to improve. In the other, Codex runs a critic swarm that reviews each report and returns a verdict, PASS or REVISE. A revised report goes back for another review. The two swarms never talk directly; they coordinate through a shared protocol file that sets the filenames, the verdict format, and the steps of the loop.

Herdr solved seeing my agents, down to every subagent in the tree. It didn’t solve the rest: more agents, more problems. When a profiler revised its report, nothing told the critics, so I noticed, added a DONE marker to the protocol, messaged all seven agents, and checked that each one picked it up. That’s the whole problem in miniature: one agent’s output changes what another should do, and I’m the one who detects it, routes it, and confirms it landed.

So how does one keep it all together, and what does that control plane look like? I’m not alone in asking. Anthropic’s recent report on how work has changed inside the company:

Amid this model-driven acceleration, human attention is a constant bottleneck.

In interactive sessions, roughly 80% of the time is the agent sitting idle, waiting for a person. For some non-technical teams, simply reading everything their agents produced would take more than half a work week. People are adapting by becoming, in the report’s words, managers of Claudes.

Why agents break the usual playbook

None of this is new to management. Teams have always had owners, dependencies, and escalation. What’s new is the volume and the speed. The usual playbook assumes people produce work at a human pace and can read each other’s output:

• Status is read on a human cadence. A standup or a ticket update comes daily. Agents can build on a stale assumption for hours before the next one.
• Coordination runs through conversation. “Tell the other team” works with two teams. It fails with forty sessions that nobody reads in full.
• Done means someone says so. Review catches problems when output is small. When it isn’t, “done” has to come with evidence.

Whatever replaces it has to work within fixed human attention, keep a person accountable, and not throttle the gains that made the agents worth running. I’m assuming agents that are capable and at least human quality within their domains; how far that holds today is a separate question.

Where today’s tools stand

• Multiplexers (T3 Code, Conductor, Herdr) organize around sessions. They make many agents visible and fast to switch between. Herdr goes furthest: agents report whether they’re working, blocked, or idle, and can prompt each other. But the screen still shows agents, and the person still connects their work.
• AgentCraft moves toward tasks: dependency-aware campaigns drawn on an RTS-style map, with merges gated on verification evidence.
• Paperclip works at the level of goals, budgets, and governance, closer to how an organization thinks.

The bottom-right corner is the one I care about: a screen built around the work, where routing is the system’s job and only decisions reach a person.

The hypothesis

The intuitive control plane isn’t a better multiplexer. It’s a different object, built on four claims:

1. Show the work, not the agents. Agents are interchangeable. Deliverables, dependencies, and commitments aren’t.
2. Only decisions reach a person. Whatever policy can settle, agents settle. What reaches you is a tradeoff, with its options and evidence.
3. Every decision closes on evidence. A decision isn’t done when it’s sent. It’s done when the affected work adopts it and passes verification again.
4. Attention is budgeted like compute. The system doesn’t start work faster than its people can steer it.

My protocol file is a hand-rolled version of all four, for one person and two swarms. A release spanning three teams can’t run on a hand-rolled file. So here’s the hypothesis at that scale.

A conflict, start to finish

Nine days before launch, the platform team ships a new payments API. The release needs a capability only the new API has. But the new API drops a field that a major customer’s integration relies on, under contract, and the customer can’t migrate before launch.

Here’s how my dream agent team handles it all while I maintain control:

1. Detected. The release declared a dependency on the API, so the change flags it and voids its earlier verification.
2. Held. Only the affected path pauses. Everything else keeps moving.
3. Routed. Neither the release owner nor the account owner can settle it alone, so it comes to me, as head of product, the one who owns both.
4. Framed. The agents bring three options, each with a real cost:
   • Slip the launch three weeks, and miss the partner announcement it’s timed to.
   • Break the commitment, and the customer’s integration fails on launch day.
   • Build a full adapter that keeps the old field alive. It takes two engineers off the fraud work promised for this quarter, someone has to own it until the customer migrates, and it’s only as compatible as the traffic it’s tested against.
5. Reframed. None of them is right, because the agents are missing a fact. From last week’s account call, I know the customer reads that field only in a monthly reconciliation export, not at checkout. I add that as context and narrow the question: keep the field in the export only. The agents come back with a fourth option, an export-only adapter at a fraction of the cost. It rests on my recollection, so I accept it on one condition: the account team confirms with the customer within two days, and the export path stays held until they do.
6. Propagated. Every affected team’s plan updates, and each acknowledges the change.
7. Re-verified. The required checks pass against the new contract and the export adapter, and the holds lift.
8. Remembered. It’s the third field-removal conflict this quarter, and the agents propose a standing policy. I approve a narrow one: export-only fields under a committed agreement get an adapter by default, capped at five engineer-days and expiring at the end of the quarter. Anything outside that scope still comes to me.

I didn’t discover the conflict by reading twenty conversations, or chase anyone afterward. I did three things the agents couldn’t: supplied a fact, reshaped the question, and accepted a tradeoff with my name on it.

The control plane

StarCraft players steer whole armies through a heads-up display (HUD): a minimap, resource counters, alerts, and control groups bound to number keys. Units handle their own micro, so the player spends attention only where it matters. The same layout fits an agent swarm, with one twist: the human’s micro isn’t moving units. It’s injecting context and revising intent.

Here’s the release conflict from my screen, at the moment the options don’t fit:

1. Look. A map of the work, not the workers. The top bar shows what needs me: three decisions due today, one release gate blocked. A stop is always one click away.
2. Investigate. Zooming in changes what you see, not just its size: organization, mission, deliverable, then an agent’s own workspace. Here, the evidence: a failed compatibility check, the contract clause it breaks, and unit tests that pass only because they encode the old API.
3. Decide, or reframe. One inbox for everything that needs a person, ranked by consequence and deadline, with each option’s cost. When none fits, I don’t pick the least bad one. I add the missing context and ask for new options.
4. Confirm. Missions acknowledge, checks rerun, and the hold clears on fresh evidence.

The same screen works forward, too. Ask three groups of agents to prototype competing migration strategies within a fixed budget, compare their evidence side by side, pick one, and redirect the rest.

Under the hood

Four mechanisms make that walkthrough possible:

• Missions, not agents. A mission is a goal with a plan, an owner, and evidence of completion. Agents come and go; the mission’s record persists. That’s what lets a change find the work it affects.
• Records you can trust. Agents propose dependency and commitment records as they work, and people confirm the consequential ones. An uncertain match becomes a question, not permission to proceed.
• Authority the system can read. Permissions, budgets, and commitments decide what proceeds, what pauses, and who resolves a conflict: the lowest person with authority over both sides.
• Attention as a budget. Every mission is a future claim on someone’s judgment. Ten missions stuck on one overloaded person can deliver less than six that aren’t.

Open problems

• Overlapping authority. If product and sales both own the customer, who decides? Escalating every tie to the CEO just moves the bottleneck.
• Summaries that hide uncertainty. “Verified” can be true and misleading: tests built from recorded traffic miss the endpoint nobody recorded. Summaries have to name their evidence.
• Decision overload. Fifty legitimate decisions in an incident are still fifty decisions. And the more policy absorbs, the less practice people get at what’s left (Bainbridge, 1983).
• Locally right, globally wrong. Every check can pass on a feature nobody wants.

How to test it

The test: several missions sharing contracts and decision-makers, run against today’s tools with the same agents and information. Measure how many concurrent missions people can direct before decision quality drops, and what it costs them in attention.

A different working day

A head of product opens a briefing, not a backlog: three decisions, ranked by deadline, each with its options and evidence. They’re done by mid-morning and spend the rest of the day with the customer at risk. An engineer catches up on twenty agents’ overnight work with three summaries and one diff, and knows which three.

I want to spend less time carrying messages between agents and more time deciding what’s worth doing. In this picture, I am the bottleneck. I’d rather learn to be a good one.