Choosing the Right AI Agent Architecture: From ReAct to Swarm – 6 Practical Options and Pitfalls

1. Understanding What Each Architecture Fixes

Large language models have three inherent shortcomings. Each agent architecture is designed to compensate for one of them:

Inability to act (only generates text, cannot invoke tools) → ReAct

Inability to plan (can take next step but not perform global planning) → Planner‑Executor

Inability to collaborate (limited knowledge scope) → Multi‑Agent

Workflow is special: instead of filling a shortcoming, it deliberately limits LLM autonomy to gain deterministic control.

Clarifying this starting point makes the later selection logic straightforward.

2. ReAct – Letting the Agent "Take Action"

Core idea: ReAct = Reason + Act. The agent repeatedly executes a loop of "think → act → observe" until the task finishes.

User: What was Q3 revenue last year? Think: I need to query a database, call a text2sql tool. Act: Invoke text2sql, run the generated SQL. Observe: SQL returns empty result. Think: Data is missing, inform the user. Act: Return "Q3 revenue data not available". Done.

Implementation: ReAct is not a separate system; it is an orchestration mode configured in the agent definition. The orchestrationMode field is set to react (default falls back to Workflow). A ReAct‑mode agent must specify:

Orchestration mode

Bound tool list (LLM decides when to use each)

Maximum loop count (to prevent infinite calls)

When to use:

✅ Open‑ended tasks, uncertain steps, "think‑while‑doing" scenarios such as knowledge‑base Q&A, complex data analysis, or RAG retrieval that adapts to intermediate results.

❌ Fixed‑step, compliance‑driven processes – use Workflow instead.

Pitfalls: ReAct lacks a global view; with many loops it can lose focus and errors accumulate.

Real incident: In the seventh loop the model repeatedly called the same search tool because an unrelated error log was mistakenly interpreted as a signal to re‑search.

Solution: Limit the maximum loop count and apply structured filtering to observation results.

3. Workflow – Determinism for Controllability

Core idea: Workflow is not an agent but a developer‑defined process. The LLM is placed at fixed nodes and has no decision‑making power about the next step.

Implementation in the project uses Spring AI Alibaba’s Graph Core (StateGraph). A workflow is defined as JSON stored in a database, describing nodes (type: llm / tool / text2sql / condition / parallel / summarize …) and edges (transitions and conditions). The JSON is parsed by WorkflowGraphBuilder into a StateGraph, compiled, and executed. Developers only need to supply the JSON.

Typical application – Text2Sql pipeline:

START → Prepare (load context) → Intent (classify) → Context (recall schema) → GenerateSql → Execute → SelfHeal (embedded ReAct loop for SQL auto‑repair) → Render → Finalize

When to use:

✅ Fixed steps, clear rules, high compliance – e.g., expense reimbursement, leave requests, contract review, any auditable scenario.

❌ Open‑ended exploratory tasks – delegate to ReAct.

Workflow’s essence: it does not prevent AI from acting; it simply confines AI to the appropriate granularity where deterministic routing is required.

4. Planner‑Executor – Separate Planning from Execution

Core idea: ReAct performs "think while doing"; Planner‑Executor follows "plan first, then act".

User: Analyze whether this company is worth investing. Planner: Decompose the task – 1) fetch basic info, 2) fetch financial data, 3) fetch industry comparison, 4) fetch risk factors, 5) generate investment report. Executor: Execute the plan step by step → [1] → [2] → [3] → [4] → [5] (if a step fails, Planner revises the remaining plan).

Comparison with ReAct:

Planning timing – ReAct: on‑the‑fly; Planner‑Executor: plan first.

Global view – ReAct: none; Planner‑Executor: has.

Suitable scenarios – ReAct: uncertain, exploratory steps; Planner‑Executor: complex tasks with defined steps.

Typical examples – ReAct: knowledge Q&A Planner‑Executor: deep research.

When to use:

✅ High‑value, long task chains with many dependencies – deep research reports, complex software development, multi‑step business analysis.

❌ Costly planning overhead; if the planner’s quality is poor, the whole chain fails.

Implementation note: Planner‑Executor is a special mode of Workflow – the Planner is simply the first node that outputs a plan, followed by regular nodes that execute it. Adding a planner node type is sufficient; no separate system is required.

5. Multi‑Agent – Specialized Collaboration

Core idea: Multi‑Agent addresses the "cannot collaborate" shortcoming. When a task requires expertise from multiple domains, a single agent’s knowledge boundary is insufficient.

User: Analyze this investment. Legal Agent → contract risk assessment Financial Agent → financial metric calculation Market Agent → industry comparison Report Agent → synthesize final report

The real difficulty is not the number of agents but how they cooperate.

5.1 Supervisor mode – Centralized management

The Supervisor acts as the sole brain, assigning tasks, coordinating, reviewing, and delivering the final output. Suitable for clear goals, strict quality requirements, and tightly controlled enterprise processes.

5.2 Swarm mode – Decentralized collaboration

Agents negotiate autonomously and transfer control dynamically (e.g., a Research Agent hands over to a Legal Agent when legal input is needed). Ideal for open‑ended, highly exploratory, and rapidly changing environments.

When to adopt Multi‑Agent: Ask three questions:

Does the task need expertise from multiple domains? (If no, a single agent suffices.)

Do agents need dynamic negotiation? (If no, use Supervisor; if yes, use Swarm.)

Does the coordination cost match the expected benefit? (If not, avoid Multi‑Agent.)

True cost: Defining communication protocols, handling state transfer, and managing failure recovery can be an order of magnitude more complex than a single Workflow handling intent routing.

6. Layered Architecture

All six architectures are not isolated; they stack layer by layer, each plugging a specific LLM shortcoming:

ReAct – fixes "cannot act".

Workflow – fixes "needs controllability".

Planner‑Executor – fixes "cannot plan".

Multi‑Agent – fixes "cannot collaborate".

Supervisor / Swarm – two collaboration patterns within Multi‑Agent.

7. Decision‑Tree Overview

A four‑step decision tree simplifies the selection logic.

8. Five Practical Recommendations

Start with Workflow, not Multi‑Agent. Workflow is the simplest and most controllable; get deterministic processes running before adding autonomy.

ReAct and Workflow are complementary, not exclusive. In our Text2SqlGraph, the main flow is a Workflow with a ReAct‑based SelfHeal sub‑loop.

Planner‑Executor does not require a separate system. It is just a planner node inside an existing Workflow.

Multi‑Agent has a high entry barrier. Only adopt after confirming that coordination costs are outweighed by benefits.

Architecture complexity is a cost, not a benefit.

The most suitable architecture is the one that is just enough, not the one with the highest theoretical capability.