Give the same long task to one agent and to a crowd of them and the winner flips depending on a property of the task you can inspect before you build anything: whether the work comes apart into pieces that do not need each other's output. On a day-long instruction-following job made of loosely related requests, splitting the work scored 71.8 against a single agent's 53.6. On terminal work where each command depends on the last, every multi-agent method in the paper lost to the single agent, by up to 9 points. Same models, same budgets. Different shape of task.
Four long-horizon benchmarks, one base model throughout, five methods: a plain single agent and four ways of splitting the work. Two of the benchmarks are chains — a terminal session where each command consumes the last one's output, and a repository build where the modules have to agree. Two are bundles of loosely coupled requests: a deep research task and a day of assorted instructions.
Step through the benchmarks. Watch where the single agent sits in the ranking.
On the chained tasks the crowd is a liability: on the terminal benchmark the best multi-agent baseline scores 71.5 against the single agent's 76.7, and the worst drops to 67.5. On the loosely coupled ones the order inverts and the gap is larger in the other direction — 71.8 against 53.6 on the day-of-instructions benchmark. No method is good here. A method is good for a shape of task.
The paper's formal object is a bridge edge: draw the task as a graph of steps, and an edge is a bridge if deleting it leaves you with more disconnected pieces than you started with. That is the only honest place to cut. Delegation across a bridge hands the sub-agent a self-contained subproblem plus a bounded summary; delegation anywhere else hands it half a conversation and asks it to guess the rest.
Drag the coupling. The chain below is a twelve-step task; the slider sets how often a step consumes the previous step's output rather than starting fresh.
This is the part worth internalising: the decision is about the dependency structure of the work, not about how big the work is. A very long task with a dependency at every step has no seam and nothing to gain from a second agent. A short task made of three unrelated lookups has two.
Most multi-agent frameworks decide their topology up front: a planner writes a plan, the plan becomes a fixed set of workers, and everyone is handed context at the moment of decomposition. SAIGE does neither. It runs as one agent until it detects a boundary that satisfies the bridge-edge property, spawns a child only there, and lets branches pull each other's results by content-based retrieval when they actually need them instead of broadcasting context at the split.
Step through the four rules.
The payoff shows up twice: in the score, where it is the only method that never loses badly on the chained benchmarks, and in the bill. Toggle between them.
Note what is not claimed. On the terminal benchmark this method still trails the single agent, 75.5 to 76.7, and spends slightly more to do it — 501M input tokens against 475M. Spawning at a seam does not make decomposition free on a task that has no seam. It makes it cheap enough to be wrong about.
The obvious next move after a multi-agent system works is to give it more agents. The paper ran it: raising the pool from four to six, and letting sub-agents spawn their own sub-agents to depth two and three. Both hurt, on both of the benchmarks where decomposition was helping in the first place, while input tokens went up sharply.
Drag the pool and the depth.
Six agents instead of four cost 7.8 points on the day-of-instructions benchmark and more than doubled input tokens on the research one, from 2,745M to 6,312M. Depth is worse: every extra level of sub-agents spawning sub-agents lost points on both benchmarks, ending 8.6 points down at depth three. The configuration that won is the smallest one tested.
Take a job your product already runs as one long agent loop — a migration, a research brief, a batch of tickets. Before adding a sub-agent, write down its steps and ask, for each one, whether it needs the output of the step before it. The answer decides the architecture, and you can get it from a transcript you already have.
The cheap version of this experiment does not need a framework. Run the job once as a single agent, log which steps read which earlier outputs, and count the cuts that would leave two pieces standing on their own. If the count is zero, the orchestrator you were about to write is a cost with no upside.