An AI agent is a language model that can take actions — call an API, run a search, edit a file, execute code — and then keep going, using what came back to decide what to do next, until a task is finished or it gives up.
That last part is the whole thing. A chatbot answers. An agent loops.
Everything else people say about agents is either a consequence of that loop or marketing. (The idea long predates the current wave — see intelligent agent for the older, broader definition.)
The difference in one comparison
Ask a chatbot to fix a failing test and you get a suggestion. You run it. It does not work. You paste the new error. You get another suggestion. You are the loop.
Ask an agent and it runs the test, reads the actual error, edits the file, runs the test again, sees it still failing, tries something else, and reports back when it passes or when it has run out of ideas.
Same model, often literally the same weights. The difference is that something is feeding the results of its actions back to it and letting it continue.
What is actually in the box
Four parts. None of them are exotic.
A model that produces text — the reasoning and the decisions.
Tools, which are just functions the model can request. The model does not “use” a tool in any magical sense: it emits something like call read_file with path src/auth.py, your code runs that function and passes the result back as text. A tool is a described function plus permission to call it.
A loop that runs: model produces output → if it requested a tool, run it → feed the result back → repeat. The loop needs a stopping condition, which is usually “the model says it’s done”, a step limit, or an error.
Context — the accumulating record of what has been tried and what came back. This is the agent’s entire working memory, and it is the source of most practical limits.
That is it. You can write a working agent loop in about fifty lines. The engineering difficulty is not in building the loop; it is in everything that happens when the loop runs for a while.
Why the loop is hard
Errors compound
A chatbot that is 95% reliable per response is a good chatbot. An agent that is 95% reliable per step and takes twenty steps finishes correctly about 36% of the time, if the errors are independent.
They usually are not independent, which cuts both ways. A wrong early decision poisons everything after it — the agent is now reasoning confidently about a file it misread three steps ago. But good agents also recover, because seeing an error message is information the chatbot never gets.
This is why step count matters more than model quality for reliability. A five-step agent is a different risk category from a fifty-step one.
Context fills up
Every action and every result goes into the context. Read three large files and a substantial chunk of the context window is gone before any real work starts.
When it fills, something has to be dropped or summarised — and now the agent is working from a lossy summary of its own recent history, with all the problems that come with reconstruction rather than reading.
It cannot tell “failed” from “finished”
This is the failure that surprises people. An agent that has been going for thirty steps will often report success. It has produced a summary of what it did, and that summary is generated by the same process that generates everything else — it is a plausible account, not an inspection.
Agents will report a fixed bug that is not fixed, a deployed service that did not deploy, a completed task where step four silently failed. The summary is downstream of the work, not evidence about it.
Actions have consequences
A wrong sentence is a wrong sentence. A wrong DELETE is a different category of event. The moment an agent can act on real systems, every reliability problem becomes an operational one.
What they are genuinely good at
The pattern that works: tasks with fast, honest feedback, where the agent can tell whether it succeeded without asking a person.
- Coding. The best case by a distance, because tests and compilers are ruthless, immediate verdicts. The agent cannot fool a failing test.
- Research across many sources. Searching, reading, following leads. Verification is weaker here, so check the citations yourself.
- Data wrangling. Fetch, transform, validate, report. The validation step is what makes it work.
- Multi-step retrieval. Questions needing four lookups and a synthesis.
- Routine ops with a check at the end. Provided a human sees the diff before it lands.
And what they are bad at: anything where success is a matter of taste, anything where the feedback arrives days later, anything where a wrong action is expensive to undo, and anything requiring knowledge that exists only in someone’s head and not in any system the agent can read.
The vocabulary, decoded
Tool use / function calling — the model requesting that your code run a function. The foundation of all of this.
MCP (Model Context Protocol) — a standard way to describe tools to models, so a tool built once works across different agents instead of being wired bespoke into each. Plumbing, but genuinely useful plumbing.
Multi-agent — several agent loops, often with different instructions, passing work between them. Sometimes this genuinely helps, particularly for separating “do the work” from “check the work”. It also multiplies the cost and adds a new failure mode where agents confidently hand each other wrong information. Try one agent first.
Autonomy levels — how far it runs before a person looks. This is the dial that actually matters, and it should be set by how expensive a mistake is, not by how impressive it looks.
Human in the loop — a person approves consequential actions. Not a failure of the technology; usually the thing that makes it deployable at all.
If you are thinking about using one
Start with something verifiable. If you cannot describe how you would check the output, you cannot deploy an agent against it.
Bound the blast radius before the capability. Read-only first. Scoped credentials. A staging environment. The order matters: capability added before boundaries is how the interesting incidents happen.
Cap the steps. An agent that stops after fifteen steps and says it is stuck is more useful than one that runs for two hundred and reports triumphant success.
Log every action. When it does something strange — it will — you need the trace of what it actually did, not its account of what it did.
Check the work, not the summary. The summary is the least reliable output in the system.
Ask whether you need the loop. A great deal of what gets built as an agent is a script with a model in one step. That is cheaper, faster, and dramatically easier to debug. Use an agent when the next action genuinely depends on the last result — that is the only thing the loop buys you.
The thing worth remembering
An agent is a model in a loop with tools and a stopping condition. Everything impressive about them comes from that loop, and so does everything that goes wrong.
Judge one by the same question every time: how would I know if this failed? If there is a fast, honest answer, agents work well. If there isn’t, you have not built an agent — you have built something that will tell you it succeeded.