ReAct vs Function Calling vs Plan-and-Execute: The Architecture Decision Map

The 2023 ReAct paper Yao et al. (2023) introduced Thought → Action → Observation as a prompting pattern. Late 2023, OpenAI shipped function calling — models emit structured JSON calls instead of free-text actions. 2024 brought plan-and-execute (Pre-Act, ADaPT, HIPLAN) — explicit planning artifacts before execution.

By 2025, the field split into three paradigms. Most teams pick one by default. The right choice depends on what you are optimizing for.

The Core Difference

Aspect ReAct (Thought/Action/Obs) Function Calling (Structured) Plan-and-Execute (DAG/Plan)
Reasoning visibility Explicit — every step prints “Thought: …” Implicit — reasoning inside model, only action emitted Explicit plan artifact (DAG), then execution
Action format Free text (parsed by regex/template) JSON schema (validated by host) Plan = data structure (DAG, AND/OR tree)
Token overhead High — reasoning tokens every turn Low — only action + result Medium — plan tokens upfront, then execution
Debuggability High — read the trace Low — no trace unless engineered High — plan inspectable before execution
Schema compliance Fragile — model may malformat Strong — fine-tuned for JSON Plan validates; execution uses function calling
Flexibility High — can invent new action patterns Constrained — must match registered schemas High — plan can compose arbitrarily
Recovery Retry/backtrack in conversation Retry same call Surgical: rollback failed subgraph only
Best for Complex, multi-hop, unpredictable Predictable, single-step, high-volume Long-horizon, dependent tools, auditability

What the Research Shows

Xu et al. (2026) survey the evolution: single-call → multi-tool orchestration. Key findings:

  • ReAct variants (Pre-Act, ADaPT, Beyond ReAct) dominate cognitive architecture research — DAG planners, recursive decomposition, think-simulate-act — because explicit reasoning enables planning as data structure.
  • Function calling dominates production deployment — LLMCompiler (parallel calls), ToolLLM/AnyTool (hierarchical retrieval), MCP-Zero (active discovery) — because structured actions integrate with software pipelines.
  • Plan-and-execute (GAP, ToolNet, HIPLAN, ADaPT, ARTIS, Smurfs) wins on cost reduction (AutoTool: 30%) and recovery (Smurfs: stable rollback + local context filtering).

Hybrid is winning: Plan-and-execute using function calling with ReAct-style reasoning traces → model emits {reasoning: "...", tool_call: {...}}. Best of all three.

Decision Framework: Which to Use?

Use ReAct (or hybrid) when:

  • Task requires multi-hop reasoning (research, troubleshooting, multi-step planning)
  • You need auditability (compliance, debugging, user trust)
  • The action space is open-ended (model may need to compose tools creatively)
  • You are developing/iterating on the agent — visible traces accelerate learning
  • Failure cost is high — you want to see why before it acts

Use Function Calling when:

  • Task is well-structured (lookup, calculate, CRUD, API call)
  • Latency/token budget is tight (high volume, edge deployment)
  • You have many tools (20+) — schema routing beats free-text parsing
  • Integration with code pipelines matters (CI/CD, data pipelines)
  • You have fine-tuned models for function calling (Llama-3.1, GPT-4o, Claude 3.5)

Use Plan-and-Execute when:

  • Long-horizon tasks with cross-tool dependencies (build → test → deploy)
  • You need concurrency (independent branches run in parallel)
  • Recovery matters — surgical rollback of failed subgraph
  • Auditability of plan before execution (compliance, human review)
  • Cost model includes λ·Cost(τ) — plan optimizes token budget upfront
Plan-and-execute architecture
    → Function calling for execution (structured, validated)
    → Reasoning field in every action (visible trace)
    → DAG planner with checkpoint/resume

The Hidden Cost: Reasoning Tokens

ReAct agents spend 2–5× more tokens per turn on reasoning. At scale, this is real money. Xu et al. (2026) note the objective: max E[R_task - λ·Cost(τ)]. λ is your token cost.

Paradigm Tokens/Turn (est.) Best λ Regime
ReAct 2,000–5,000 Low λ (complex tasks, low volume)
Function Calling 500–1,500 High λ (high volume, edge)
Plan-and-Execute 1,500–3,000 (plan) + 500/turn (exec) Medium λ (long-horizon)

Practical rule: Measure utility per 1k tokens. If ReAct’s higher accuracy doesn’t offset its token cost, switch to function calling + hybrid reasoning field.

Debugging the Black Box

Function-calling agents fail silently: wrong tool, wrong args, no explanation. Mitigations:

  1. Force reasoning field in prompt/template — even if model doesn’t use it natively
  2. Log every call with input/output + model’s internal confidence (if available)
  3. Replay failed traces with a ReAct prompt — “here is what happened; why did you choose X?”
  4. Eval on snapshots Sun et al. (2025) — freeze context, compare action faithfulness

The Evolution: From Paradigm to Architecture

Xu et al. (2026) show the field moving beyond this binary:

Stage Paradigm Key Innovation
1 Single call One tool, one answer
2 ReAct Thought → Action → Observation loop
3 Function calling Structured JSON actions
4 Planning-as-graph DAGs, concurrent execution, rollback (GAP, ToolNet, ADaPT)
5 Dual-system Sys1 (fast) + Sys2 (slow) (MARS, SwiftSage, CodeTool)
6 Self-improving Reflexion, SPIRAL, MetaAgent, test-time tool evolution

ReAct vs function calling vs plan-and-execute is stage 2 vs 3 vs 4. The production frontier is stage 4–6 — and those require structured actions (function calling) plus explicit planning artifacts (plan-and-execute) plus visible reasoning (ReAct’s contribution). The binary is obsolete.

What to Do

  1. Default to hybrid: function-calling model + reasoning field in every action + DAG planner. Log all three.
  2. Profile token cost: measure λ for your workload. Optimize the utility/token ratio.
  3. Build snapshot eval Sun et al. (2025) — test all three paradigms on your actual failure modes.
  4. Invest in planning infrastructure (DAG builder, scheduler, rollback) — that pays off regardless of paradigm.
  5. Don’t marry a paradigm. The model, the host, the task — they change. The architecture (loop + memory + tools + eval) stays.

The model emits tokens. The host decides what those tokens mean. Design the host.