"Agent" is one of the most overloaded terms in AI. It means everything from a chatbot to a research assistant to a fully autonomous coding tool. Before we can discuss architectures, we need a working definition. This lesson starts with what distinguishes an agent from a simple LLM call, then walks through the major architecture patterns and when to use each.

A Working Definition

An agent is a system where an LLM makes decisions about what to do next. The critical word is "decisions". A simple LLM call takes input and produces output in a single pass. An agent has a loop: observe state, think, take an action, observe the result, think again, take another action, and so on. The loop continues until the task is done or the agent decides to stop.

Three properties distinguish an agent from a simple LLM call:

1. Tool use: The LLM can take actions that affect the world outside its context window, call APIs, read files, search the web, run code.
2. Multi-step reasoning: The task requires more than one LLM call. The agent breaks the task into steps and executes them in sequence.
3. Autonomy: The agent decides what to do next based on the current state. The sequence of actions is not pre-planned; it emerges from the agent's decisions.

A system with tool use but no multi-step reasoning is not really an agent. It is a tool-augmented assistant. A system with multi-step reasoning but no tool use is a chain-of-thought prompt, not an agent. A system with both tool use and multi-step reasoning but no autonomy (every decision is made by the programmer) is a workflow. An agent has all three.

The Agent Loop

The simplest agent architecture is a loop of three operations:

1. Observe: Gather information about the current state. This includes the user's original request, results from previous actions, and any external state the agent has access to.
2. Think: Decide what to do next. The LLM reasons about the state and picks the next action. This might be calling a tool, responding to the user, or concluding the task.
3. Act: Execute the chosen action. If it is a tool call, run the tool and get the result. If it is a response, return it to the user. The result becomes part of the state for the next iteration.

This loop runs until a terminal condition is met: the task is done, the agent gives up, or a budget (time, iterations, cost) is exhausted.

The agent loop is surprisingly powerful. A lot of seemingly complex agent architectures are just variations on this basic loop with different ways of managing state, different thinking strategies, or different terminal conditions.

Why Agents Matter

Agents let you tackle problems that are too complex for a single LLM call. A simple call can answer factual questions, summarize text, or generate code snippets. An agent can research a topic, debug a multi-file codebase, or execute a multi-step business process. The difference is the ability to decompose a problem, take intermediate actions, and adapt based on results.

Agents also enable a new programming paradigm: instead of specifying every step of a process in code, you describe the goal and let the agent figure out the steps. This trades predictability for flexibility. Workflow systems (where every step is pre-defined) are more predictable but cannot handle variations. Agents are less predictable but can handle tasks the programmer never anticipated.

The Reliability Problem

The fundamental challenge with agents is reliability. Every LLM call has a non-zero failure rate. An agent that makes 10 LLM calls to complete a task will fail at a much higher rate than a single-call system, even if each individual call is highly reliable. This compounds quickly. At 95% per-call reliability and 10 calls, task success drops to 60%.

Agent architectures are largely designed to address this compound reliability problem. Different architectures make different trade-offs between flexibility and reliability. Understanding these trade-offs is the main subject of this lesson.