How to Answer
"Decision tree: ReAct when the task is exploratory and the path isn't known upfront (research, diagnosis). Planner-Executor when the task has clear phases and I want auditability — the plan is a human-readable artifact I can approve before execution. Great for compliance-heavy workflows. Multi-Agent only when there are genuinely separable domains of expertise — e.g., a researcher who searches the web and an analyst who runs SQL shouldn't share a context window. Multi-agent is a tool, not a default — it adds coordination overhead and debugging complexity."
The three shapes, side by side
The pattern is not a taste question — it follows from whether the path is known upfront and whether anyone must approve it.
Choose on the failure you can live with
| Pattern | Reach for it when | What it costs | How it fails |
|---|---|---|---|
| ReAct | The path is discovered as you go — diagnosis, research, triage | Unbounded steps; latency and cost you cannot quote in advance | Wanders: re-calls tools, never converges, stops at the iteration cap |
| Planner-Executor | Phases are known and a human must sign off before anything runs | One extra planning call, plus human wait time in the middle | A wrong plan is executed faithfully — the executor never questions it |
| Multi-Agent | Genuinely separate expertise whose contexts should not mix | N× the tokens, plus handoff serialization and cross-agent tracing | Facts get lost in handoffs; the orchestrator cannot arbitrate a disagreement |
Why the plan artifact is the whole point
Planner-Executor wins compliance reviews because the plan is inspectable before anything happens — a diff a human can approve, not a trace they read afterwards:
{
"task": "close out the Q3 vendor invoice dispute",
"plan": [
{ "step": 1, "tool": "fetch_invoices", "args": { "vendor_id": "V-8841" },
"reads": ["billing.invoices"], "writes": [] },
{ "step": 2, "tool": "diff_against_contract", "args": { "contract_id": "C-119" },
"reads": ["legal.contracts"], "writes": [] },
{ "step": 3, "tool": "open_credit_memo", "args": { "amount_cap_usd": 5000 },
"writes": ["billing.credit_memos"], "requires_approval": true }
],
"approval": { "because": "step 3 moves money", "approver_role": "ap_manager" }
}Every step declares what it reads and writes, so the approval gate is derived rather than remembered. ReAct cannot produce this document: step 3 does not exist until step 2 returns.
An incident-triage system started as three agents — logs, metrics, deploy history — behind an orchestrator. Median resolution burned ~31K tokens and ~48s, and 1 run in 5 lost a fact across a handoff: the log agent found the bad deploy, the orchestrator’s summary dropped the timestamp. One ReAct agent holding all three tools took it to ~12K tokens and ~19s, with lost-context failures near zero. Multi-agent came back for one case: the customer-data agent, which had to run under a different service account.
“More specialists must be better — why not five agents?” — Because every handoff is a lossy summary. One agent passes full observations from step N to step N+1; a handoff passes only what the orchestrator wrote down. Split when contexts must not mix — different credentials, different data residency — not because the org chart has specialists.