What is an AI agent? (And why it isn’t a chatbot)

What is an AI agent, stripped to one sentence

Most definitions of an agent list capabilities. Reasoning, planning, tool use, memory. Those are components, and a system can have all four and still not be an agent.

Ownership is the test. An agent is given an outcome rather than an instruction, and it keeps working until the outcome is reached or it decides a human has to see it. Nobody stands over it choosing the next move. If a person has to say “now do the next step”, you have a tool with a good interface.

That distinction is commercial, not academic. A tool saves a person minutes per use. An agent takes a recurring job off the org chart and reports on it. You buy them for different reasons and you govern them completely differently.

The loop underneath the word

Ownership is implemented as a loop. Four moves, repeated until a stopping condition fires:

1. Perceive. Read the current state of the world: the ticket queue, the inbox, the failed build, the invoice that would not match. Not a prompt someone typed, but a state it went looking for. 2. Decide. Choose the next action from a declared set. This is the step people call reasoning, and it is the least interesting part of the engineering. 3. Act. Call a tool that changes something. Write the field, post the comment, open the pull request, move the ticket. 4. Observe. Read back what actually happened, compare it against the intent, and decide whether the job is done, needs another pass or needs a person.

Step four is where systems are won and lost. A model that acts without reading back its own effect is guessing about the state of your business, and it will keep guessing confidently. Most of what separates a demo from a production agent lives in that fourth step: verification, retries, idempotency, and a defined answer to “what if the tool call half-worked”.

The stopping condition matters as much as the loop. An agent needs a definition of done it can evaluate, a budget of attempts, and a rule for what to do when both run out. Without those three it does not stop. It circles.

Where a chatbot stops

The AI agent vs chatbot question has a clean answer, and it is not about model quality. Both can run on the same model. The difference is who holds the loop.

In a chat interface, the human holds it. You perceive the problem, you decide what to ask, the model produces text, and you decide whether to act on it. The model contributes one step out of four. It is an excellent step, and it is still one out of four.

An agent holds all four. Which means it also inherits the parts nobody enjoys: knowing when it is finished, knowing when it is stuck, and being accountable for a change in a system of record rather than a paragraph on a screen.

There is a second difference that shows up in month three. A chatbot’s output is disposable, so a bad answer costs a person thirty seconds. An agent’s output is durable, so a bad answer sits in your CRM until someone finds it. That is why agent work is engineering work, and why the interesting effort goes into boundaries, logging and escalation rather than prompt wording.

The accountability test

Three questions settle whether what you are being sold is an agent. Ask them in this order.

Autonomy is a dial, not a badge

“Autonomous” gets used as a binary and behaves like a dial. Every agent we build is promoted through the same three positions, and the promotion is earned against measurements rather than granted at launch.

The boundary is a written list, not a vibe. Which tools it may call, which record types it may write, what value threshold sends a case to a person, what it may never do without approval. Anything irreversible or externally visible sits outside the boundary by default: sending money, emailing a customer, deleting data, touching production infrastructure without a rollback path.

That last part is the honest reason autonomy is a dial. Nobody, including us, can prove a system is safe on cases it has never seen. So the boundary starts narrow and widens against a measured pass rate. If a vendor offers full autonomy on day one, they are describing a demo, because on day one there is nothing to measure.

• Shadow - The agent does the whole job and writes nothing. Its proposed actions sit next to what the human actually did, and the gap between them is the score.
• Assisted - The agent acts, a human approves before the action lands. Slower than manual work at first. This is the stage that produces the evidence for the next one.
• Autonomous within a boundary - The agent acts alone on the cases where it has cleared the bar, and escalates everything outside them with its reasoning attached.

One ticket, end to end

Abstraction gets slippery here, so here is a real shape of work. This is what the Ticket Triage Agent does with a single inbound support ticket.

Every line of that is a state change in your helpdesk, logged with the model version, the retrieved context and the reasoning. Nobody typed a prompt. The last two rows are the point of the whole exercise: the agent knew what it did not know, and the human’s first contact with the ticket was already three quarters solved.

What an agent needs that a prompt does not

If you are scoping a build, this is the part that gets underestimated. A prompt needs a model. An agent needs six things around it, and five of them are ordinary software engineering:

Notice how little of that list is about the model. This is the whole argument for treating agent work as engineering: the model is the one component you did not build and cannot fully test, so everything around it has to be built and tested properly. We do that work as AI agent development, and the layer underneath it has its own discipline.

• Tool schemas it cannot misuse - Typed arguments, validation, idempotency keys, and a defined failure response. A malformed call should be rejected by the interface, not executed hopefully.
• State that survives a restart - Long jobs get interrupted. An agent that loses its place mid-task and starts over will duplicate work in your systems.
• An eval suite - Scored cases from your real inputs, run on every change. Without it, “is it working better” is a matter of opinion, and opinions do not survive a model upgrade.
• An escalation path with a named owner - Where does a stuck case go, how fast, and with what context attached.
• A full log per action - Input, retrieved context, tool calls, model version, output, cost. This is what makes a wrong answer diagnosable three weeks later instead of mysterious forever.
• A kill switch that a non-engineer can reach - If turning it off requires a deployment, it is not a control.

What changes for the person whose work it touches

The technical definition matters less to your team than one operational fact: an agent changes the shape of their day rather than the length of it.

Before, a support lead opens a queue of raw tickets and spends the first hour sorting. After, the queue is already sorted, and the hour goes to the eleven cases the agent flagged as uncertain. The work that remains is harder per case and there is less of it. That is a real change to a job description, and it goes badly if nobody says so before launch.

Two practical consequences follow. First, the exception queue becomes the main interface between your team and the agent, so it deserves proper design: sensible ordering, the agent’s reasoning attached, and a way to correct it that feeds back into the eval set. Second, somebody has to be told they are now accountable for reviewing rather than doing. People accept that readily when it is framed honestly and resent it when an agent appears in their tooling one Monday with no explanation.

The finance view is a third frame again. An agent moves a variable cost that scaled with headcount into a fixed build cost plus a variable cost that scales with task volume. Whether that is an improvement depends entirely on your volume curve, which is why the arithmetic gets its own article.

What agents are still bad at

Four categories where we say no, or say not yet.

Three things called agents that are not

Vocabulary has drifted, and it costs buyers money. Three patterns get sold under the word:

A prompt chain runs a fixed sequence of model calls. There is no decision about what to do next, so there is no loop. It is a template with steps.

A workflow with a model step is automation where one node happens to call an LLM. Useful, often the right answer, and governed like software rather than like a worker. If your process is genuinely deterministic, this is cheaper and more predictable than an agent, which is the argument in AI agents vs RPA.

A chatbot with function calling can act, but only within a turn a human started. Close the browser and nothing happens. That is an assistant, and assistants are valuable. They are just not a headcount question.

None of these are bad architectures. Each is the right answer to some problem. The failure is buying one, budgeting for the other, and finding out in month four.

The short version

• An AI agent owns an outcome, holds its own perceive-decide-act-observe loop, and stops when the job is done or a human is needed.
• A chatbot’s loop is held by the person typing. Same model, different accountability.
• The engineering that matters sits after the action: verification, retries, logging and escalation.
• Autonomy is a dial that gets widened against a measured pass rate, never a setting you switch on at launch.
• If nobody can name the human who owns the agent’s output, it is not deployed.

Keep reading

• AI agents vs RPA: when rules stop being enough - The same question from the automation side, with the arithmetic on when scripts stop paying for themselves.
• Multi-agent orchestration, explained with a beehive - What happens when one agent is not enough, and why smaller agents beat bigger ones.
• Questions, answered - Cost, safety, timelines and what stays human.