Agent Architectures Guide

TL;DR

• Agent architecture defines the control loop structure - how the LLM alternates between reasoning, planning, acting, and reflecting.

• ReAct (Reason + Act) interleaves thought and tool calls step-by-step; best for exploratory tasks with unknown path length.

• Plan-and-Execute separates planning from execution; the planner creates steps, an executor runs them, and a replanner adapts on failure.

• Reflexion adds self-critique - after failure, the agent reflects on what went wrong and retries with an improved strategy.

• Choose architecture based on task predictability - ReAct for open-ended exploration, Plan-and-Execute for structured multi-step workflows, Reflexion when quality and recovery matter.

Why This Matters

Two teams build the same agent - customer refund handler - and get wildly different results. Team A uses a raw ReAct loop; the agent takes 12 steps, calls the wrong tools twice, and eventually succeeds. Team B uses Plan-and-Execute with a replanner; the same task completes in 4 steps with auditable plan history.

The difference isn't the model. It's the architecture.

Architecture determines latency (how many LLM calls), cost (tokens per task), reliability (error recovery), and debuggability (can you see what the agent intended vs. what it did). Picking the wrong pattern is one of the most common reasons agent projects fail in production - not model capability, not prompt quality, but structural mismatch between task shape and control loop design.

The Problem Agent Architectures Solve

A naive agent loop - "call LLM, if tool call then execute, repeat" - works for simple tasks but breaks down when:

• Tasks have predictable structure but ReAct rediscovers the plan every step, wasting tokens and introducing variance.

• Early mistakes cascade because there's no explicit replanning - the agent keeps executing a flawed approach.

• Quality requirements demand self-correction but the loop has no reflection phase.

• Multiple specialists are needed but a single loop tries to do everything.

Architectural patterns encode proven control strategies. They're the design patterns of agent engineering - as fundamental as MVC for web apps or map-reduce for data processing.

What Is an Agent Architecture?

An agent architecture is a template for organizing the agent's control flow: which nodes exist (planner, executor, critic), how state flows between them, when the LLM is invoked, and how errors trigger recovery.

The major patterns in production use today:

These aren't mutually exclusive. Production systems often combine them - Plan-and-Execute with Reflexion on failed steps, or a hierarchical manager running ReAct workers.

How Agent Architectures Work

ReAct (Reason + Act)

Introduced by Yao et al. (2022), ReAct prompts the LLM to produce explicit reasoning before each action:

Thought: I need to find the customer's order history first.
Action: search_orders(customer_id="C-8842")
Observation: [Order O-991: $49.99, status=charged, Order O-880: $29.99, status=shipped]
Thought: Order O-991 shows a single charge. I should check payment records for duplicates.
Action: get_payment_events(order_id="O-991")
...

The LLM generates Thought → Action → (system executes) → Observation → Thought → ... until it produces a final answer.

ReAct interleaves reasoning traces and tool actions: the model thinks about what to do, calls a tool, observes the result, and repeats until it can answer.

Strengths: Flexible, handles unexpected observations, no separate planner needed. Weaknesses: Verbose (reasoning tokens cost money), no global plan visibility, can wander.

Plan-and-Execute

Separates the cognitive modes:

1. Planner - Given goal and context, produce an ordered list of steps.

2. Executor - Execute one step at a time using tools, without re-planning each step.

3. Replanner - If a step fails or returns unexpected data, revise remaining steps.

Agent systems extend LLMs with tools, memory, and planning loops so they can take actions in external environments rather than only emit text.

Strengths: Cheaper execution (small model for steps), auditable plan, predictable structure. Weaknesses: Initial plan may be wrong; rigid for highly exploratory tasks.

Reflexion

Adds a reflection loop after failed attempts:

1. Execute task (via ReAct or Plan-and-Execute).

2. Evaluator scores the outcome (rule-based or LLM-as-judge).

3. If failed, Reflector generates critique: "I queried the wrong date range because I assumed fiscal year matches calendar year."

4. Critique appended to memory; retry with improved context.

Multi-agent systems assign specialized roles to multiple LLM agents that communicate, delegate, and coordinate to solve complex tasks.

Strengths: Self-improving within a session, reduces repeated mistakes. Weaknesses: Multiple full attempts multiply cost; evaluator quality is critical.

Architecture

A composable architecture stack in LangGraph:

Agents exchange messages through defined communication channels, enabling decomposition of workflows across planner, executor, and critic roles.

Source: Research paper

Each worker can use a different internal architecture. The manager handles delegation, budget allocation, and final synthesis.

Step-by-Step Flow

ReAct Flow

1. User submits goal.
2. LLM generates Thought + Action (tool call).
3. Runtime executes tool, returns Observation.
4. Observation appended to message history.
5. Repeat steps 2–4 until LLM generates Final Answer or step limit hit.

Plan-and-Execute Flow

1. User submits goal.

2. Planner LLM generates: ["Search customer orders", "Check payment duplicates", "Issue refund if confirmed", "Notify customer"].

3. Executor takes step 1, selects tool, executes, stores result. 4. Executor takes step 2 with accumulated context. 5. Step 2 fails - payment API returns "order not found".

4. Replanner revises: ["Re-search with alternate ID format", "Check payment duplicates", ...]. 7.

Execution continues until all steps complete.

8. Synthesizer produces final user-facing response from step results.

Real Production Example

Plan-and-Execute with LangGraph for an incident triage agent:

from typing import List
from pydantic import BaseModel, Field
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, END
from typing_extensions import TypedDict

class Plan(BaseModel):
    steps: List[str] = Field(description="Ordered steps to complete the task")

class PlanExecuteState(TypedDict):
    input: str
    plan: List[str]
    past_steps: List[tuple]  # (step, result)
    response: str

planner = ChatOpenAI(model="gpt-4o", temperature=0)
executor_llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
replanner = ChatOpenAI(model="gpt-4o", temperature=0)

def plan_step(state: PlanExecuteState):
    plan = planner.with_structured_output(Plan).invoke([
        {"role": "system", "content": "Create a concise step plan for incident triage."},
        {"role": "user", "content": state["input"]},
    ])
    return {"plan": plan.steps}

def execute_step(state: PlanExecuteState):
    current_step = state["plan"][0]
    result = executor_llm.invoke([
        {"role": "system", "content": f"Execute this step using available tools: {TOOLS_DESCRIPTION}"},
        {"role": "user", "content": f"Task: {state['input']}\nStep: {current_step}\nPrior results: {state['past_steps']}"},
    ])
    # Tool execution handled by bound tools (omitted for brevity)
    return {
        "past_steps": state["past_steps"] + [(current_step, result.content)],
        "plan": state["plan"][1:],
    }

def replan_step(state: PlanExecuteState):
    if not state["plan"]:
        return {"response": synthesize(state)}
    last_step, last_result = state["past_steps"][-1]
    if "ERROR" in str(last_result):
        new_plan = replanner.with_structured_output(Plan).invoke([
            {"role": "user", "content": f"Step '{last_step}' failed: {last_result}. Remaining goal: {state['input']}. Past: {state['past_steps']}"},
        ])
        return {"plan": new_plan.steps}
    return {}

def should_end(state: PlanExecuteState) -> str:
    if state.get("response"):
        return "end"
    if not state["plan"]:
        return "respond"
    return "execute"

workflow = StateGraph(PlanExecuteState)
workflow.add_node("planner", plan_step)
workflow.add_node("execute", execute_step)
workflow.add_node("replan", replan_step)
workflow.set_entry_point("planner")
workflow.add_edge("planner", "execute")
workflow.add_conditional_edges("execute", should_end, {"execute": "replan", "respond": "respond", "end": END})

ReAct equivalent - simpler, single-node loop:

from langgraph.prebuilt import create_react_agent
from langchain_openai import ChatOpenAI

react_agent = create_react_agent(
    ChatOpenAI(model="gpt-4o", temperature=0),
    tools=[search_logs, query_metrics, page_oncall],
    state_modifier="You are an SRE agent. Think step by step before each action.",
)

result = react_agent.invoke({"messages": [("user", "API latency spiked 3x in us-east-1")]})

Use create_react_agent for prototypes and exploratory tools. Switch to explicit Plan-and-Execute when you need plan auditability and cost control on the execution phase.

Design Decisions

⚠ Common Mistakes

1. Using ReAct for structured pipelines - If your task always follows the same 5 steps, Plan-and-Execute saves 40–60% of tokens and produces consistent traces.

2. No replanner in Plan-and-Execute - A static plan that can't adapt is just a brittle workflow with extra LLM calls.

3. Reflection without a good evaluator - Reflexion is only as good as the signal telling it something failed. "Did the user say thanks?" is not a reliable evaluator.

4. Over-engineering with LATS - Tree search over actions is expensive. Reserve for domains where exploration depth genuinely matters (optimization, game playing).

5. Mixing architectures mid-task without clear handoffs - If a ReAct worker hands off to a Plan-and-Execute worker, define explicit state boundaries or context gets lost.

6. Ignoring plan storage - Plans are valuable for debugging, compliance, and user transparency. Log them.

Where It Breaks Down

• ReAct wanders on long tasks - Without a global plan, agents lose track of goal after 10+ steps. Mitigate with periodic re-planning or hierarchical delegation.

• Plan-and-Execute assumes planability - Some tasks can't be planned upfront (real-time negotiation, interactive debugging). Use ReAct.

• Reflexion retry storms - Without a retry cap, reflection loops burn budget. Limit to 2–3 attempts with escalating model capability.

• Architecture overhead on simple tasks - A 1-tool lookup doesn't need Plan-and-Execute. Route by task complexity.

• Cross-architecture eval inconsistency - Metrics tuned for ReAct (steps to success) may not apply to Plan-and-Execute (plan quality). Design eval per architecture.

Running in Production

Best Practice

✅ Best Practices - Instrument every stage, version embedding models, enforce access control at retrieval time, and evaluate on a fixed golden set before shipping changes.

Important

Start with ReAct for prototyping. Migrate to Plan-and-Execute when you can enumerate typical step sequences and need cost/latency predictability. Add Reflexion only after baseline architecture is stable and eval shows recoverable failure modes.

Ecosystem

• LangGraph: First-class support for ReAct (create_react_agent), Plan-and-Execute (tutorials and examples), checkpointing, and custom architectures.

• LangChain: AgentExecutor (legacy ReAct), LCEL chains for custom loops.

• AutoGen: Conversational multi-agent patterns with built-in reflection.

• CrewAI: Role-based agents with implicit hierarchical architecture.

• OpenAI Agents SDK: Handoff-based multi-agent with guardrails.

Related Technologies

• AI Agents: Foundation concepts - control loops, tools, state - that architectures build upon.

• Agent Planning: Deep dive into decomposition, replanning, and goal verification.

• Agent Memory: Reflection and replanning depend on memory to persist critiques and past attempts.

• Multi-Agent Systems: Hierarchical architectures deploy multiple specialized agents.

• Workflows vs Agents: Plan-and-Execute blurs the line - understand when architecture is still "agentic."

• Prompt Engineering: Architecture prompts (planner, reflector, evaluator) require careful design.

• LLM Evaluation: Evaluators for Reflexion and replanning decisions.

Learning Path

Prerequisites: AI Agents · Tool Calling · Prompt Engineering

Next topics: Agent Planning · Agent Memory · Multi-Agent Systems

Estimated time: 55 min · Difficulty: Advanced

FAQs

Which architecture should I start with?

ReAct. It's the simplest to implement (create_react_agent in LangGraph), handles the widest range of tasks, and teaches you agent failure modes before adding complexity.

When should I switch from ReAct to Plan-and-Execute?

When you observe consistent step sequences across runs, need plan auditability, or ReAct costs/latency are too high due to verbose reasoning at every step.

Can I combine ReAct and Plan-and-Execute?

Yes. Common pattern: Plan-and-Execute for the overall workflow, with ReAct as the executor for individual steps that require exploration.

What is LATS and when should I use it?

Language Agent Tree Search - explores multiple action branches, evaluates them, and expands promising paths. Use for complex optimization or when the action space is large and exploration depth matters. Too expensive for most production APIs.

How does Reflexion differ from simple retry?

Simple retry repeats the same prompt. Reflexion adds explicit critique of the failed attempt to context, so the next attempt avoids the specific mistake.

Does architecture choice affect which model I use?

Yes. Use your most capable model for planning and reflection. Use a cheaper, faster model for execution steps in Plan-and-Execute. ReAct typically needs one capable model throughout.

How do I evaluate plan quality?

Compare generated plans against expert-written plans for the same tasks. Measure: step count, step ordering correctness, missing steps, unnecessary steps. Plan quality predicts execution success.

Is ReAct the same as chain-of-thought?

Related but different. Chain-of-thought is a prompting technique (think before answering). ReAct extends it with interleaved actions and observations - the "Act" part.

How many replans are too many?

More than 2 replans per task suggests the planner prompt, tools, or task decomposition needs fixing - not more replanning capacity.

Can architecture be selected dynamically?

Yes. A router classifies task complexity and routes to ReAct (simple/exploratory) or Plan-and-Execute (structured). This is a best practice in production agent platforms.

What's the difference between hierarchical agents and Plan-and-Execute?

Plan-and-Execute is a single agent with two modes (plan, execute). Hierarchical agents are separate agent instances - a manager with distinct worker agents, each potentially using different architectures.

How do I debug Plan-and-Execute failures?

Check three layers: (1) Was the initial plan wrong? (2) Did execution deviate from the plan? (3) Did the replanner produce a worse plan? Log each layer separately.

References

• ReAct: Synergizing Reasoning and Acting (Yao et al., 2022)
• LangChain Agents Documentation
• OpenAI Agents Guide

Further Reading

• Anthropic Tool Use Documentation
• LangGraph Documentation
• Microsoft AutoGen

Summary

• Agent architecture is the control flow pattern - as important as model choice for reliability and cost. - ReAct interleaves reasoning and action; best for exploration. Plan-and-Execute separates planning from execution; best for structured tasks. - Reflexion adds self-critique for quality-critical tasks with retry budget. - Use capable models for planning/reflection, cheap models for execution.

• Start with ReAct, migrate to Plan-and-Execute when task structure stabilizes, add Reflexion when eval shows recoverable failures. - Log plans, steps, and reflection critiques - they're essential for debugging and compliance. - Most production systems combine patterns: hierarchical managers, Plan-and-Execute workers, Reflexion on critical steps.