Agent decision tree
Walk every new AI use case down these questions in order. Stop at the first pattern that does the job. Every step up the list is a cost — take it only when the simpler option demonstrably fails.
Step 1 — The single-prompt test
- Can one well-written prompt handle this task with no tools and no loop? Yes → Use a single model call. You're done. No → Continue to step 2.
Step 2 — The fixed-sequence test
- Can you write the steps in advance — same order, every time — and have each step's output feed the next? Yes → Use prompt chaining. Predictable, testable, cheap. No → Continue to step 3.
Step 3 — The input-variety test
- Does the input vary enough that you must classify it first and send it down different paths? Yes → Use a router. A cheap, fast model classifies; fixed chains handle each path. Still not an agent. No → Continue to step 4.
Step 4 — The open-ended test
- Is the work genuinely open-ended — steps depend on what the model discovers, so you cannot write them in advance? Yes → You have a case for an agent (orchestrator-worker or full decide-act-observe loop). You also now have a case for the full operational apparatus: logging, guardrails, and human gates. No → Return to step 2 and re-examine.
Step 5 — The multi-agent test (take only if step 4 said yes)
- Does the task genuinely decompose into distinct subtasks with natural seams — where separating them makes each cleaner and more testable? Yes → Consider a supervisor/worker multi-agent setup. Centralize routing in one supervisor; workers do not volley tasks peer-to-peer. No → Stay with a single agent. Multi-agent adds coordination cost you do not need.
When to use each pattern
| Pattern | Best for | Watch out for |
|---|---|---|
| Single prompt | Simple extraction, drafting, classification where context fits in one call | Assuming more complexity exists than does |
| Prompt chaining | Fixed multi-step workflows — same order every run | Adding decision logic that belongs in a router |
| Router | High-volume, mixed-input work (support queues, supplier emails); cheap model sorts, heavier model only where needed | Under-sizing the "I don't know" bucket — it will be larger than your test set suggested |
| Single agent (orchestrator-worker) | Genuinely open-ended tasks where steps are unknown until the model starts working | Unpredictable paths, harder to debug; requires logging and HITL gates before go-live |
| Multi-agent (supervisor pattern) | Tasks with true natural seams: each subtask is independently testable and a single agent struggled | Infinite handoff loops if peers can route to each other; swarms are a research project, not a starting point |
The complexity-tax reminder
Every increment of agentic freedom you give the system is a cost, not a feature. The boring router that handles 80 percent of volume and routes the rest to a person is worth more than the autonomous system that quietly gets the strange 20 percent wrong.
Notes for this use case
| Field | Answer |
|---|---|
| Use case name | |
| Pattern selected | |
| Why this pattern (not simpler) | |
| Who reviews when it surprises us |
Want a second set of eyes on this in your firm? The no-sell promise applies — if it isn't a fit, I'll tell you in the first ten minutes.
Book a 30-Minute Call →