What Are AI Agents? — Bohdan Danyliuk

From answering to doing

A chatbot answers questions. You type, it replies, the conversation ends. An AI agent does something different: it works toward a goal, and it can act on the world to get there — search the web, read files, call APIs, run code — deciding for itself which steps to take and in what order.

Why should you care? Because this is the difference between a tool that talks about your work and a tool that does part of it. Coding assistants that fix the failing test, support bots that actually issue the refund, research runs that come back with a cited report — all of those are agents. And the idea behind them is small enough to hold in your head in two minutes.

If you want one picture: a head chef with a team of helpers. The chef never chops an onion. She looks at the order, decides what is needed next, calls out “dice two onions”, the helper does it and puts the result on the counter, she looks at the result and calls the next thing. The chef is the model. The helpers are tools. The counter is the context. Repeat until the dish goes out.

The core idea fits in one sentence: take a model, give it tools, and put it in a loop — think, act, observe, repeat. The rest of this article says that one loop three different ways, until it is obvious.

Nothing “runs” — every step is one call

This is where beginners get lost, so let us be blunt about it.

There is no process running inside the model. No code executes there, no clock ticks, no job is scheduled, and nothing is waiting in the background. A language model is a box that takes text in and puts text out. One call, one reply. That is the entire interface — there is no second one.

So how does an agent get anything done? Your code calls that box over and over:

Your code builds a message list — the goal, the rules, the menu of tools — and calls the model once. It gets one reply back.
If that reply says “run search with these arguments”, then your code runs the search. The model has not done anything in the world; it has written a request.
Your code pastes the result back into the message list as one more message, and calls the model again — sending the whole conversation, now one message longer.
Repeat. Every turn the model re-reads everything from the beginning, because it remembers nothing between calls. The conversation is its memory.

And the loop ends because your code decides it ends: usually because the model’s reply contained no tool request and is just the answer. The model does not stop itself — it merely stops asking. A careful loop also stops after a step limit or a token budget, so a confused agent cannot spin in circles forever.

In one sentence: the model writes, your code acts, the model reads what came back, and your code decides when to stop.

Click through one real loop and watch where the decisions happen:

think → act → observe, repeated
→→→→→
1. Goal
The user asks for something that needs real work, not just text.
"Find the three best-rated projectors under 600 dollars and compare them in a table."
out› user request
1/6

Notice that the step after the first result is the one that makes it an agent. A chatbot would have answered after the first call. This one looked at what came back and changed its plan.

The same loop, as the messages actually look

Below is that exact loop as the message list your code keeps sending. Step through it and watch the token count in the corner grow — the model re-reads everything, every single time:

three calls, one growing conversation
press the button below to send the first message
sent to the modelnothing yet — every message is sent in full

Three things to read off that:

The second call re-sent everything. The model did not “continue” — it was called again with a longer list. This is why a long task gets expensive and why the size of the context window matters.
Tool results are just text. JSON, a number, an error message — to the model it is all more text to read, no different from your message.
One number was missing, and the loop noticed. That recovery is the entire value of the pattern.

Two more things people trip over. First, the model does not run the tools — it asks for them, and your code does the running. Second, there is no fixed plan: each step exists because the previous one came back with new information. The loop is a reaction to what it just saw, not a script.

Agent vs chatbot

The difference is not the model — it is who drives the conversation:

Chatbot: one request, one response. The human decides every next step. Great for explanation, drafting, and brainstorming.
Agent: many requests, driven by the model itself, until a goal is reached. Great for tasks with multiple steps where you care about the result, not the process.

A useful test: if the task can be finished in one reply, use a chatbot. If it needs “look this up, then based on that, do that” — repeated several times — you want an agent. Coding assistants like Claude Code or Cursor in agent mode are exactly this: a model that reads files, edits them, runs tests, and keeps going until the build passes.

Classic use cases

You will meet the same shapes again and again:

Coding agents — read a repository, implement a feature, run tests, iterate on failures. Currently the most commercially successful agent type.
Research and summarization — search, read a dozen sources, synthesize into a report with citations.
Customer support — look up the order in a database, check the shipping API, issue a refund via an internal tool — all inside one conversation.
Data work — take a CSV, write and run Python to clean it, chart the result, describe what it shows.
Ops and automation — watch a dashboard, triage alerts, draft a fix, open a pull request for a human to approve.

Why only now?

The idea of an agent is old — researchers wrote papers about tool-using loops years before they worked well. Three things changed:

Tool calling became a first-class API feature. Models are now trained to emit a structured tool call (a function name plus JSON arguments) instead of improvising text and hoping your parser copes. This is the single biggest enabler.
Models got good enough. An agent makes many small decisions in a row. If each step is 90 percent reliable, a ten-step task succeeds only about a third of the time. Modern models push per-step reliability high enough that multi-step tasks actually complete.
Intelligence got cheap. An agent might make 20 or 50 model calls for one task, each carrying a growing conversation. At yesterday’s prices that was uneconomical; at today’s it is a rounding error for most businesses.

The honest trade-off

Agents trade reliability for autonomy. A chatbot cannot break anything, because it only produces text. An agent calls real tools, so real mistakes are possible: a wrong API call, a deleted file, a bad purchase. That is why serious agent systems use permissions, allowlists, and human approval for anything destructive — the model proposes, the code disposes.

Check yourself

Who actually runs the tools in an agent loop?

What makes an agent different from a chatbot?

A ten-step task, each step 90 percent reliable. Roughly how often does the whole task succeed?

Who decides that the loop is finished?

On the second call of a loop, what does the model receive?

Where this leaves you

You now know what an agent is: a model called again and again, each time with the growing conversation plus whatever the tools returned — where your code does the acting and decides when to stop.

For the deep version of this loop — reflection, memory, and the honest list of cases where an agent is overkill — read AI Agents 101, in depth. Three more stops later in this path: agent SDKs, which wrap this loop with retries, tracing and a tool registry; multi-agent systems, which is what happens when one loop is not enough; and MCP, the open standard for connecting tools to models.