What Is an Agent

An agent is a model that calls tools in a loop until a goal is met. See one work, learn how it differs from a fixed workflow, and when not to build one.

13 minLesson 1 of 6
On this page
  1. The idea: a model with tools, in a loop
  2. Watch one work
  3. Who decides the next step
  4. When not to use an agent
  5. Try it yourself
  6. Common mistakes
  7. Check yourself
  8. What to practise next

Last night's backup failed, and you ask an AI assistant why. A plain chat model can only guess: "Backups often fail because of full disks, expired credentials or network problems." All true, and no help to you.

Now picture a colleague with access to the server. They open the backup log and see "no space left on device". So they check how full the disk is. It is 98% full, so they look at what is taking the space, and find an old snapshot folder nobody uses. Each step depended on what the previous step showed. Nobody could have written those steps down in advance.

An agent is a model set up to work like that colleague: it looks, decides what to do next, does it, and looks again, until the job is done.

The idea: a model with tools, in a loop

You already know from Tools and MCP that a model can ask the app to run a tool and read the result. An agent is that same mechanism with the model in charge of the next step. It has four parts:

  • A goal. What you want, and ideally how to tell when it is done: "Find out why the backup failed. Do not delete anything."
  • Tools. The actions it can request: read a log, check disk usage, list a folder.
  • A loop. The app calls the model, runs whatever tool it asks for, adds the result to the context, and calls the model again.
  • A stop. The loop ends when the model gives a final answer, or when the app's limits say so (too many steps, too much time).

The important word is decides. In ordinary software, you write the sequence of steps. In an agent, the model picks each step at run time, based on what it has seen so far.

Watch one work

Here is the backup investigation as an agent would run it. The agent has three read-only tools: readLog, diskUsage and listDir. The tool results are illustrative.

An agent finds out why the backup failedUse the arrows or ← → keys
history = [goal]loop:  step = model(history)  if step is an answer: return step  result = run(step.tool, step.input)  history += [step, result]
  1. history
    whotext
    goalWhy did the backup fail? Delete nothing.
    model calls
    0
    tool runs
    0

    1The app starts the history with the goal. The model also sees short descriptions of the three tools. No tool has run yet.

  2. history
    whotext
    goalWhy did the backup fail? Delete nothing.
    modelreadLog("backup", last 20 lines)
    model calls
    1
    tool runs
    0

    2The model has no facts yet, so the sensible first move is the log. It asks for readLog instead of answering.

  3. history
    whotext
    goalWhy did the backup fail? Delete nothing.
    modelreadLog("backup", last 20 lines)
    toolERROR: no space left on /mnt/backup
    model calls
    1
    tool runs
    1

    3The app runs the tool and appends the result. The log names the problem: the backup disk is full.

  4. history
    whotext
    goalWhy did the backup fail? Delete nothing.
    modelreadLog("backup", last 20 lines)
    toolERROR: no space left on /mnt/backup
    modeldiskUsage("/mnt/backup")
    model calls
    2
    tool runs
    1

    4This request only makes sense because of the last result. The model wants to know how full the disk is, so it asks for diskUsage.

  5. history
    whotext
    goalWhy did the backup fail? Delete nothing.
    modelreadLog("backup", last 20 lines)
    toolERROR: no space left on /mnt/backup
    modeldiskUsage("/mnt/backup")
    tool490 of 500 GB used (98%)
    model calls
    2
    tool runs
    2

    5The app runs it and appends the answer: 98% full.

  6. history
    whotext
    goalWhy did the backup fail? Delete nothing.
    modelreadLog("backup", last 20 lines)
    toolERROR: no space left on /mnt/backup
    modeldiskUsage("/mnt/backup")
    tool490 of 500 GB used (98%)
    modellistDir("/mnt/backup", by size)
    model calls
    3
    tool runs
    2

    6Next question: what is taking the space? The model asks for listDir, sorted by size.

  7. history
    whotext
    goalWhy did the backup fail? Delete nothing.
    modelreadLog("backup", last 20 lines)
    toolERROR: no space left on /mnt/backup
    modeldiskUsage("/mnt/backup")
    tool490 of 500 GB used (98%)
    modellistDir("/mnt/backup", by size)
    toolsnapshots-old 310 GB, 14 months old; daily 170 GB; logs 10 GB
    model calls
    3
    tool runs
    3

    7One folder holds 310 of the 490 GB and has not changed in 14 months. 310 + 170 + 10 = 490, so nothing else is hiding.

  8. history
    whotext
    goalWhy did the backup fail? Delete nothing.
    modelreadLog("backup", last 20 lines)
    toolERROR: no space left on /mnt/backup
    modeldiskUsage("/mnt/backup")
    tool490 of 500 GB used (98%)
    modellistDir("/mnt/backup", by size)
    toolsnapshots-old 310 GB, 14 months old; daily 170 GB; logs 10 GB
    modelDisk full. snapshots-old (310 GB) looks unused. Archive it?
    model calls
    4
    tool runs
    3

    8The model has enough to explain the failure, so it writes an answer instead of a tool request. The loop ends. It suggests a fix but, as told, deletes nothing.

  9. history
    whotext
    goalWhy did the backup fail? Delete nothing.
    modelreadLog("backup", last 20 lines)
    toolERROR: no space left on /mnt/backup
    modeldiskUsage("/mnt/backup")
    tool490 of 500 GB used (98%)
    modellistDir("/mnt/backup", by size)
    toolsnapshots-old 310 GB, 14 months old; daily 170 GB; logs 10 GB
    modelDisk full. snapshots-old (310 GB) looks unused. Archive it?
    model calls
    4
    tool runs
    3

    9Four model calls and three tool runs. None of the three tool calls was planned at the start: each one was chosen from the result before it.

1 / 9

Notice what the app did: almost nothing clever. It ran the loop, ran the tools and kept the history. The judgement, "the log says disk full, so check the disk next", came from the model. The Agent Loop turns this pseudocode into real code.

Who decides the next step

"Agent" gets used for almost anything with AI in it. A more useful way to sort systems is by who decides the next step.

Single call model answer one step, no tools Workflow step 1 step 2 step 3 your code fixes the order Agent model tools the model picks each next step
Three ways to build with a model. Moving right gives the model more freedom, and costs more predictability.
  • Single call. One prompt, one answer. "Rewrite this paragraph more simply."
  • Workflow. Several model calls, but your code fixes the order. "Summarize each support ticket, then classify it, then draft a reply." The model does each step; it never chooses what comes next.
  • Agent. The model chooses the next step and when to stop. You set the goal, the tools and the limits.

Workflows are underrated. You know every path in advance, so they are cheaper, faster and easier to test and debug. Many useful AI features are single calls or workflows.

When not to use an agent

Freedom has a price. Each extra step is another model call, so agents are slower and cost more. They can take a different path on each run, which makes them harder to test.

Errors also compound. Say each step is right 95% of the time and one wrong step spoils the run. Then a ten-step run is fully right only about 60% of the time, because 0.9510 ≈ 0.60. Real agents sometimes notice a bad result and correct course, so the true number can be better. But the direction holds: more steps, more chances to go wrong.

So use the simplest thing that works:

  1. If one good prompt does it, use a single call.
  2. If you can write the steps down in advance, write a workflow.
  3. Reach for an agent only when the steps depend on what you find along the way, and when a wrong turn can be noticed and undone.

Debugging, research across many sources, and working through an unfamiliar codebase fit that last description. Sending the same weekly report does not.

Try it yourself

Try it: Single call, workflow or agent

For each task, pick the simplest approach that would work: single call, workflow or agent. Write one line of reasoning for each.

  1. Translate a product description into Spanish.
  2. Every morning, take new customer reviews, tag each one by topic, and post a count per topic to the team chat.
  3. Find out why the checkout page got slower this week, using logs, recent code changes and metrics.
  4. Turn a meeting transcript into a list of action items with owners.
Show a sample answer
  1. Single call. One input, one output, no lookups.
  2. Workflow. The steps are the same every day: fetch, tag each review, count, post. Code can run them in order and the model only does the tagging.
  3. Agent. You cannot know in advance whether the answer is in the logs, a code change or a database. Each finding decides where to look next.
  4. Single call. It looks like a big job, but the whole transcript fits in one prompt and no tools are needed. Adding an agent would only add cost and ways to fail.

The pattern: an agent earns its cost only when the path is unknown until you start walking it.

Common mistakes

Check yourself

Quick check

What makes a system an agent rather than a workflow?

Each step of an agent is right 90% of the time. Roughly how often is a 5-step run right at every step?

Every Friday you want last week's sales pulled from a database, summarized and emailed to the team. What should you build?

What to practise next

An agent is only as good as its tools. Continue with Tool Use, which covers how to design tools an agent can use well, then The Agent Loop to write the loop yourself.