What an AI agent is

An AI agent is a language model placed in a loop where it can take actions, see the results of those actions, and decide what to do next, which is the shift that turns a text generator into something that gets work done rather than just describing how work might be done.

Start with what a model does on its own

A language model, by itself, does one thing: it reads some text and produces more text. You give it a prompt, it returns an answer, and that is the end of the interaction. It is, underneath, a very good predictor of what words come next given the words so far. That single capability is enough to write a paragraph, translate a sentence, or explain an idea. But notice what it cannot do. It cannot look anything up. It cannot check whether its answer is right. It cannot run the code it just wrote to see if it works. It produces one block of text and stops.

Think of it as a brilliant person locked in a room with no windows, no phone, and no reference books, who can only slide answers under the door. Ask a question and a thoughtful answer comes back, drawn entirely from memory. If the answer depends on something they cannot know from inside the room, today’s date, the contents of a file, whether a program actually runs, they can only guess, and their guess will sound just as assured as their knowledge. The model on its own is that person: capable, articulate, and completely cut off from the world it is reasoning about.

Most real work is not a single answer. It is a sequence of steps where each step depends on what the last one turned up. You look something up, that changes what you do next, you try a thing, it fails, you adjust. A person who could only ever give one answer and never act on the world would be of limited use for that kind of work, no matter how smart. The question an agent answers is: what if we let the model out of the room?

The loop is the whole idea

An agent is what you get when you stop treating the model’s output as a final answer and start treating it as a decision about what to do next. You wrap the model in a loop. Each time around, the model looks at the situation, decides on an action, the action is carried out, and the result is fed back in for the next time around. The model keeps going until the job is done. That cycle has a simple name: observe, think, act.

1. Observe: the model is shown the current state of things, including the goal and whatever the previous actions returned.
2. Think: the model reasons about what to do next given what it now knows.
3. Act: the model chooses an action, and that action is actually carried out in the world.
4. The result of the action becomes part of the next observation, and the loop runs again.

That is the entire mechanism, and its plainness hides how much it changes. The model no longer has to know everything up front. It can find out. It writes a line of code, runs it, sees the error, and fixes the error on the next pass. It reads a file, learns something it did not know, and changes its plan. It is no longer sliding a single answer under the door. It is stepping out, doing something, seeing what happened, and stepping again. The loop turns a one-shot predictor into something that can pursue a goal over many steps.

Tools are the hands

For the loop to matter, the act step has to reach beyond producing text. The model needs a way to actually do things: read a file, search a codebase, run a command, call a service, look something up. Those capabilities are called tools, and they are the agent’s hands. The model itself still only produces text, but now some of that text is a request to use a tool, and the surrounding system carries out the request and hands back the result.

The mechanics of that, how a model asks to use a tool and receives an answer, are the subject of tool use and function calling, and the shared standard that lets a model reach many outside tools through one common interface is the subject of the Model Context Protocol. For now, hold the picture: the model is the mind that decides, and tools are the hands that touch the world. A mind with no hands can only think out loud. Hands with no mind do nothing on purpose. The agent is the two together in a loop.

Consider how this plays out in a small, concrete task: fix a failing test in a project.

1. The model runs the tests with a tool and observes that one fails, with a specific error.
2. It reads the file the error points to, using a read tool, and thinks about the cause.
3. It edits the file with an edit tool to fix what it found.
4. It runs the tests again, observes that they now pass, and stops.

No step here required the model to be right on the first try. The loop absorbs being wrong. A bad edit shows up as a still-failing test, which the model sees and corrects. This tolerance for error, built from observing real results, is a large part of why agents can handle messy, multi-step work that a single answer never could.

Why a loop with tools is different in kind

It is tempting to think of an agent as just a model that runs a few more times. The difference is deeper than repetition. A model answering once is bounded by what it already knows. An agent is bounded by what it can find out and do, which is a far larger space. The loop lets capability compound across steps: each action changes what the model knows, and better knowledge leads to better next actions.

A model answers from what it already knows. An agent can go find out, act, and adjust. That is a difference in kind, not in degree.

This is why an agent can do things that feel qualitatively beyond a single response: work through a task with many unknowns, recover from its own mistakes, and hold a goal across a long chain of steps. It is also why agents can surprise you, in both directions. Because they act and observe, they can solve problems the author never explicitly scripted. And because they act, they can also do damage a mere text answer never could. The same loop that lets an agent fix a test lets it delete the wrong file. Autonomy cuts both ways, and pretending otherwise is how people get hurt.

Autonomy and its risks

An agent acts on the world, and actions have consequences that text does not. A single wrong answer is a wrong answer. A single wrong action can send an email, overwrite a file, or spend money, and once taken it may not be undoable. So the freedom that makes an agent useful is exactly the thing that makes it something to handle with care. The more actions you let an agent take without a human checking, the more it can accomplish and the more it can break.

There is also the matter of trust in what an agent is told to do. An agent reads text from the world as part of observing, and text can carry instructions. A well-designed agent treats what it reads as information, not as commands, so that a stray line in a document or a web page cannot quietly redirect it. This is a real concern precisely because the agent acts. A text generator that gets fooled produces a bad paragraph. An agent that gets fooled can take a bad action. Autonomy raises the stakes on every weakness the underlying model already had.

Where agents fail

Agents fail in characteristic ways, and knowing them is the difference between using one well and being burned by it. The first is compounding error. Because each step feeds the next, a small mistake early can grow. The model misreads one result, acts on the misreading, observes a confusing new state, misreads that too, and drifts further from the goal with each pass. A single answer cannot spiral like this, because it never has a second step. A loop can, and the longer the loop runs unattended, the more room there is for drift.

The second is bad context. An agent’s decisions are only as good as the information it observes. If the material it reads to make a decision is incomplete, stale, or simply the wrong material, the model reasons carefully over the wrong facts and acts confidently on a mistaken picture. The model is not broken in this case. It is being fed a bad view of the world and behaving exactly as a careful reasoner would given that view. Garbage going in becomes confident wrong action coming out.

An agent is only as good as what it can observe. Feed it the wrong context and it will reason flawlessly toward the wrong action.

These two failures compound each other. Bad context leads to a bad action, the bad action produces a confusing result, and the confusing result becomes worse context for the next step. The way out is not a smarter model alone. It is giving the agent good tools and, above all, good information to observe, so that each pass through the loop starts from an accurate picture rather than a misleading one.

Quality of the agent is quality of its information

Put the pieces together and a practical truth appears. An agent is a model, a loop, and a set of tools, and of those three the model is the part you are least able to change day to day. What you can change is the tools it has and, most of all, the quality of the information those tools bring back. An agent with a strong model but a poor view of the world will act confidently and wrongly. An agent with the same model but an accurate, relevant view of the world will act well, because every observe step starts from truth.

This matters especially when the world in question is complicated. Take a coding agent working in a large codebase. Its actions, edit this, change that, are only as safe as its understanding of how the code connects. If it cannot see that a function it is about to change is used in a dozen other places, it will change it and break them, not out of carelessness but out of blindness. The fix is not a better model. It is a better observation: a way for the agent to see the real structure of the code before it acts. That is why so much of the effort around useful agents goes into what they can reach and how good that information is.

This idea, that an agent lives or dies by the quality of what it can observe, is the thread that connects agents to almost everything else. It is why agents reason and plan more carefully when they can, which is the subject of reasoning and planning. It is why agents that write software need accurate access to the code they are changing, which is the subject of agentic coding. And it is why the way an agent reaches its tools and its information, the common interface that lets it connect to the outside world, matters so much, which is the subject of the Model Context Protocol. The loop is the engine. The information it runs on decides where it goes.