AI Agents & Automation 
The first time you wire up a multi-agent setup, everything looks like a nail. You have Opus over here, Sonnet and Haiku over there, a bash dispatcher that will happily fan out five workers in parallel, and a per-worker budget cap so nothing runs away. It feels expensive not to use it. Every incoming request becomes a candidate for parallel execution.
That’s the mistake I made for about three weeks. The bill wasn’t the tell — my orchestrator was still cheap. The tell was that responses got slower and worse. A question I could’ve answered in one sentence started coming back as a synthesized summary of three worker outputs that all said roughly the same thing in different registers.
The interesting engineering problem in a multi-agent system isn’t the fan-out. It’s the rule that decides when to sit still.
The rule I actually use
My PA orchestrator has a paragraph in its standing instructions that reads like a bouncer’s list. Dispatch a worker if any of these is true:
- The subtask is bounded and stateless — one Calendar lookup, one Todoist write, one vault search.
- It can run in parallel with other subtasks.
- It doesn’t need conversational context with me.
- It would consume a lot of vault context that shouldn’t pollute the orchestrator’s session.
Handle it inline if:
- The task is conversational — “how should I think about X?”, “what do you remember about Y?”
- It needs the orchestrator’s full session memory.
- It’s trivial enough that the cost of spawning a worker exceeds the cost of doing it yourself.
That last inline bullet is the one that took me the longest to internalize. Spawning a worker isn’t free. There’s a cold start, a fresh context window, a re-load of the relevant skill files, and then the orchestrator has to read the worker’s output and re-synthesize it. For anything under a few hundred tokens of actual work, you’re paying overhead to do less thinking.
Fan out when the work is bounded, parallelizable, and boring. Sit still when it’s conversational, contextual, or small.
— The rule that saved me from turning a chat into a jobs queue
What the workers actually are
To make the rule concrete, here’s the worker table my orchestrator dispatches against. Model tier is chosen per task shape, not per importance:
| Feature | Worker | Model | When it gets dispatched |
|---|---|---|---|
| vault-search | Haiku | Keyword or grep retrieval across the vault | |
| calendar | Haiku | Google Calendar reads — 'what's on Tuesday' | |
| task | Sonnet | Todoist add / update / find / complete | |
| Sonnet | Gmail search + draft replies | ||
| briefing | Sonnet | Aggregated calendar+email+tasks briefing | |
| idea-triage | Sonnet | Brain dump → Ideas / Projects / Tasks classification | |
| blog-draft | Sonnet | Long-form blog drafting | |
| cold-drop | Sonnet | Hand-drop pitch PDFs for target companies |
Haiku for the shallow-and-fast stuff. Sonnet for the “actually needs to think but is still bounded” stuff. Opus never runs as a worker — it’s the orchestrator, and its job is routing and synthesis. If Opus ever ends up doing the actual work itself, either I picked the wrong shape or the task was small enough that inline was correct.
The call signature is deliberately dumb:
Type, prompt, optional parallelism. Workers return text on stdout. No SDK, no framework, no message bus. When the orchestrator wants three email variants, it appends --parallel 3 and reads the concatenated stdout. When Anthropic ships a new model, I change one line in the dispatcher.
Where the temptation to over-dispatch lives
Two patterns kept tricking me into fanning out when I shouldn’t have.
The multi-step task that looks parallel but isn’t. “Find the vault note about a client account, then draft a Slack update based on it, then queue a follow-up task in Todoist” looks like three workers. It’s actually one dependency chain. Worker B needs A’s output. Worker C needs B’s. If I fan them out anyway, either I serialize them by hand (in which case why is there a dispatcher) or I let them race and get garbage. The rule is: fan out only when the subtasks are actually independent.
The conversational question that has some retrieval in it. “What do you remember about that half-baked side-project idea?” tempts you to spawn a vault-search for context and then reason over the result. But the whole question is a conversation. The orchestrator already has session memory. Spawning a worker here throws away the exact thing that makes the answer good — my context with the person asking.
The budget cap is a shape constraint, not a spending limit
Every worker runs under a hard $0.50 cap enforced by the dispatcher’s --max-budget-usd flag. I’ve never actually hit it — most workers cost fractions of a cent. The cap isn’t there to save money. It’s there to make sure I notice if a worker’s shape is wrong.
If a vault-search worker is spending real money, the query is probably too broad and should have been handled inline as a conversation. If an email worker is approaching the cap, the prompt was too vague and I’m burning tokens on the model wandering. The bill is a shape signal.
That reframing changed how I write dispatcher calls. I started shipping tighter prompts with a clear success criterion, because a worker that returns quickly and cheaply is a worker with the right shape. A worker that costs a nickel is telling me the task belonged somewhere else.
The takeaway
The multi-agent literature is mostly about how to fan out. The under-discussed half of the problem is when not to. If you’re building your own orchestrator, spend the first day writing the “handle inline” list, not the “dispatch” list. The dispatch list is easy — every SDK on the market will help you write it. The inline list is where the good answers actually live.
Fan out for the boring, bounded, parallel work. Sit still for the conversation. And when your bill for a single request creeps up without the answer getting better, that’s the orchestrator telling you it fanned out something that should’ve stayed home.