From ReAct to Supervisor-Worker: Core Concepts and Architecture Choices of AI Agents

A few days ago, I was chatting with a friend who works in business, and he asked me very seriously: "Everyone's talking about Agents everywhere now—what exactly is the difference between that and ChatGPT? Is it just writing longer prompts and hooking it up to a few tools, and that counts as an Agent?" This question is very representative. In 2024 and 2025, everyone was still excitedly discussing "can large models use tools?" By 2026, the discussion has already become "Is your Agent single-loop or multi-Agent? How do you design the Supervisor? How do you compress the context so it doesn't explode?" The speed at which concepts spread lags far behind the speed of technological evolution. The so-called "Agents" that many teams launch today are essentially still a conversational bot with tool calls added. It can complete simple tasks, but once the steps increase, the environment starts to change, and specialized division of labor is needed, the system quickly becomes uncontrollable—costs soar, loops cannot terminate, and after an error occurs, you have no idea which layer the problem is in. This article will not talk about vague trends, nor will it pile up paper titles. I will use the most straightforward way possible to explain the core concepts of Agents, mainstream architectural patterns, and the pitfalls you will really hit in production environments, all at once. After reading, you should at least be able to answer these questions: What is the essential difference between an Agent and an ordinary large model call? What problems do ReAct, Plan-and-Execute, and Reflexion actually solve, and what scenarios are they each suitable for? When should you use multi-Agent, and when does using it make things worse? What exactly is the difference between a Supervisor, an ordinary Agent, and an Orchestrator? When it comes to real implementation, which engineering problems should be prioritized first?

Get ready, let's start from the beginning. 1. The essence of an Agent: it is not a "model that can talk," but a "closed loop that can act"

First, let's clarify the most easily confused point. A large model (LLM) itself is an input→output function. You give it a piece of text, and it returns a piece of text. It has no "goal," nor the ability to "act continuously." An Agent is different. An Agent has at least four basic capabilities: Goal: it knows what it needs to accomplish. Perception: it can receive environmental feedback (tool return results, new user input, system state changes). Decision-making: it can decide what to do next based on the current observation. Action: it can actually call tools, modify state, or delegate to other Agents.

These four capabilities form a closed loop. As long as the task is not complete, it continues "perceive→decide→act→perceive again." This is why we say "an Agent is a closed loop of action," rather than "a model that can chat." Let's illustrate with the simplest example. The user says: "Help me check tomorrow's high-speed trains from Shanghai to Beijing, pick a suitable one, and tell me whether I need to book tickets in advance." An ordinary large model might directly make up a train number, or tell you "I suggest you check on 12306." An Agent with tool-calling capabilities would do this: Think: I need to first get real-time train information. Act: call the high-speed rail query tool. Observe: get the returned list of trains. Think again: filter according to user preferences (assuming the user previously mentioned preferring afternoon departures). Act again: maybe check ticket availability again. Finally, give an evidence-based recommendation.

The key difference is: it interleaves "thinking" and "acting," and each step depends on real environmental feedback, rather than generating the entire answer all at once. This idea of "interleaving" directly leads to today's most basic and most widely used Agent pattern—ReAct. 2. The three foundational patterns of a single Agent: ReAct, Plan-and-Execute, and Reflexion

Single-Agent systems are the foundation of all complex architectures. If you don't understand how a single Agent works, multi-Agent will basically become a disaster. At present, the three most commonly discussed patterns in production environments are ReAct, Plan-and-Execute, and Reflexion. They solve problems at different levels and are often used in combination. 1. ReAct: an adaptive loop that takes one step and looks one step ahead

The core idea of ReAct (Reason + Act) is very direct: have the model first produce a Thought at each step, then decide on an Action, then observe the result (Observation), and repeat this loop until the task ends. Its execution flow can be represented by the following diagram:

The advantages of ReAct are very obvious: Strong adaptability. The result of any intermediate step can change the subsequent path. Friendly to unknown paths. When task steps cannot be fully enumerated in advance, it can still work. Debugging is relatively intuitive. The entire trajectory is linear, so when something goes wrong you can follow it through.

But its costs are equally real: The context expands rapidly with the number of steps. Each step must carry all historical Thoughts, Actions, and Observations, and token consumption grows approximately quadratically. It is easy to fall into local optima or infinite loops. The model may repeatedly try the same failed tool call. There are many calls, and both latency and cost are relatively high.

Therefore, when using ReAct in production, it is almost always necessary to add hard constraints: a maximum number of steps, repeated-action detection, and a token-budget circuit breaker. Scenarios suitable for ReAct: the path cannot be fully predicted in advance, the route needs to be changed based on real-time observations, the number of steps is relatively small (usually kept within 8 steps), and the task is highly interactive. Examples include open-ended information gathering, dynamically debugging code based on error messages, and customer-service conversations in which the user may interject at any time. 2. Plan-and-Execute: set the global plan first, then execute according to the graph

Plan-and-Execute separates "strategy" from "tactics." It first has a stronger model (the Planner) generate a complete task-decomposition plan, usually an ordered list of steps, or a DAG with dependency relationships. Then an executor (which can be the same model or a weaker model) executes the plan step by step. The process is as follows:

The core benefits of this pattern: The plan itself is an auditable artifact. You can review whether the plan is reasonable before execution, or even have a human approve it. Costs are more controllable. The strong model is used only for planning, and the execution phase can use cheaper, faster models. It supports a certain degree of parallelism (when steps in the plan have no dependencies).

Main risks: A wrong plan will be "faithfully executed." If the Planner misunderstands from the start, all subsequent steps will be built on an erroneous foundation. Adaptability is poor when the environment changes midway, unless a replan trigger mechanism is explicitly designed.

Scenarios suitable for Plan-and-Execute: tasks in which steps can be enumerated relatively clearly, an approvable intermediate artifact is needed, cost is sensitive, and global consistency matters more than mid-course fine-tuning. Examples include report generation (outline first), automation of known business processes, and multi-source data aggregation and analysis pipelines. 3. Reflexion: giving the Agent the ability to "criticize in hindsight"

Reflexion (and, more broadly, Reflection) is not an independent complete architecture, but a quality-closing layer. Its approach is: during or after execution, have the model verbally reflect on the trajectory just taken or the final output, generate a signal of "what went wrong and how it should be changed next time," and then retry or correct with that signal. It can be layered on top of ReAct, and also on top of Plan-and-Execute. The core problem it solves is: models often repeatedly make the same mistake. Through explicit self-criticism, "the experience of this failure" can be quickly injected into the next attempt, forming a short-term, task-specific kind of learning. The cost is also direct: additional LLM calls increase latency and cost. If the reflection itself hallucinates, it instead introduces noise. Therefore, in production, Reflexion is usually used in a restricted way—triggered only at the final output or at key failure points, rather than reflecting at every step. How the three patterns combine

In reality, almost no one uses only one pure pattern. What is more common is layered hybridization: The outer layer uses Plan-and-Execute (or a Supervisor) to produce a high-level plan. Simple, determinate steps are executed directly. Complex or uncertain steps are downgraded to a bounded ReAct sub-loop. Reflexion/Verifier is layered on at key outputs or failure points.

This hybrid preserves the auditability of the plan while leaving room for adaptability under local uncertainty. III. Why are multi-Agent systems needed? Where are the boundaries of a single Agent

When a task becomes complex enough, a single Agent encounters three structural bottlenecks: Context window and attention decay. The longer the history, the weaker the model's ability to follow early constraints. Capability dilution. A general-purpose Agent simultaneously handles retrieval, analysis, writing, and verification, and cannot excel at any one of them. Limited parallelism. A single-threaded thought-action loop cannot effectively exploit subtasks that could be parallelized.

The core value of multi-Agent systems is to break through these three bottlenecks through specialized division of labor and controlled collaboration. But one counterintuitive fact must be stated first: multi-Agent is not a free lunch. Each additional Agent increases the potential interaction paths. Coordination itself consumes tokens, increases latency, and amplifies the risk of failure propagation. Many teams adopt multi-Agent before single-Agent is even running stably, and the result is merely turning "model errors" into "coordination errors" that are harder to debug. So the criterion is simple: The single Agent's context or capability has clearly become a bottleneck → consider splitting. The task can naturally be clearly divided by responsibility or stage → splitting yields greater benefits. The team does not yet have cross-Agent tracing and state-persistence capabilities → do not split yet. IV. The mainstream form of multi-Agent collaboration: Supervisor-Worker

In 2026 production practice, the multi-Agent patterns that actually run relatively stably have highly converged on the hierarchical Supervisor-Worker (also often called Orchestrator-Workers). Basic structure

One (or a small number of) Supervisor(s) are responsible for the global picture: understanding the goal, decomposing tasks, routing to the appropriate Worker, collecting compressed results, and deciding whether to continue or replan. Multiple Workers each hold narrow responsibilities, narrow context, and specialized tools, and return only structured result summaries rather than full trajectories. The control flow is roughly as follows: The key principles of division of labor

The essence of division of labor is to narrow each Agent's decision space. Common effective dimensions of division include: Role responsibilities: retrieval, analysis, writing, critique, reporting. Model capability: strong models serve as Supervisor and final synthesis, weak models serve as execution-type Workers. Tool permissions: each Worker is exposed only to the subset of tools it needs, reducing the risk of permission explosion. Context scope: a Worker sees only the minimal information needed to complete the current subtask.

Information transfer must be structured. Downward flow is a clear task package (goal, constraints, inputs, success criteria, step limit); upward flow is a structured result package (status, summary, key evidence, error information). Free-text "hand-to-hand" passing is prohibited, otherwise information loss is almost inevitable. What exactly is a Supervisor

A common confusion must be clarified here. A Supervisor is an Agent in a special role, not another kind of thing opposed to Agents. Agent is the general term: any LLM-driven entity that can perceive, decide, and act. A Supervisor is an Agent endowed with global control authority: it is responsible for decomposition, routing, state maintenance, and final decisions.

An ordinary Worker Agent's decision scope is local ("how do I complete this subtask assigned to me"), while a Supervisor's decision scope is global ("who should act next, what should they do, and when is it considered finished"). The same underlying model can serve as either a Supervisor or a Worker; the difference lies only in the prompt, toolset, visible context given to it, and whether it has the authority to decide "who executes next." The subtle difference between Supervisor and Orchestrator

These two terms are often used interchangeably in the literature and frameworks, but they emphasize different things: Supervisor emphasizes more "who is in charge"—management, decision-making, hierarchical control. Orchestrator emphasizes more "in what order things are advanced"—process orchestration, dependency management, state transitions.

In real systems, what you actually need is often a combination of the two: a central control component that has both intelligent decision-making capability and can reliably orchestrate the execution process. What it is called is secondary; a clear definition of responsibilities is what matters. V. Where it really hurts in engineering implementation

No matter how clear the concepts are, once in a production environment, problems will erupt concentratedly at these points. 1. State and persistence

Long tasks will almost inevitably encounter crashes, rate limiting, and interruptions for human approval. Systems without checkpoint capability are basically unusable in production. State must be explicitly designed and support recovery from any interruption point. 2. Termination and circuit breaking

Multi-Agent systems are more prone than single-Agent systems to falling into mutual waiting or cyclic delegation. There must be global step budgets, token budgets, time budgets, and repeated-handoff detection. Agent systems without circuit breaking will all eventually become cost black holes. 3. Context engineering

This is currently the most underestimated capability. Each Agent should only receive the minimal context needed to fulfill its own responsibilities. Results returned by Workers must be forcibly compressed. Passing full history is a double killer of cost and attention. 4. Observability and attribution

When a single Agent has a problem, looking at the linear trajectory can usually locate it. When multiple Agents have a problem, it is often "coordination failure" rather than "some model answered incorrectly." You need to record: the Supervisor's plan versions, each routing decision, the complete task package issued, and the complete result package returned by the Worker. Without these, the system is a black box. 5. Tool and permission boundaries

Tool calls must be schema-based and pass policy checks before execution. Broad permissions + model hallucination = production incident. High-risk actions (writing to databases, sending messages, involving funds) should by default have human-in-the-loop or rule-engine interception added. 6. Misalignment of evaluation methods

High success rates on technical benchmarks often cannot correspond to real business utility. You need to look simultaneously at task success rate, cost, latency, and recoverability after failure. If you optimize only "whether it can be done" and not "how much it costs to finish and whether problems can be fixed," the system will ultimately be unsustainable. VI. How to choose an architecture that suits you: an executable decision framework

For a specific task, you can judge in the following order: Step 1: First ask whether a single Agent is enough. If there are few steps, the path is relatively certain, and the context window is sufficient to cover it, prioritize bounded ReAct or Plan-and-Execute. Simple systems are always more controllable. Step 2: If splitting is needed, prioritize Supervisor-Worker. It achieves the best current balance among predictability, debuggability, and specialization benefits. Pure peer-to-peer or Swarm is not recommended as a default choice unless there are special reasons. Step 3: Clarify where control authority lies. Who has the right to decide the next step? Who has the right to terminate? Who has the right to trigger replanning? These must be written clearly at the design stage, rather than relying on the model to "negotiate by itself" at runtime. Step 4: Treat engineering constraints as first-class citizens. State persistence, circuit breaking, structured interfaces, and tracing are not optimization items to be "patched after launch" but part of the architecture. Without them, no matter how correctly the pattern is chosen, it will not run. Step 5: Validate on a small scale with real tasks. First run through 3–5 typical tasks, while recording token consumption, latency, and failure modes. Many designs that look elegant will expose problems as soon as they encounter real data distributions. VII. In closing: clear concepts are the prerequisite for controllable engineering

An Agent is not magic; it is an engineering system that explicitly closes the loop of "goal, perception, decision, action." ReAct solves the problem of local adaptability. Plan-and-Execute solves the problem of global structure and auditability. Reflexion solves the problem of the quality loop. Supervisor-Worker solves the problem of specialized division of labor and controlled collaboration. They are not in a relationship of replacing one another but are control means that can be combined as needed. What truly determines whether an Agent system can survive in production is often not how cutting-edge the chosen pattern is, but: whether context has been effectively managed whether failures have been clearly isolated whether cost and latency have been incorporated into design constraints whether, when a problem occurs, it can be quickly located to which layer and which decision went wrong

The significance of popularizing concepts lies precisely here. Only by first thinking through these foundational issues can subsequent framework selection, model selection, and prompt optimization have a solid foundation. If you are building your own Agent system from 0 to 1, it is recommended to start with the smallest bounded ReAct, first make circuit breaking, logging, and evaluation solid, and then decide based on real bottlenecks whether to introduce Plan-and-Execute or Supervisor-Worker. Complexity is a cost, not a goal.