Burst pressure

In engineering, burst pressure is the point where a vessel stops holding and lets go. I think a lot of us are building towards ours.

Most teams I talk to go all in on orchestrator teams. Agents of agents. Three or four providers, because each one is better at something. A hundred-plus agents running and building the product.

And when you ask what one agent could have done on its own, there’s usually a pause. Because nobody ever checked.

The exciting bit comes first

I get it. The orchestrator demo is genuinely exciting. Watching a swarm of agents plan, build, review and hand off to each other feels like the future, and maybe it is.

But we jump in with the view of what’s exciting, not what’s proven. The architecture gets designed before anyone has shown that a single agent, with good context, can deliver the outcome. So the team skips straight to step five, and the proving never happens.

What a hundred agents actually cost you

More agents isn’t free, even when the tokens feel cheap:

• Coordination. Every hand-off between agents loses context. A hundred agents is a lot of hand-offs, and a lot of agents confidently working from a summary of a summary.
• Debugging. One non-deterministic worker is hard enough to debug. A hundred of them, talking to each other, is archaeology.
• Governance. Every agent needs permissions, guardrails and evals. Every provider needs its own keys, contracts and quirks. That’s your surface area, multiplied.
• Spend. Tokens per agent look small. Tokens per outcome, across the whole swarm, often don’t.
• Understanding. If nobody on the team can explain why the system did what it did, you don’t own it. It owns you.

None of that shows up in the demo. All of it shows up in month three.

Prove one, then earn the next

The fix is boring, which is probably why nobody does it: start with one, prove it, and make every step up the gauge earn its place.

↑ Where most teams start

1. 1
   A good promptStart here. Riff, research, and work out what you actually want.
2. 2
   One agent with context and toolsEarn it when you keep giving the same prompt the same context.
3. 3
   One agent with a workflowEarn it when the outcome is proven and you want it repeatable: plugins, skills, a Work Pack.
4. 4
   A small teamEarn it when you can name what one agent can’t do: a separate reviewer, real parallel work, or more context than one window holds.
5. 5
   An orchestrator and a fleetEarn it when your evals show the team beats one agent on a real outcome, by more than it costs to run.

The same goes for providers. Add another one when an eval shows it wins on a task you care about, not because it topped a leaderboard this week.

If you can’t prove one agent works, a hundred won’t prove it for you.

So, are we overthinking it?

Mostly, yes. Not because orchestration is wrong; some problems genuinely need it. But because we’re reaching for it before we’ve earned it, and every agent we add without proof is a bit more pressure in the vessel.

The teams I see getting real value aren’t the ones with the biggest swarm. They’re the ones who can tell you exactly why each agent exists, and what it does better than the one before it.

Start with one. Watch the gauge. Add pressure on purpose.