One inbox for every model: how to actually run a fleet of agents
Spawning ten agents is easy. Reviewing ten agents is the hard part. One inbox — spawn, review, merge — is how agent orchestration stops being chaos.
Spawning AI agents is the easy part. Anyone can fire off ten of them. The hard part — the part that actually decides whether agents make you faster or just busier — is what happens next.
Ten agents finish. Now you have ten branches, in ten contexts, from however many models, scattered across however many projects. Which ones are good? Which conflict? Which quietly broke the build? If the answer is “I tab through ten terminals and ten browser windows to find out,” you haven’t orchestrated anything. You’ve just made a mess in parallel.
The fix is a single idea: one inbox for every model.
The problem isn’t spawning. It’s reviewing.
Most “multi-agent” tooling optimizes the wrong half of the loop. It makes it trivial to launch work and leaves judging work as your problem. So the bottleneck just moves: instead of waiting on one agent, you’re now the human merge-conflict resolver for a swarm, context-switching between providers, projects, and panes until the speedup evaporates.
An agent fleet only pays off if reviewing N agents is barely harder than reviewing one. That requires the outputs to land in one place, in a consistent shape, regardless of which model or project they came from.
What “one inbox” means in practice
A real agent inbox does four things:
- Spawn. One prompt fans out into N agents, each in its own isolated git worktree. Different models, different providers, different projects — it doesn’t matter. They run in parallel without stepping on each other.
- Collect. Every agent’s result lands in the same inbox, in the same diff-and-comment shape. You are not hunting across editors and tabs. You’re reading a queue.
- Review. You diff, you comment, you compare. Two agents took the same task two ways? They’re side by side. One model nailed it, another wandered? Obvious at a glance.
- Merge. You ratify. The work you approve merges; the work you don’t, doesn’t. The human stays in the driver’s seat — by design, not by accident.
Spawn, review, merge. That’s the whole loop, and the inbox is what makes it survive scale.
Why “every model” is the unlock
Single-model agent tools quietly cap your ceiling. The best model for a refactor isn’t always the best model for a test suite, a migration, or a gnarly debug. If your orchestration is welded to one provider, you’re leaving capability on the table — and you’re exposed the day that provider has a bad week.
“One inbox for every model” means you can:
- Race two models on the same task and keep the better diff.
- Route cheap, mechanical work to a cheap model and hard reasoning to a strong one — and see both in the same queue.
- Swap providers without rebuilding your workflow, because the inbox is the constant, not the model.
Model choice becomes a per-task decision instead of a platform lock-in.
The part people forget: isolation
Parallel agents that share a working tree will corrupt each other’s changes — guaranteed. That’s why Tandem gives every agent its own git worktree. Ten agents, ten isolated checkouts, zero stomping. They can run flat-out in parallel precisely because they can’t see each other’s half-finished work. The inbox is where their finished work finally meets — under your review.
How Tandem does it
Tandem is built around exactly this loop. You describe the work in plain English; Tandem plans it and you approve; agents execute in isolated worktrees across every project; and you review and merge them all from one inbox — for every model, every provider, on hardware you control. Local-first, zero telemetry, your code never leaving your box.
The agents do the typing. You do the deciding. One inbox is what keeps that division of labor from collapsing into chaos.
See how the one-inbox model stacks up against single-agent and single-workspace approaches.