Introduction#

When developers talk about AI in 2026, they rarely talk only about “getting a model to generate a piece of text”—they talk about “getting a model to accomplish a task.” Behind this shift is the rise of AI Agents: LLMs are no longer just answering questions; they can plan, call tools, observe results, self-correct, and ultimately deliver a verifiable outcome.

But an Agent isn’t as simple as “stuffing an LLM into a while True loop.” Over the past two years, the community has distilled several repeatedly validated architectural patterns. Once you understand these patterns, you understand the internal skeleton of tools like Claude Code, OpenHands, and AutoGPT.

This article breaks down the three most core patterns—ReAct, Plan-and-Execute, and the Reflection loop (Reflexion)—and provides minimal implementations you can run directly.

Starting from a naive idea#

The most naive Agent can be written like this:

1
def naive_agent(task: str) -> str:
2
    for _ in range(10):
3
        response = llm(task)          #Ask the model
4
        action = parse_action(response) #Parse out the action
5
        result = execute(action)        #Execute the action
6
        task += f"\nResult: {result}"     #Feed the result back in
7
    return task

This code “works,” but the problems quickly surface:

1. The model doesn’t know what it’s doing: it can’t distinguish between “thinking” and “acting,” the output format is chaotic, and it’s hard to parse.
2. There’s no explicit stopping condition: the model doesn’t know when to stop.
3. When it hits an error, it just spins in place: without a reflection mechanism, the same mistake gets repeated ten times.

Architectural patterns emerged precisely to answer these questions.

Pattern 1: ReAct (Reasoning + Acting)#

ReAct is a classic paradigm proposed by Yao et al. in 2022. Its idea can be summed up in one sentence: have the model alternately output “Thought” and “Action,” and use “Observation” feedback from the external environment to drive the reasoning forward.

Its core contribution is defining a clear output protocol for the Agent:

1
Thought: I need to search for relevant information first
2
Action: search[ReAct paper]
3
Observation: Search results: ...
4
Thought: The search results mention "alternating reasoning and acting," which I can use to answer
5
Final Answer: ReAct is a ...

This protocol looks simple, but it solves the first two problems of the naive implementation: the format is fixed and parseable, and there’s a clear Final Answer stop signal. Below is a minimal runnable implementation:

1
#react_agent.py — a minimal runnable ReAct loop
2
import re
3

4
def llm(prompt: str) -> str:
5
    """LLM abstraction interface, replace with any model API you use."""
6
    raise NotImplementedError
7

8
TOOLS = {
9
    "search": lambda q: f"Search results for “{q}”: …",
10
    "calculator": lambda expr: str(eval(expr)),
11
}
12

13
SYSTEM = (
14
    "You are an Agent that can call tools. Strictly output in the following format:\n"
15
    "Thought: <your reasoning>\n"
16
    "Action: <tool name>[<parameters>]\n"
17
    "When you can give the final answer, output:\n"
18
    "Final Answer: <answer>"
19
)
20

21
def run_react(question: str, max_steps: int = 6) -> str:
22
    history = SYSTEM
23
    for _ in range(max_steps):
24
        history += f"\nQuestion: {question}\n"
25
        raw = llm(history)
26
        history += raw
27

28
        action = re.search(r"Action:\s*(\w+)\[([^\]]+)\]", raw)
29
        if action:
30
            tool, arg = action.group(1), action.group(2)
31
            history += f"\nObservation: {TOOLS[tool](arg)}"
32
            continue
33

34
        if "Final Answer:" in raw:
35
            return raw.split("Final Answer:", 1)[1].strip()
36

37
    return "Reached the maximum number of steps without arriving at an answer"

ReAct’s advantages are that it’s intuitive, controllable, and interpretable—the Thought at each step leaves behind a reasoning trace, making debugging easy. Its drawbacks are also obvious: each step requires regenerating the full context, so token consumption is high; and its planning ability for long-chain tasks is weak, making it prone to “taking one step and seeing what happens next” and drifting away from the goal.

Pattern 2: Plan-and-Execute (plan first, execute later)#

To address ReAct’s “lack of global planning,” Plan-and-Execute splits the task into two phases: first use a Planner to generate a complete plan, then have an Executor carry it out step by step.

1
Task → [Planner generates step list] → [Executor executes in sequence] → aggregate results

The core code is as follows:

1
#plan_and_execute.py — plan first, then execute step by step
2
def plan_and_execute(task: str) -> str:
3
    #Phase one: planning
4
    plan = llm(
5
        "Please break down the following task into several executable steps,"
6
        "List each step as '- [ ] step description':\n\n"
7
        f"Task: {task}"
8
    )
9
    steps = re.findall(r"- \[ \]\s*(.+)", plan)
10

11
    #Phase two: execute one by one, each step can see the results of previous steps
12
    context = f"Task: {task}\nPlan:\n{plan}\n\n"
13
    for i, step in enumerate(steps, 1):
14
        context += f"\nExecuting step {i}: {step}\nExecution result:"
15
        context += llm(context)
16
    return context

This pattern is especially suited to tasks that are clearly stepped and can be decomposed in advance, such as “research a topic and produce a report” or “deploy a service according to a checklist.” Its cost is also more controllable—there’s no need to re-reason at every step like ReAct.

But it has a soft spot too: real-world tasks are often not linear. If, while executing step 3, you discover that the assumption in step 1 was wrong, Plan-and-Execute needs an additional “re-planning” mechanism as a fallback. In engineering practice, projects like LangGraph abstract planning, execution, and re-planning into orchestration-ready graph nodes.

Pattern 3: Reflection loop (Reflexion)#

Both ReAct and Plan-and-Execute assume “the model can get it right in one shot.” But in real scenarios, the first generated answer is often wrong. Reflexion introduces a closed loop of external evaluator + verbal reflection: execute → evaluate → reflect → retry with the reflection.

1
#reflexion.py — reflection loop: execute → evaluate → reflect → retry
2
def reflexion(task: str, max_attempts: int = 3) -> str:
3
    reflection = ""
4
    for _ in range(max_attempts):
5
        result = run_react(task)  #Reuse the ReAct executor from earlier
6
        feedback = llm(
7
            f"Task: {task}\nCurrent result: {result}\n"
8
            f"History reflection: {reflection or 'None'}\n"
9
            "Please evaluate whether the result achieves the goal and provide specific suggestions for improvement."
10
        )
11
        if "Achieved" in feedback or "Success" in feedback:
12
            return result
13
        reflection = feedback  #Write the reflection into the context of the next attempt
14
    return result

The key insight of the reflection loop is: failure itself is valuable information. Feeding the reason for the previous failure back to the model in natural language is essentially a lightweight form of “verbal reinforcement learning”—no gradient descent needed; language alone can make the model do better the next time.

This mechanism is especially effective in code generation scenarios: have the model write code → run the tests → feed the error message back as a reflection → write it again. After a few cycles, it often passes the tests. This is also the core of many “AI automatically fixes bugs” tools.

Comparison and selection of the three patterns#

In real engineering, these patterns are not mutually exclusive. A mature Agent (such as a coding assistant) is often a combination of them: use Plan-and-Execute for task decomposition, use ReAct to complete the tool calls at each step, and layer Reflexion on top for failure retries. This is also why more and more teams choose to use graphs/state machines to orchestrate Agents—because real workflows are a superposition of these patterns, not a choice between one or the other.

Conclusion#

The essence of the Agent architecture pattern is to decouple “the model’s capabilities” from “the control of the flow.” ReAct gave the model a parseable thought-action protocol, Plan-and-Execute filled in global planning, and Reflexion filled in self-correction. Once you understand these three building blocks, reading source code like LangGraph or OpenHands won’t intimidate you with their complexity—most of them simply make these three building blocks more robust and easier to orchestrate.

For readers who want to get hands-on, my suggestion is: first manually implement the three minimal versions from this article. In under 100 lines of code, you can build an intuitive feel for how an Agent operates, which is more worthwhile than directly calling any high-level framework.

References:

1. Yao, S., et al. “ReAct: Synergizing Reasoning and Acting in Language Models.” arXiv 2022. https://arxiv.org/abs/2210.03629
2. Shinn, N., et al. “Reflexion: Language Agents with Verbal Reinforcement Learning.” arXiv 2023. https://arxiv.org/abs/2303.11366
3. Wang, L., et al. “Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models.” arXiv 2023. https://arxiv.org/abs/2305.04091
4. LangGraph official documentation (Agent orchestration graph). https://langchain-ai.github.io/langgraph/