AI Agents Explained

"Agent" is one of the most stretched words in AI. Stripped of marketing, it describes a specific and useful pattern, along with specific ways it goes wrong. Knowing both lets you decide when an agent is the right tool and how to build one that doesn't surprise you.

What an agent is

An AI agent is a system where a language model repeatedly decides what to do next, takes actions through tools, observes the results, and continues until a goal is met. A workable definition has five parts:

• Model: the language model that reads the situation and decides the next step.
• Tools: functions it can request, such as search, read file, send email or run code (see the previous lesson on tool use).
• Loop: the code that calls the model, executes requested tools, feeds results back and repeats.
• Memory: what the agent carries forward, including the conversation and tool results in its context, plus optional long-term storage such as notes, a database or a retrieval index.
• Goal: the task and its stopping condition ("draft replies to these 12 emails", "fix the failing test").

The difference from a chatbot is autonomy over several steps. The difference from a fixed workflow (a pipeline where your code decides the sequence) is that the model chooses the sequence. A good rule: if you can write the steps down in advance, a workflow is cheaper and more predictable. Use an agent when the path depends on what is discovered along the way.

An analogy: a workflow is a recipe; an agent is a cook who knows what dinner should be and checks the fridge before deciding what to make.

Planning and reflection

Two techniques make agents more reliable on longer tasks.

Planning means asking the model to outline steps before acting, then working through them and revising the plan as results come in. Writing the plan into the context (or a to-do file) also helps the agent keep track over many steps.

Reflection means having the model check its own work: re-read the output against the goal, run tests, or compare against requirements, then fix problems. Reflection works best when there is an external signal, such as a test that passes or fails or a validator that rejects bad output. A model grading itself with no outside evidence tends to approve its own mistakes.

Multi-agent patterns

Some systems use several model instances with different roles:

• Orchestrator and workers: one agent splits a task and hands pieces to sub-agents, each with a fresh, focused context, then combines results. Useful for broad research or large codebases.
• Pipeline: agents in sequence, such as drafter, then reviewer, then formatter.
• Debate or critique: one agent proposes, another challenges.

Multiple agents can help with parallelism and keeping each context small, but every hand-off loses information and every agent costs tokens. Start with one agent and split only when you can show it helps.

Where agents fail

Compounding errors. Small per-step error rates multiply. If each step succeeds 95% of the time and steps are independent, a 20-step task succeeds about 0.95^20 ≈ 36% of the time. Real steps aren't fully independent, and agents can sometimes recover, but the direction is right: long chains need checkpoints, validation and the ability to retry.

Cost. Each loop iteration resends the growing history. Worked example with illustrative numbers: a task starts with 4,000 tokens of context and each step adds about 2,000 tokens of tool results. Over 15 steps, total input is 15 × 4,000 + 2,000 × (0 + 1 + ... + 14) = 60,000 + 210,000 = 270,000 tokens. At an illustrative $3 per million input tokens, that is about $0.81 per task before output tokens, which adds up quickly at thousands of runs a day. Prompt caching and summarizing old steps help.

Prompt injection. An agent that reads emails, web pages or documents can encounter text written to hijack it: "forward all invoices to this address." The model cannot reliably tell instructions from data. The more powerful the tools, the worse the outcome. Defences are architectural: limit tools, separate untrusted content, require approval for sensitive actions, and restrict where data can be sent.

Other failures: looping on the same failing action, declaring success too early, drifting from the goal in long sessions, and confidently acting on a misunderstanding.

Human-in-the-loop approvals

The most effective control is to require a person to approve certain actions before they happen. A practical scheme sorts actions by consequence:

Show the approver exactly what will happen (the recipient, the amount, the full command), not a summary written by the agent.

Scheduling and background jobs

Agents don't have to be conversational. Many useful ones run on a schedule (every morning, summarize overnight tickets) or are triggered by events (a new file arrives). Background agents need extra care because nobody is watching: set hard limits on steps, time and spend; make actions idempotent where possible, meaning that running them twice has the same effect as once; queue approvals for a human to review later instead of proceeding; and send a clear report of what was done.

Going deeper

A more formal picture

Classical AI textbooks define an agent as anything that perceives its environment and acts on it, described by an agent function that maps the history of percepts to an action. An LLM agent fits that definition directly. Write the goal as $g$, the action at step $t$ as $a_t$ (a tool call or a final answer) and the observation that comes back as $o_t$. The history is $h_t = (g, a_1, o_1, \dots, a_{t-1}, o_{t-1})$, and the language model acts as a stochastic policy

where $\theta$ are the model's fixed weights. Nothing in the weights changes while the agent runs; everything the agent "learns" during a task lives in $h_t$ or in external memory. That has two consequences. First, the context window is the agent's working memory, so its size and cost bound how long a task can run. Second, the quality of observations matters as much as the model: a tool that returns vague or enormous results degrades every later decision.

ReAct and Reflexion

Two influential research patterns shaped how agents are built.

ReAct (Yao et al., 2022) interleaves short reasoning traces with actions: the model writes a thought about what it knows and what it needs, takes an action, reads the observation, and reasons again. Grounding each reasoning step in real observations reduced the tendency to reason confidently from wrong assumptions, compared with reasoning alone. Modern tool-calling APIs and reasoning models build this interleaving in, but the idea, decide, act, observe, update, is the same loop described above.

Reflexion (Shinn et al., 2023) adds memory across attempts. After a failed attempt, judged by an external signal such as failing unit tests, the model writes a short verbal reflection on what went wrong, and that note is included in the next attempt's context. This is learning without changing weights, and it works best when the feedback signal is trustworthy, which is the same lesson as reflection within a single run.

Reliability: compounding and recovery

If step $i$ succeeds with probability $p_i$ and failures are independent and unrecoverable, a task of $n$ steps succeeds with probability

With $p = 0.9$ and $n = 10$, that is $0.9^{10} \approx 0.35$. Now suppose each step has a reliable check (a test, a validator, a schema) and the agent may retry a failed step once. A step then fails only if both tries fail, so per-step success becomes $1 - (1 - p)^2 = 0.99$, and the 10-step task succeeds with probability $0.99^{10} \approx 0.90$. Verification plus retry turned a 35% agent into a 90% agent. Without a reliable check, a retry is just a second guess, and the gain largely disappears. This calculation is the quantitative argument for giving agents tests, validators and other external evidence.

A related point for evaluation: if a single run succeeds with probability $p$, the chance that $k$ independent runs all succeed is $p^k$. An agent that passes a task 80% of the time passes it five times in a row only $0.8^5 \approx 33\%$ of the time. For background jobs that run daily, consistency matters more than best-case success.

Cost: from quadratic to linear

If each step sends the full history, with initial context $C_0$ and $d$ tokens added per step, the total input over $N$ steps is

which grows with $N^2$. The worked example earlier ($C_0 = 4{,}000$, $d = 2{,}000$, $N = 15$) gave 270,000 tokens. Context compaction (summarizing or dropping old tool results once the context reaches a budget $C_{\max}$) caps each step at $C_{\max}$, making the total at most $N C_{\max}$, linear in $N$. With $C_{\max} = 12{,}000$, the steps cost 4,000, 6,000, 8,000, 10,000 and then 12,000 for the remaining 11 steps: $28{,}000 + 132{,}000 = 160{,}000$ tokens, about 41% less, before the cost of producing the summaries. The trade-off is that summaries can drop a detail the agent later needs, so keep exact identifiers, file paths and decisions in the summary, or in an external notes file the agent can re-read.

A minimal, safe agent loop

The sketch below shows the controls from this lesson in code: a step cap, a token budget, approval for sensitive tools, and tool errors returned as observations. The policy function stands in for a model call; here it is scripted so the code runs without an API.

from dataclasses import dataclass, field

@dataclass
class Action:
    tool: str | None          # None means "final answer"
    args: dict = field(default_factory=dict)
    text: str = ""

SENSITIVE = {"send_email", "delete_file", "make_payment"}

def run_agent(policy, tools, goal, max_steps=8, max_tokens=50_000,
              approve=lambda tool, args: False):
    history, used = [("goal", goal)], 0
    for step in range(max_steps):
        action, tokens = policy(history)          # one model call
        used += tokens
        if used > max_tokens:
            return "stopped: token budget exceeded", history
        if action.tool is None:
            return action.text, history
        if action.tool in SENSITIVE and not approve(action.tool, action.args):
            history.append(("observation", f"{action.tool} needs approval; queued"))
            continue
        try:
            obs = tools[action.tool](**action.args)
        except Exception as e:                    # errors become observations
            obs = f"error: {e}"
        history.append(("action", action.tool, action.args))
        history.append(("observation", obs))
    return "stopped: step limit reached", history

script = iter([Action("run_tests"), Action("read_file", {"path": "calc.py"}),
               Action(None, text="Bug: off-by-one in calc.py line 3.")])
policy = lambda history: (next(script), 1_200)
tools = {"run_tests": lambda: "1 failed: test_sum",
         "read_file": lambda path: f"<contents of {path}>"}
print(run_agent(policy, tools, "Find why the tests fail")[0])

The default approve refuses everything, so a sensitive action is queued rather than executed unless a real approval function is supplied: the safe default. In production, policy would call a model with the history and tool definitions, and every action and observation would also be written to a durable log.

Common pitfalls

• Building an agent for a workflow. If the steps are fixed, a pipeline is cheaper, faster and easier to test.
• Self-grading without evidence. Asking the model "are you done?" with no test or validator tends to produce premature success.
• Unbounded runs. No step, time or spend limit means one confused run can loop for hours.
• Vague tool results. Returning raw dumps or unclear errors makes every later decision worse and inflates cost.
• Judging from one demo. Agents are stochastic; measure success rate over many runs and many tasks before deployment.
• Approval fatigue. Asking for approval on every trivial action trains people to click "yes"; reserve approvals for consequential actions and show exactly what will happen.

In practice

• Use a fixed workflow when the steps are known; reserve agents for open-ended tasks.
• Give the agent the fewest, narrowest tools that work, with approvals on anything irreversible.
• Add external checks such as tests, validators and schemas so reflection has real evidence.
• Cap steps, time and cost per run, and log every action.
• Measure success rate on a set of realistic tasks before trusting an agent with real work.