Introduction to AI Agents

Suppose you are handed an AI agent and asked what it is able to do. Two questions come up almost immediately. First, where does it operate: what world does it perceive and affect? Second, what can it actually do inside that world? These questions are linked. The world an agent works in shapes the things it could possibly do, and the things it is equipped to do shape how much of that world it can reach. This article follows that link, then looks at how an agent works through a task one step at a time and why long chains of steps are risky.

An agent's environment is defined by its use case. The easiest way to find it is to ask, for each agent, what it is supposed to act upon. An agent built to play a game has that game as its environment. An agent that scrapes documents from the internet has the internet as its environment. A cooking robot works in a kitchen. A self-driving car works in the road system and the areas beside it.

Once the environment is fixed, it determines which tools an agent could potentially use. The environment acts as a boundary on the agent's options. A tool that makes sense in one environment may be meaningless in another, because the actions it offers have nothing to apply to there.

The relationship between environment and tools runs in both directions. Read it first from the environment side: the environment determines which tools are potentially usable. Then read it from the tool side: the tool inventory an agent carries restricts which environments it can actually work in. If a robot's only action is swimming, it is confined to a water environment, because on land it has nothing it can do. The tools fix the reachable world just as the world fixes the usable tools.

Tools are what expand an agent's set of actions. A model that only produces text has a small set of possible actions. Giving it tools adds to that set. Many generative AI applications people use every day are agents with access to tools, although many of those tools are simple. ChatGPT is one example: it can search the web, run Python code, and generate images. Each of these capabilities is an action that is unavailable to a model with no tools at all.

A coding agent called SWE-agent, built on top of GPT-4, shows both ideas together. Its environment is a computer with a terminal and a file system. Its set of actions includes navigating a repository, searching files, viewing files, and editing lines. The environment supplies the places where those actions apply, and the actions are what let the agent change that environment.

An agent is defined by its environment and the tools it can access. In an AI-powered agent, the AI acts as the planner. It analyzes the task it has been given, considers different solutions, and picks the most promising one. The planner, the tool inventory, and the environment work together as one system: the use case sets the environment, the tools determine which actions are available inside that environment, and the planner decides which actions to take and when the task is done.

The diagram shows the central idea of this article. The environment and the tool inventory constrain each other, and the planner works inside those limits. A planner cannot choose an action that the tool inventory does not contain, and it cannot usefully reach a part of the environment that no tool can touch.

An agent is typically given a task by a user. The agent does not simply return one answer. It processes the task together with feedback from its environment, plans a sequence of actions, and decides when the task is finished. To see this in action, take the RAG system with tabular sales data. It has three actions: generating a response, generating a SQL query, and executing a SQL query. Given the request to project sales revenue for a product over the next three months, the agent works through a sequence of moves in which each tool result feeds the next decision.

Trace the state of this run through the loop. The agent begins at the task and reasons about its next move. It acts by calling one of its tools. It observes the output that tool returned. Then it returns to reasoning, because the agent comes back to reasoning after every tool call. At the decision point, it judges whether the information is enough. If it is not, the loop repeats with a new plan. The second round of queries in the sales run exists only because the output of the first round was judged insufficient. The loop stops only when the agent judges the task complete and returns the result.

The sales run had seven reasoning-and-action moments. Each one is a place where the agent can go wrong: a query can be malformed, a result can be misread, or a plan can be poor. Because the agent needs many steps, its overall accuracy depends on how the individual steps combine, not only on how good any single step is. This is called the problem of compound mistakes.

The source gives a concrete case. If a model is 95% accurate per step, then over 10 steps the overall accuracy drops to about 60%, and over 100 steps it falls to about 0.6%. The pattern matches multiplying the 95% figure by itself once for each step: $0.95^{10} \approx 0.60$ and $0.95^{100} \approx 0.006$.

In the formula, p is the per-step accuracy and n is the number of steps. The table shows how quickly the trend bends downward. A small per-step error rate, repeated over many steps, adds up to a large chance that something has gone wrong somewhere along the way.

Compared with non-agent uses of a model, agents typically require more powerful models, and the source gives two reasons. The first is the compound-mistake effect just described. The second is that agents with access to tools can perform more impactful tasks, but any failure could carry more severe consequences. A text answer that is wrong can be ignored. An action that is wrong may have already changed something in the environment.

Cost works in the other direction too. A task that requires many steps takes time and money to run. The source argues that this cost can still be worthwhile, because autonomous agents can save a great deal of human time. Whether an agent is worth deploying depends on weighing that saving against the expense of running many steps and the damage a failure could cause.

Imagine asking a language model a question about your company's internal leave policy. The model was trained on a large body of text, but that training did not include your company's private handbook, and it certainly did not include last month's revision. Even if you paste the handbook into the prompt, the model can only read a limited amount of text at once, so a long document may not fit. Retrieval-augmented generation addresses this gap by changing what the model sees at the moment it answers, rather than changing the model itself.

Retrieval-augmented generation (RAG) retrieves relevant information from external memory first, then uses it to generate more accurate responses. The word order matters. Retrieval comes first, and generation depends on its output. The model is not asked to remember everything. It is handed the pieces of information most likely to be relevant to the question, and it writes its answer from those pieces. The external memory can be any store of documents that the system can search, which is why RAG lets a model draw on material that was never part of its training.

Retrieval quality is the step that decides what the model sees. Retriever quality determines how well a RAG system performs. If the retriever returns the wrong passages, the model writes its answer from the wrong material, however capable it is. The source contrasts two kinds of retriever: term-based and embedding-based retrievers trade lightness against potential effectiveness.

RAG and agents are closely related. The source describes the RAG pattern as a special case of an agent, one in which the retriever is a tool the model can use. A RAG system can be viewed as an agent whose tools are a text retriever, an image retriever, and a SQL executor. Looking at it this way makes RAG easier to understand: it is the agent idea narrowed to a single kind of tool, used for a single purpose, which is searching external memory.

The difference lies in who decides the sequence. A RAG system follows a fixed retrieve-then-generate pipeline. An agent chooses its own actions and judges when the task is finished. Both patterns are prompt-based, and both extend what a model can know at the moment it answers.

A natural instinct is to give an agent more tools. The source supports part of that instinct: the more tools a model is given, the more capabilities it has, which lets it solve more challenging tasks. The same source warns about the other side of the trade. The more automated an agent becomes, the more catastrophic its failures can be. Each added tool and each step taken without a person checking it widens the range of things that can go wrong.