What Makes an LLM an Agent (and What Doesn't)

The best way to predict the future is to invent it. The second best way is to build an agent and let it figure things out.

Agent X, Self-Starting AI Agent

26.1.1 What Makes an Agent?

"Agent" gets slapped on everything from a one-shot prompt chain to a fully autonomous system, so it pays to nail down the line. An AI agent uses a language model to pick the next action, then loops (perceive, decide, act) until the task finishes or hits a stop condition. The defining property is autonomy in action selection: the model picks the next step. If the developer hard-coded the sequence, it is a chain, not an agent.

The Perception-Reasoning-Action Loop

Every agent runs the same four-step cycle. The agent perceives by reading input: user messages, tool outputs, results from the previous step. It reasons with the language model about the next move. It acts: call a tool, write a response, ask for clarification. Then it observes the result and loops back to perceive. Figure 26.1.3 shows the loop.

Figure 26.1.3: The perception-reasoning-action loop that defines all AI agents

Agents vs. Chains vs. Workflows

The simple-to-complex orchestration spectrum has three rungs. A chain is a fixed sequence of LLM calls; you wrote the steps in code. A workflow adds if/else and loops, but you wrote those branches too. An agent hands control flow to the LLM: it picks which tool to call, in what order, and when to stop. Use the hybrid ML/LLM decision framework from Chapter 13 to decide whether the extra autonomy is worth the unpredictability.

26.1.2 The Four Agentic Design Patterns

Andrew Ng identified four foundational agentic design patterns that appear across virtually all agent architectures. These patterns can be used individually or composed together, and understanding them provides a vocabulary for designing and analyzing agentic systems.

Pattern 1: Reflection

In the reflection pattern, the LLM reviews its own output and iteratively improves it. This can be as simple as asking the model to critique its response, or as sophisticated as having separate "generator" and "critic" roles. Reflection is powerful because it lets the model catch errors, improve quality, and refine its approach without external feedback.

# Reflection pattern: draft, critique, revise. The same model wears two hats,
# first generator then critic, and we loop until the critic signals no major issues.
from openai import OpenAI

client = OpenAI()

def _chat(messages: list[dict], model: str = "gpt-4o") -> str:
    return client.chat.completions.create(model=model, messages=messages).choices[0].message.content

def reflect_and_improve(task: str, max_rounds: int = 3) -> str:
    """Generate a response, then iteratively critique and revise it."""
    draft = _chat([{"role": "user", "content": task}])
    for _ in range(max_rounds):
        # Ask the critic for specific, actionable feedback on the current draft.
        critique = _chat([
            {"role": "system",
             "content": "You are a critical reviewer. Find flaws, gaps, and areas for improvement. Be specific."},
            {"role": "user",
             "content": f"Task: {task}\n\nDraft:\n{draft}\n\nProvide specific, actionable critique."},
        ])
        if "no major issues" in critique.lower():
            break  # Critic is satisfied; stop early to save tokens.
        # Otherwise revise: feed the original task, the current draft, and the critique back in.
        draft = _chat([
            {"role": "system", "content": "Revise the draft to address all critique points."},
            {"role": "user",
             "content": f"Original task: {task}\n\nCurrent draft:\n{draft}\n\nCritique:\n{critique}\n\nRevised version:"},
        ])
    return draft

Pattern 2: Tool Use

Tool use extends the LLM beyond text generation by giving it the ability to call external functions: searching the web, querying databases, executing code, sending emails, or interacting with any API. The model receives tool descriptions, decides when and which tools to call, and incorporates the results into its reasoning. This is covered in depth in Section 26.6.

Tool use is architecturally significant, not merely an API feature. When a model gains the ability to call external functions, it transitions from a closed system (bounded by its training data) to an open system that can interact with the live world. This is the same leap that distinguishes a calculator from a spreadsheet connected to a database. The model's role shifts from "answer generator" to "action coordinator," and the design constraints change accordingly: latency now depends on external services, reliability depends on tool robustness, and safety requires controlling what actions the model can take. Chapter 27 explores these architectural implications in depth, including standardized protocols like MCP and A2A that formalize tool interfaces.

Pattern 3: Planning

Planning involves the LLM decomposing a complex task into subtasks before executing them. Rather than acting step by step reactively, a planning agent creates an explicit plan, then executes each step while potentially revising the plan based on intermediate results. Plan-and-execute architectures, reflection loops, and tree search methods all fall under this pattern. Section 26.2 covers planning in detail.

Pattern 4: Multi-Agent Collaboration

In the multi-agent pattern, multiple LLM instances (each potentially with different system prompts, tools, or roles) collaborate to solve a problem. One agent might research while another writes; a supervisor agent might coordinate workers; or agents might debate to reach a consensus. Chapter 27 is dedicated entirely to multi-agent architectures. summarizes these four patterns.

Figure 26.1.5: The four agentic design patterns (Ng, 2024)

26.1.3 The ReAct Framework

ReAct (Reasoning + Acting) is the most widely adopted agent architecture. We introduced ReAct as a prompting pattern in Section 12.2; here we build it into a full agent system with tool execution, state management, and error handling. Algorithm 1 formalizes the ReAct loop.

Formally, the agent maintains a trajectory $\tau_t = (h_1, a_1, o_1, \ldots, h_{t-1}, a_{t-1}, o_{t-1})$ of thoughts $h$, actions $a$, and observations $o$. At step $t$ the LLM $M$ jointly samples the next thought and action conditioned on the system prompt $\pi$, the user task $T$, and the trajectory:

$$ (h_t, a_t) \sim p_M(\cdot \mid \pi, T, \tau_t) $$

The environment then returns an observation $o_t = \mathrm{exec}(a_t)$, and the trajectory grows to $\tau_{t+1} = \tau_t \cup (h_t, a_t, o_t)$. The loop terminates either when $a_t = \texttt{FINAL\_ANSWER}(y)$ (returning $y$) or when $t$ reaches the step budget $S$. The "Re" in ReAct is exactly the conditioning of $a_t$ on $h_t$: pure Act baselines drop $h_t$ and sample $a_t \sim p_M(\cdot \mid \pi, T, \tau_t)$ directly, which empirically gives lower accuracy on multi-hop tool tasks because the model cannot externalise the intermediate reasoning that grounds the next call.

Input: user task T, tool set {tool_1, ..., tool_n}, LLM M, max steps S
Output: final answer or action result

1. Initialize context = [system_prompt, T]
2. for step = 1 to S:
  a. Thought: response = M(context)
  The LLM reasons about current state, what is known, what is needed
  b. if response contains FINAL_ANSWER:
  return extracted answer
  c. Action: parse tool_name and arguments from response
  d. Observation: result = execute(tool_name, arguments)
  e. Append (Thought, Action, Observation) to context
3. return "Max steps reached without resolution"
  

The key insight is that the explicit reasoning in step 2a (the "Thought") dramatically improves decision quality compared to acting without thinking or thinking without acting. Each thought provides a chain-of-reasoning that is also valuable for debugging when the agent makes mistakes.

from typing import Callable
class ReActAgent:
    """Minimal ReAct agent: Thought -> Action -> Observation loop."""
    def __init__(self, client, tools: dict[str, Callable], model: str = "gpt-4o"):
        self.client = client
        self.tools = tools
        self.model = model
    def run(self, task: str, max_steps: int = 10) -> str:
        # Build tool descriptions for the system prompt
        tool_desc = "\n".join(
            f"- {name}: {func.__doc__}" for name, func in self.tools.items()
            )
        system_prompt = f"""You are a ReAct agent. For each step:
        1. Thought: Reason about the current state and what to do next
        2. Action: Call a tool using the format: ACTION: tool_name(args)
        3. Wait for Observation (tool result)
        When you have the final answer, respond: FINAL ANSWER: [your answer]
        Available tools:
        {tool_desc}"""
        messages = [
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": task}
            ]
        for step in range(max_steps):
            response = self.client.chat.completions.create(
                model=self.model,
                messages=messages
                ).choices[0].message.content
            messages.append({"role": "assistant", "content": response})
            # Check for final answer
            if "FINAL ANSWER:" in response:
                return response.split("FINAL ANSWER:")[1].strip()
            # Parse and execute action
            if "ACTION:" in response:
                action_str = response.split("ACTION:")[1].strip()
                observation = self._execute_action(action_str)
                messages.append({
                        "role": "user",
                        "content": f"Observation: {observation}"
                        })
                return "Max steps reached without final answer."
    def _execute_action(self, action_str: str) -> str:
        # Parse "tool_name(args)" format and execute
        try:
            name = action_str.split("(")[0].strip()
            args_str = action_str.split("(", 1)[1].rsplit(")", 1)[0]
            if name in self.tools:
                return str(self.tools[name](args_str))
            return f"Error: Unknown tool '{name}'"
        except Exception as e:
            return f"Error executing action: {e}"

ReAct Trace Example

A typical ReAct trace shows the interleaved thought-action-observation pattern. Notice how the agent explicitly reasons before each action, and how observations feed back into the next reasoning step.

# Example trace for: "What is the population of the capital of France?"
Thought: I need to find the capital of France, then look up its population.
 The capital of France is Paris, but let me verify and get the
 current population figure.
Action: search("Paris population 2024")
Observation: Paris has a city population of approximately 2.1 million
 and a metropolitan area population of about 12.3 million.
Thought: I now have the information. The capital of France is Paris,
 with a city population of about 2.1 million. I should provide
 both the city and metro figures for completeness.
FINAL ANSWER: The capital of France is Paris, with a city population
of approximately 2.1 million and a metropolitan area population
of about 12.3 million.

26.1.4 Cognitive Architectures and State Machines

As agents grow more complex, the simple ReAct loop becomes insufficient. Cognitive architectures provide a richer framework for organizing agent behavior by introducing explicit state management, memory systems, and structured decision-making processes. A cognitive architecture defines how an agent thinks, not just what it thinks about.

pip install langgraph langchain
from langgraph.prebuilt import create_react_agent
from langchain_openai import ChatOpenAI
def search(query: str) -> str:
    "Search the web for the query."
    return f"results for {query}"
agent = create_react_agent(ChatOpenAI(model="gpt-4o"), tools=[search])
result = agent.invoke({"messages": [("user", "Who won the 2024 Turing Award?")]})

Agent State Machines

Many production agents are best modeled as state machines, where the agent transitions between well-defined states based on its observations and decisions. This provides predictability and debuggability while still allowing the LLM to make autonomous decisions within each state. Figure 26.1.6a shows the agent state machine with its transitions.

# Define AgentState, AgentContext, StatefulAgent; implement __init__, run, _handle_planning
from enum import Enum
from dataclasses import dataclass, field
class AgentState(Enum):
    PLANNING = "planning"
    EXECUTING = "executing"
    REFLECTING = "reflecting"
    WAITING_FOR_HUMAN = "waiting_for_human"
    COMPLETE = "complete"
    ERROR = "error"
@dataclass
class AgentContext:
    """Tracks the full state of an agent's execution."""
    task: str
    state: AgentState = AgentState.PLANNING
    plan: list[str] = field(default_factory=list)
    completed_steps: list[str] = field(default_factory=list)
    observations: list[dict] = field(default_factory=list)
    current_step_index: int = 0
    error_count: int = 0
    max_errors: int = 3
class StatefulAgent:
    """Agent that operates as a state machine with explicit transitions."""
    def __init__(self, client, tools):
        self.client = client
        self.tools = tools
        self.transitions = {
            AgentState.PLANNING: self._handle_planning,
            AgentState.EXECUTING: self._handle_executing,
            AgentState.REFLECTING: self._handle_reflecting,
            AgentState.ERROR: self._handle_error,
            }
        def run(self, task: str) -> str:
            ctx = AgentContext(task=task)
            while ctx.state not in (AgentState.COMPLETE, AgentState.WAITING_FOR_HUMAN):
                handler = self.transitions.get(ctx.state)
                if handler:
                    ctx = handler(ctx)
                else:
                    break
                    return self._format_result(ctx)
            def _handle_planning(self, ctx: AgentContext) -> AgentContext:
                # LLM creates a step-by-step plan
                plan = self._call_llm(
                    f"Break this task into concrete steps:\n{ctx.task}"
                    )
                ctx.plan = self._parse_plan(plan)
                ctx.state = AgentState.EXECUTING
                return ctx
    def _handle_executing(self, ctx: AgentContext) -> AgentContext:
        if ctx.current_step_index >= len(ctx.plan):
            ctx.state = AgentState.REFLECTING
            return ctx
            step = ctx.plan[ctx.current_step_index]
            try:
                result = self._execute_step(step, ctx)
                ctx.observations.append({"step": step, "result": result})
                ctx.completed_steps.append(step)
                ctx.current_step_index += 1
            except Exception as e:
                ctx.error_count += 1
                ctx.state = AgentState.ERROR if ctx.error_count >= ctx.max_errors \
            else AgentState.EXECUTING
            return ctx
            def _handle_reflecting(self, ctx: AgentContext) -> AgentContext:
                # LLM reviews results and decides: complete or replan
                assessment = self._call_llm(
                    f"Task: {ctx.task}\nCompleted: {ctx.completed_steps}\n"
                    f"Results: {ctx.observations}\n\n"
                    f"Is the task fully complete? If not, what remains?"
                    )
                if "complete" in assessment.lower():
                    ctx.state = AgentState.COMPLETE
                else:
                    ctx.state = AgentState.PLANNING # Replan with new context
                    return ctx

Figure 26.1.7: Agent state machine with planning, executing, reflecting, and error states

26.1.5 Agent Memory Systems

Agents need memory beyond the single context window. We sketch the categories briefly here; Section 26.6 covers the full taxonomy, storage strategies, retrieval policies, and production patterns. The four-way split below maps directly to the human-memory taxonomy in cognitive psychology (Tulving 1972, "Episodic and Semantic Memory"), which is not an accident: the names were borrowed in the 2023-2024 MemGPT, Voyager, and Generative Agents papers, and the analogy has stuck in production agent architectures since.

• Working memory: the live context window during a turn (system prompt, user message, tool results, reasoning traces). Bounded by the model's context limit; the engineering question is what to keep and what to evict. A GPT-4o-with-128k-context turn typically devotes 5-10k tokens to the system prompt and tool schemas, 20-40k to retrieved evidence, and the rest to scratch reasoning; above 60k working-memory occupancy, all frontier models in 2024-2026 show measurable quality degradation per the RULER long-context benchmark (Hsieh et al., 2024).
• Episodic memory: records of past interactions stored outside the context window so the agent can recall what happened in earlier sessions. Typically a vector database keyed by user/session/topic. Park et al.'s 2023 "Generative Agents" paper (Stanford, arXiv:2304.03442) stored every observation as an episodic record in a Chroma vector DB and ran a memory-stream retrieval on every action; without this layer, the simulated agents lost coherence within a single in-game day.
• Semantic memory: extracted facts, preferences, and learned heuristics that persist across sessions. Distilled from episodic memory or populated by the agent's own reflection step. MemGPT (Packer et al., 2023, arXiv:2310.08560) implements this as a hierarchical promotion: an episodic record is promoted to a "main context" semantic entry when the agent's reflection loop scores it as high-value, mirroring the systems-consolidation theory in human declarative memory.
• Procedural memory: skill libraries, tool descriptions, and learned routines the agent invokes by name. Often stored as structured templates or callable code rather than embeddings. The canonical 2024 reference is Voyager (Wang et al., NeurIPS 2024), which played Minecraft by incrementally extending a JavaScript skill library; by the end of a 30-day run the library contained over 100 reusable skills (craft_iron_pickaxe, build_furnace, etc.), each invocable by name without re-reasoning.

The hard problems (when to write, when to retrieve, how to compress, how to forget, how to prevent contamination across users) are the topic of Section 26.6.

26.1.6 Token Budget Management

Token management is one of the most practical challenges in building agents. Unlike a single-turn completion where you control the input size, agents accumulate context over many iterations. Without careful budgeting, agents hit context limits, lose important early context, or incur excessive costs.

Strategies for Managing Token Budgets

• Summarize tool outputs: Instead of including raw API responses, extract only the relevant fields. A search result page might be 10,000 tokens raw but only 200 tokens of useful information.
• Sliding window with summarization: Periodically summarize older conversation turns and replace them with a compact summary, keeping recent turns intact.
• Tiered context priority: Assign priorities to different message types. System prompts and the current task have highest priority; old tool results have lowest priority and are evicted first.
• Lazy loading: Instead of loading all context upfront, fetch information only when the agent needs it. Store tool descriptions in a separate index and inject only the ones the agent requests.
• Step limits: Set hard limits on the number of agent iterations. If the agent cannot solve a task in N steps, it should report what it found and ask for guidance.

26.1.7 Designing for Failure

Agents fail in ways that are qualitatively different from non-agentic systems. A simple chain either succeeds or produces an error. An agent can get stuck in loops, waste tokens on unproductive actions, misinterpret tool outputs, or take increasingly erratic actions as its context window degrades. Robust agent design requires anticipating and handling these failure modes. Chapter 42 covers how to observe and measure these failures in production.

Common Agent Failure Modes

• Infinite loops: The agent repeats the same action because it does not recognize that the result is unchanged. Always implement a maximum step counter.
• Tool misuse: The agent calls a tool with invalid arguments or misinterprets the output. Clear tool descriptions and structured error messages help.
• Goal drift: Over many steps, the agent gradually shifts away from the original task. Periodically re-injecting the original task description helps maintain focus.
• Context window overflow: The agent accumulates so much history that it cannot generate useful output. Token management strategies (above) are essential.
• Cascading errors: An early mistake propagates through subsequent steps, leading the agent further astray. Reflection checkpoints catch and correct errors early.

Exercises