Choosing the Right Agentic Design Pattern

You know how to build an agent (Building-an-AI-Agent-from-Scratch); this note is about deciding what shape of agent a task actually needs — before writing code, when the decision is cheap to change. The individual patterns (ReAct, planning, reflection, multi-agent) are well documented everywhere; what’s rarely documented is the selection logic between them. This note teaches that logic as a five-question decision tree, following Bala Priya C’s article (archived as Choosing the Right Agentic Design Pattern A Decision-Tree Approach).

Read LLM Tool Calling and Building-an-AI-Agent-from-Scratch first — ReAct, the base pattern here, is the loop those notes build. This note pairs with LangGraph vs CrewAI Research: choose the pattern here first, then the framework there. Doing it in the other order is how you end up with orchestration you don’t need.

Related: LangGraph vs CrewAI Research, Frameworks, runtimes, and harnesses, The-AI-Agents-Stack-Summary, Deep-Agents.

1. Why pattern selection is the real design decision

Most agent-architecture mistakes are a misread of the problem, in one of two directions. The famous one is over-engineering: a multi-agent system looked impressive in a conference talk, so a team spends weeks on orchestration for something one well-prompted agent with two tools handles in a day — the agent-world version of standing up Kubernetes to run a cron job. The quieter one is under-engineering: the simple thing ships, then can’t adapt or scale, and gets redesigned under production pressure.

The root cause of both is the same: every pattern encodes assumptions about the task, and value appears only when the assumptions hold. When they don’t, the pattern is pure overhead:

PatternIts core assumptionWhen the assumption fails
ReAct (reason → act → observe, in a loop)The next best step is not knowable in advance — it depends on what the last step revealedOn fully predictable workflows, per-step reasoning is cost and nondeterminism for nothing
Planning (roadmap upfront, then execute)The task’s major structure can be identified before startingWhen structure only emerges during execution, the plan misleads and gets abandoned
Reflection (generate → critique → refine)First-pass output is often flawed, and there are criteria to check it againstWithout clear criteria the critic hand-waves; when speed matters the extra pass is pure latency
Multi-agent (specialized roles, coordinated)Decomposition into roles is worth the coordination overheadFor tasks one agent can hold, you’ve added IPC, shared state, and failure points for nothing

The decision tree below just asks, in order, which assumptions your task actually satisfies.

2. The five questions

Q1 — Is the solution path known in advance?

The first cut separates fixed workflows from adaptive ones. A known path means the full step sequence can be written down before execution: invoice processing (extract → validate → store → confirm), employee onboarding (create accounts → send email → assign manager). Same steps, every time. An unknown path means each step depends on the previous step’s output: research that follows evidence, debugging that shifts hypotheses, support conversations that branch on what the user says. The test is the difference between a script and an interactive session — could you write the whole thing as a pipeline, or is it inherently a gdb session where the next command depends on what the last one printed?

Known path → Q2a. Unknown → Q2b.

Q2a — Known path: use a sequential workflow, and resist upgrading it

For stable, predictable paths, the right pattern is the least glamorous one: a sequential workflow — explicit stages, output of one feeding the next, exactly a shell pipeline. The design skill is deciding where the model belongs at all: use the LLM only for the steps that need interpretation or generation (reading a free-text invoice), and plain deterministic code for everything else (validation, storage, notification). Fast, predictable, cheap.

The failure mode is over-engineering: adding ReAct-style “should I…?” reasoning to steps that are already defined. If the process is deterministic, the agent should execute, not decide — a cron job does not need a planner. The legitimate exit is when edge cases keep breaking the fixed steps; that’s the task telling you its path wasn’t as known as you thought, and you re-enter the tree at Q2b.

Q2b — Unknown path: does the task need tools?

Almost always yes — an agent limited to its training data and the conversation handles only a narrow slice of real tasks; anything touching current information, external state, or side effects needs tools (LLM Tool Calling covers why). The point that matters for pattern selection is that tools don’t change the pattern: they sit under the reasoning layer, not beside it. A ReAct agent with tools is still ReAct; a planning agent with tools is still planning. Proceed with tools assumed.

Q3 — Can the task’s structure be articulated before execution?

The question that separates planning from ReAct — and the one most often skipped, with developers defaulting to ReAct. A task is structurally articulable when its major stages and their dependencies are clear upfront even though details aren’t: build a feature (design → implement → test), produce a report (gather → synthesize → write), provision systems in dependency order. That’s a task you could write a Makefile for — targets and prerequisites declared before the first command runs, even if each recipe’s internals are adaptive. (Task graphs of this kind are DAGs; see Understanding Directed Acyclic Graphs (DAGs).)

When that structure exists, planning wins because it surfaces dependencies early — without a plan, the agent discovers the missed prerequisite only after spending compute going down the wrong path. When structure genuinely emerges only through interaction, a plan is worse than no plan: it’s confidently wrong, and the agent either follows it into a wall or abandons it (see the failure table below).

Structure articulable → planning for the stages, ReAct inside each step. Structure emergent → plain ReAct, continue to Q4.

Q4 — Does output quality matter more than speed?

If yes, add reflection: a generate → critique → refine cycle, the pattern equivalent of not shipping a patch without review. It pays off only when two conditions hold: there are explicit criteria to critique against (the SQL must run, the contract must contain the required clauses), and the cost of an error justifies the extra pass (deployed code, client-facing documents). Without criteria the critic produces vague agreement; under latency pressure the extra round-trips are a real cost.

The detail that decides whether reflection works at all is critic independence. A critic that mirrors the generator agrees instead of evaluating — the same reason the patch author doesn’t review their own patch. Give the critic a different framing, different instructions, or a different model entirely.

Quality-critical with clear criteria → add reflection. Speed-critical or criteria fuzzy → skip it.

Q5 — Is there a specialization or scale problem one agent can’t handle?

Only now, with everything else settled, does multi-agent enter. The two legitimate triggers: specialization — parts of the task need genuinely different reasoning styles (legal review vs financial modeling, coding vs security audit), each wanting its own prompt, tools, and context; and scale — the work exceeds one context window or is being needlessly serialized when it could run in parallel. This is the fork/exec trade-off from Building-an-AI-Agent-from-Scratch’s delegation seed, at architecture scale: multiple processes buy you parallelism and isolation, and charge you coordination, shared state, and a combinatorial debugging surface. Two agents passing context are already hard to debug; five without per-handoff traces are impossible (The-AI-Agents-Stack-Summary layer 5).

The rule: multi-agent on a demonstrated bottleneck that specialization or scale actually solves — never as an architectural preference. If neither trigger applies, one strong agent wins. When it does apply, the design decisions are task ownership, routing logic, and topology (sequential, parallel, or debate).

3. Where the tree lands: four starting points

Destination patternWhenWhy it works
Single agent + tools + ReActUnknown path, emergent structure, no strict quality bar, no specialization needThe best default for real-world tasks — flexible, cheap to fail and retry
Planning + ReAct executionStructure knowable upfront, steps adaptive insidePlan exposes dependencies early; ReAct absorbs local uncertainty
Single agent + reflectionQuality critical, latency acceptable, criteria explicitThe critique loop converts checkable criteria into correctness
Multi-agent specialistsReal specialization or scale bottleneckParallelism and per-role context, bought with coordination overhead

These are starting points, not final states — production agents drift between them as feedback accumulates, and the tree’s real product is that your choice has stated reasons you can revisit when conditions change.

4. Failure signals: how the wrong pattern announces itself

SignalWhat it meansFix
ReAct loops excessively, revisits settled questionsThe task had structure you didn’t articulate, or no stopping conditionAdd lightweight planning, sharpen tool design, cap turns (the watchdog from Building-an-AI-Agent-from-Scratch §2)
Planning agent keeps abandoning its planThe task is less structured than assumedDrop to lightweight planning + ReAct; stop re-planning
Reflection cycles don’t improve outputCriteria unclear, or critic mirrors generatorMake criteria checkable; make the critic independent
Multi-agent misroutes or outputs don’t composeRouting logic is the weak linkUse deterministic rules for predictable routing instead of LLM routing — static routes beat a routing protocol when the topology is simple

5. How this fits the sequence

This tree is the pattern decision. Three adjacent decisions have their own notes: which framework implements the chosen pattern (LangGraph vs CrewAI Research — and its finding that framework choice moves results far less than pattern choice), which tier of machinery you adopt at all (Frameworks, runtimes, and harnesses), and which stack layers the resulting system needs (The-AI-Agents-Stack-Summary §3, whose four agent types line up almost one-to-one with the four destinations above). For high-stakes actions, add human-in-the-loop checkpoints regardless of pattern — that’s a guardrails-layer decision, orthogonal to the reasoning pattern.

References