Choosing a pattern (and composing them)

ReAct

Latency: strictly serial — one model call plus one tool round-trip per step; nothing parallelizes. Fine at 3 steps, painful at 30.

Token cost: grows superlinearly with steps, because every call re-sends the whole accumulated history. Short tasks are cheap; long ones quietly aren’t.

Debuggability: the trace is the reasoning — a readable thought/action/observation log. But you can only debug what already happened: there is no artifact to inspect before the agent acts.

Failure modes: wandering (goal drift over many steps), loops that repeat a failing action, and run-to-run variance — with no plan, two runs of the same task can take entirely different routes. Mitigations live in the runtime: step budgets, stopping conditions, loop detection.

Plan-then-execute

Latency: planning adds an upfront call, but independent steps fan out in parallel — usually the fastest pattern on long, decomposable tasks.

Token cost: most predictable of the three. Step count is known before execution; executors carry per-step context instead of a growing transcript; the planner can be the only expensive model in the system.

Debuggability: best-in-class — the plan is a reviewable artifact before side effects, and failures localize (“step 4 failed”) instead of dissolving into a 40-step transcript.

Failure modes: ossification — executing a plan whose assumptions died at step 2; replan storms (replanning every step — ReAct with extra ceremony); and planning-horizon errors, where the planner invents steps for a world it hasn’t observed yet.

Reflection

Latency: additive — each critique-revise cycle bolts one or two model calls onto whatever pattern generated the draft. Two rounds of reflection ≈ 2–3x baseline latency.

Token cost: roughly doubles per round (the critique re-reads the draft, the revision rewrites it). Cost without a verifier is the classic silent budget leak.

Debuggability: middling — critiques document what the model thought was wrong, which is useful, but a bad critique that triggered a bad revision is two model outputs to untangle instead of one.

Failure modes: rubber-stamp critiques (“looks good!”), self-lobotomy (revising a correct answer into a wrong one — measured by Huang et al.), and correlated judge blind spots when the critic shares the generator’s weights or training distribution.

Pick a pattern for the task in front of you

Interactive decision tree — outcomes:

• Plan-then-execute with an approval gate

  The plan is the one artifact that lets review happen before side effects. Put the gate between planner and executor, wire replan triggers, and route replans back through the gate.

• Plan-then-execute

  Enumerable steps plus a long horizon is this pattern’s home turf: bounded cost, parallel fan-out, per-step failure localization. Budget for replanning — plans meet reality eventually.

• Plain ReAct

  For short, observation-driven tasks a plan is ceremony and a critic is overhead. Spend the effort on good tools, tight step budgets, and stopping conditions instead.

• ReAct + reflection against the verifier

  Observation-driven work with an external check is the Reflexion setting: loop, verify, reflect on failures, retry. The verifier is what makes the reflection real — keep it in the loop, not in the prompt.

• Add an independent critic — and an eval before you trust it

  A second-model judge can catch some errors, but the evidence here is genuinely mixed: judges share blind spots and add real cost. Ship it behind an eval that proves it helps on your task, or the critic is theater.