Loading...
What an LLM agent actually is, the perceive-think-act loop that sits at the core of every modern agent, the ReAct pattern that fused reasoning with action, what early autonomous agents got wrong, and the design space you choose from when building your own.
An LLM agent is a system that wraps a language model in a loop: it observes the world, thinks about what to do, takes an action, sees the result, and repeats until a task is complete. That sounds trivial, but it is the single most important shift in how we use LLMs since the introduction of chat. A bare LLM is a function — text in, text out, one shot. An agent is a process — a controller that decides when to call the model, what context to give it, what tools it can invoke, and when the work is finally done.
The central object of study is the agent loop itself. Concretely, at every step the agent's controller composes a context from a system prompt, the user goal, the history so far, and any retrieved memory, then asks the LLM to produce one of two things: another thought ("I should look up the user's order ID first") or a structured action (search_orders(user_id='alice')). If it produced an action, the controller executes the corresponding tool, captures the observation, appends (thought, action, observation) to the history, and runs the model again. The loop terminates when the model produces a special final_answer action — or when the controller hits a step budget.
The paper that crystallized this design is ReAct (Yao et al., 2022): Reasoning + Acting. Before ReAct, prompting research had treated reasoning ("chain-of-thought") and acting ("tool use") as separate techniques. ReAct's contribution was simply to interleave them in the same generation: alternating Thought: and Action: lines in a single transcript. That tiny change made the model grounded — its reasoning could be checked against the world via observations, instead of running open-loop and hallucinating its way to a wrong answer.
This chapter covers:
Click any topic to jump in
Agents vs workflows vs chatbots — the LLM owns the control flow at runtime.
From the abstract definition to the implementation
Interleaved Thought / Action / Observation — the canonical pattern that grounded reasoning in real observations.
What each primitive does, and how each one fails independently.
AutoGPT and BabyAGI — what open-ended planning, vector-soup memory, and missing self-critique cost us.
A decision rubric: when a workflow beats a loop, and when a single agent beats a crew.
Everyone uses the word agent loosely — a chatbot, a script, a cron job, an LLM with a function call. To build well, we need a tighter definition. An agent is a system in which an LLM dynamically directs its own control flow: it decides at runtime which tool to call next, when to ask for clarification, when to retry, and when it is done. Anything where that control flow is hard-coded by you the developer is a workflow, not an agent — and Anthropic's Building Effective Agents essay makes the strong case that workflows are usually what you actually want.
A useful three-way split:
The practical implication: agents are slower, more expensive, and harder to test than workflows. Use them only when the task is genuinely open-ended (you cannot enumerate the steps in advance) or when the user input space is so wide that no fixed pipeline can cover it.
Think of an agent as a stochastic policy over an action space that includes both external actions (tool calls) and an internal final_answer action that terminates the episode. A workflow is the degenerate case where at every state — there is no decision to make, only computation to perform. As grows, you gain expressive power but pay for it: variance in the policy goes up, episodes get longer, and the value of a strong base model dominates over any clever orchestration.
You are building "a feature where a user types a question and gets the answer from our internal docs." Should you build an agent?
Every modern LLM agent depends on three capabilities that did not exist (or were unreliable) in pre-2023 LLMs:
If any of the three is missing, you do not have a working agent — you have a system that appears to work on demos and falls apart in production.
These three capabilities can be cast as constraints on the conditional distribution . Instruction following requires that assigns mass only inside the format constraints implied by the system prompt — measurable as the rate at which sampled outputs parse. Structured output requires to be peaked enough that greedy or low-temperature decoding produces valid JSON. In-context reasoning requires the effective context length to actually be useful — a model with a 200k window but a 10k useful window will fail on long agent traces.
A team is building a customer-support assistant that can either (a) answer FAQs from a knowledge base, (b) refund an order, or (c) escalate to a human. They are debating: agent loop or fixed workflow?