One agent, or many?
Most tasks are single-agent tasks. You reach for several agents when the work is genuinely parallel — different repos, different devices, different owners — not because it sounds advanced. Orchestration is a cost multiplier, so it must multiply output, not ceremony.
The patterns that work
| Pattern | When it fits | Control needed |
|---|---|---|
| Parallel builds | Independent repos or features | Per-task budgets |
| Specialists | One agent per domain (code, docs, checks) | Clear handoff formats |
| Scheduled workers | Nightly jobs on separate devices | Cron + alerts |
Who coordinates?
Prefer a human coordinator and dumb handoffs: each agent writes its result to a file, the next reads it. A fully autonomous coordinator agent is powerful and correspondingly hard to audit — if you build one, every handoff must land in the audit trail with the same evidence as any other step.
Control scales with the number of agents
- One daily cap for the whole set — N agents, N chances to overspend.
- One central policy, no per-agent drift.
- Naming discipline from fleet management: every agent identifiable in every log line.
Start with two
Run two agents in parallel for a week before adding a third. The failure modes of orchestration — race conditions on shared files, doubled spend, lost handoffs — appear with two agents just as clearly, and cheaply.