"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."
Q3
How do you decide between ReAct, Planner-Executor, and Multi-Agent?
ReActPlanningMulti-AgentArchitecture
Commonly asked at OpenAI · Microsoft · Sierra
How to answer — what you would actually say
The deep dive — diagrams, tradeoff tables, and the follow-up trap
The three shapes, side by side
Three control-flow shapes — pick the one the task already has
Choose on the failure you can live with
| Pattern | Use when | Trade-off |
|---|---|---|
| ReAct | The path is discovered as you go — diagnosis, research, triage | Unbounded steps; latency and cost you cannot quote in advance. Fails: wanders, re-calls tools, 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. Fails: a wrong plan is executed faithfully |
| Multi-Agent | Genuinely separate expertise whose contexts should not mix | N× the tokens, plus handoffs and cross-agent tracing. Fails: facts lost in handoffs; no one arbitrates a disagreement |
Why the plan artifact is the whole point
It wins compliance reviews: the plan is inspectable before anything runs — a diff to approve, not a trace to read later:
{
"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, not remembered. ReAct cannot write this: step 3 does not exist until step 2 returns.
REAL SYSTEM
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.
FOLLOW-UP TRAP
“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.