What is an agent?

An agent is a program that hands a language model a goal and a set of tools, then lets the model decide which tool to call next - again and again - until the goal is done. Three parts, and only three: a model that decides, tools that act, and a loop that keeps going.

The word gets attached to a lot of products, so it pays to be strict about it. A model on its own is not an agent; it produces text and stops. A tool on its own is not an agent; it is a function waiting to be called. The agent is the arrangement: the model chooses, a tool runs, the result comes back to the model, and the model chooses again. Take any one of the three away and you have something else - a chatbot, a script, or a library.

Model, tools, loop. Everything else is packaging.- the three-word definition

If you have used a chat assistant, you have already met the first part. What makes an agent feel different is the other two: it can do things (open a file, run a query, send a request), and it keeps doing them without you typing the next instruction.

Chatbot, workflow, agent

Three different things get called "AI" inside a product, and they are not the same thing. The question that separates them is simple: who decides what happens next - your code, or the model?

Code decides Model decides
Tier 1

Chatbot

You ask, it answers, the turn ends. There is no next step to decide. The model is the whole product, and it never touches anything outside the conversation.

Tier 2

Workflow

Your code lays out the steps in advance - fetch, summarise, classify, file - and calls the model to do one step at a time. The model fills in blanks; the order is fixed.

Tier 3

Agent

You state the goal. The model reads the situation, picks a tool, looks at what came back, and picks the next one. The order is decided at run time, by the model.

The middle tier deserves attention, because most production "AI features" are workflows, and that is a fine thing to be. A workflow is predictable, cheap, and easy to test, because the path through it never changes. You reach for an agent when you cannot write the path down in advance - when the next step depends on what the previous one turned up. Debugging, research, and multi-file code changes are like that. Summarising a support ticket is not.

Anthropic's guide to building agents draws exactly this line - workflows follow code paths you wrote ahead of time, agents direct their own - and it is the single most useful distinction in the vocabulary. When someone says "we built an agent", the first question worth asking is which tier they mean.

The three parts

Each part has one job, and none of them can do the others' job.

Model

The part that decides

A large language model reads the goal, the tools it has, and everything that has happened so far, then answers with one of two things: a request to call a tool, or a final answer. It never runs anything itself.

Tools

The part that acts

Ordinary functions your code exposes: read a file, search, query a database, call an API. Each has a name, a description, and a schema for its inputs. The model picks a tool by reading its description.

Loop

The part that repeats

A small piece of code, usually called the harness, that sends the conversation to the model, runs whichever tool it asked for, appends the result, and sends the whole thing back. It stops when the model stops asking.

Two of the three are yours to write. The model is rented from a provider - Claude, a GPT-class or Gemini-class model, or an open-weight model you host - while the tools and the loop are code you own, and they are where most of the design decisions live. Which tools to expose, how to describe them, what the model may do without asking, when to cut the loop off: none of that is in the model. Increasingly the tools arrive through Model Context Protocol, a standard for plugging tools into an agent that did not ship with them, but the division of labour stays the same.

One task, end to end

Here is a small agent doing a small job. It has three tools - search_files, read_file, and create_issue. The goal comes from a person; everything after that is the model's call.

Output one run · eight turns
goal Find every TODO in src/ and open one GitHub issue per TODO. turn 1 model → search_files({ pattern: "TODO", dir: "src/" }) tool → 3 matches: auth.js:41, cache.js:12, cache.js:88 turn 2 model → read_file({ path: "src/auth.js", from: 35, to: 48 }) tool → "// TODO: rotate refresh tokens after 30 days" turn 3 model → create_issue({ title: "Rotate refresh tokens after 30 days", body: "src/auth.js:41 - the refresh token ..." }) tool → created #212 turn 4-7 the same read-then-create pair for cache.js:12 and cache.js:88 tool → created #213, created #214 turn 8 model → (no tool call) "Opened #212, #213 and #214. The note at cache.js:88 reads like a stale comment rather than a task - I opened it anyway and said so."

Notice what the person did not do. Nobody told the agent to search first, or to read the surrounding lines before choosing an issue title, or that three matches meant three issues. The model worked that out from the goal and the tool descriptions. Notice also the final turn: the model did not request a tool, so the loop ended and the text became the answer. That is the whole stopping rule.

And notice the hedge about cache.js:88. A good agent reports what it was unsure about instead of quietly deciding. That behaviour is not free - it comes from the instructions you give the model and from tool results being fed back honestly, errors included.

The loop is smaller than you think

People expect the agent part to be the complicated part. It is not. Stripped of logging, retries, and permissions, the loop that ran the example above fits on one screen. Below, callModel wraps whichever model API you use and returns the model's reply, and runTool is a switch over the functions you expose.

JavaScript the harness, minus everything optional
const messages = [{ role: "user", content: goal }]; while (true) { const reply = await callModel(messages, tools); // one model turn messages.push(reply); if (!reply.toolCall) break; // no tool asked for: the agent is done const result = await runTool(reply.toolCall); // your code does the acting messages.push({ role: "tool", content: result }); // and the model sees the outcome } return messages.at(-1).content; // the final answer

Everything that makes a real agent trustworthy is added around this loop, not inside the model: a cap on how many turns it may take, a list of tools that need a human's approval before they run, a budget in tokens or dollars, a log of every call. What the model actually sees on each pass - and why it fills up far faster than a chat - is the subject of What's in an agent's context? What the loop looks like as real API calls, stop reasons and tool results included, is in What is the Claude Platform?

What an agent is not

Most confusion about agents comes from one of five mix-ups.

  • Not the model. Claude, GPT and Gemini are models. Claude Code is an agent built on one of them. The model is the deciding part; the agent is the whole arrangement around it.
  • Not a chatbot with a personality. Giving an assistant a name and a tone does not make it an agent. If it cannot call a tool and act on the result, it is a chatbot, however it talks.
  • Not autonomous by default. How much an agent does before checking in is a setting, not a property. The same agent can be run so it asks before every write, or so it runs for an hour unattended. Autonomy is a dial you set, and the safe default is low.
  • Not new to computing. "Agent" has meant a program acting on someone's behalf for decades - in reinforcement learning, in multi-agent simulations, in the user-agent string every browser sends. What is new is a model general enough to be the deciding part for open-ended work.
  • Not always the right tool. An agent is slower, costlier and less predictable than a workflow doing the same job. If you can write the steps down, write them down. Reach for the agent when you cannot - and know what it costs before it runs at scale.

Where to go next

This article defined the thing. The rest of the cluster is about living with it. What is Agentic AI? steps back to the system view - autonomy tiers, where agents earn their keep in real work, and why the field's hard problems are mostly about the loop. Inside an AI agent takes that loop apart stage by stage - state, planning, tool selection, observation, recovery, termination, approval. What's in an agent's context? opens the window the model reads on every turn. Why agents fail and How to evaluate an agent are the two to read before you let one run unattended.

And if you would rather use one than build one, What is Claude Code? is an agent you can run in a terminal in a few minutes - every part described above, visible as it works.

References