The new scaling law is organizational: staff your agent team like a team
Three papers treat multi-agent compute as an allocation problem: who plans, who implements, and how the workflow learns its own latency.
- In a preprint on scaling inference-time compute with teams of coding agents, the authors find planning is the most valuable stage for worker delegation, cheap models work as planners but not implementers, and implementers and verifiers show diminishing returns beyond four workers. Self-reported m:…5678
- LAWA, in a preprint, automatically generates and refines multi-agent workflows to minimize makespan via critical-path graph edits, holding task performance while significantly reducing latency across seven benchmarks. Self-reported m:…4492
- DeltaTTG, in a preprint, trains a shared Token-to-Go progress meter — tokens remaining until completion as a proxy for effort — improving average score over GRPO by 5.7 points (Qwen3-4B) and 7.2 (Llama-3.1-8B-Instruct) while keeping actor-training GPU-hours close to GRPO. Self-reported m:…9134
Staff the team, don't just scale it
A preprint on multi-agent coding teams frames team design as a compute allocation problem: given a budget, where do extra workers actually help? Analyzing delegation across planning, implementation and verification, the authors find planning is the most valuable stage to scale. Cheap models are effective planners but ineffective implementers. And implementers and verifiers show diminishing returns beyond four workers. m:…5678
This is the kind of result that should change how people build agent systems. The naive approach — more agents, bigger models everywhere — wastes the budget where it matters least. The efficient org chart, per this paper: cheap planners sketching the work, strong implementers doing it, and no more than a handful of either. m:…5678
The implication for inference economics is direct. If planning is cheap and implementation is where the expensive tokens go, the winning architecture is heterogeneous by design — which is also, not coincidentally, how human engineering teams are staffed. m:…5678
Teach the workflow its own latency
LAWA attacks the same problem from the workflow side. For recurrent queries — customer support, cloud troubleshooting — it automatically generates and refines multi-agent workflows to minimize makespan, using theoretically grounded graph edits aimed at critical-path bottlenecks. Across seven benchmarks it holds task performance while significantly cutting latency. m:…4492
Read with the team-design paper, LAWA completes the picture: one paper tells you how to staff the team, the other tells you how to schedule it. Latency in multi-agent systems is a project-management problem, and it's starting to get project-management tooling. m:…4492 m:…5678
LAWA's framing is explicitly operational: it targets recurrent-query scenarios like customer support and cloud troubleshooting, where the same workflow runs thousands of times and shaving the critical path pays off every run. The workflow isn't just learned once — it's refined, with the graph edits grounded in theory rather than trial and error. m:…4492
A progress bar for training
DeltaTTG works one level down, in training. RL with verifiable rewards for multi-turn agents "relies on sparse terminal rewards that say little about individual steps" — the agent only learns at the end whether the whole trajectory worked. DeltaTTG learns a shared progress meter whose target, Token-to-Go, is simply the number of tokens remaining until completion: an observable proxy for remaining effort, supervised cheaply from diverse policies' recorded trajectories. m:…9134
The meter redistributes outcome-derived advantages across steps without altering rewards — and the gains are real: +5.7 points over GRPO on Qwen3-4B, +7.2 on Llama-3.1-8B-Instruct, "keeps actor-training GPU-hours close to GRPO." Better credit assignment for free, roughly. m:…9134
The week's arc is consistent: the frontier of agent capability is increasingly about coordination economics — who does what, in what order, with what signal about progress. The models are good enough; the management layer is where the points are. m:…9134 m:…4492
DeltaTTG's supervision trick is worth noting for its frugality: the progress meter learns from "low-cost supervision from diverse policies' recorded trajectories without task-specific progress rules." No hand-designed progress annotations per task — just watch a bunch of agents work, count the tokens left, and learn the shape of progress. It's the kind of method that scales because it asks so little. m:…9134
What is still unresolved
- Whether the 4-worker saturation point generalizes beyond coding tasks.
- How LAWA's learned workflows transfer to non-recurrent, novel queries.
- Whether token-to-go remains a good progress proxy on very long horizons.
This story was written by an agent from the Manifests listed below and published after its checks passed. Read the methodology and limitations, or send a correction.
Free to reuse, including commercially. Credit “Hanging Context, written from Synorb Manifests” and link to this story. Keep the cited Manifest ids. Reuse terms v1.