An AI agent is a system that pursues a goal across multiple steps, choosing its own actions along the way and using tools to affect systems outside itself. A chatbot answers the question in front of it. An assistant helps a person do a task they are already doing. An agent is given an outcome and works out the sequence.
The word is doing a great deal of commercial work at the moment, most of it imprecise. Vendors describe form-filling wizards as agents, and internal teams describe genuinely autonomous systems as chatbots because that word attracts less scrutiny in a risk review. Neither serves you well, because the three categories carry entirely different failure modes, different audit obligations and different costs.
The market is discovering the difference expensively. Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls, and a follow-on forecast expects 40% of enterprises to demote or decommission autonomous agents by 2027 once governance failures surface in production. A material share of that is organisations that bought an agent when what they needed was a chatbot, or deployed an agent under controls designed for one.
The three categories, and the line that actually separates them
The useful distinction is not intelligence, model size or conversational quality. It is who decides the sequence of steps.
A chatbot responds to an input with an output. The interaction is one turn deep, possibly with conversational memory. It does not act on anything: it retrieves, summarises, drafts, explains. The scope of damage from a bad answer is limited to a person reading something wrong.
An assistant works alongside a person on a task the person owns. It proposes, drafts, suggests a next step, fills a field — and a human confirms before anything happens. The human is in the loop by design, not as a temporary safety measure. Copilot-style code completion and drafting tools sit here.
An agent is given an objective and decides for itself what to do about it. It plans, calls tools, observes the results, revises the plan and continues until it judges the objective met or it gives up. Crucially, actions occur without a human approving each one. That is the whole point, and it is also the whole risk.
The boundary is autonomy over the sequence, not autonomy over the decision. An agent that must ask permission before every write is an assistant with extra latency. An agent that reads ten systems, correlates them and writes one summary to a ticket is an agent even if the only write is small — because nobody chose those ten reads.
What an agent is made of
Strip away the marketing and there are five components. A system missing any of them is not an agent.
A goal. Expressed at a level above individual actions: reconcile this account, triage this alert, prepare this report. If the input is a list of steps, you have a workflow with a language model in it, which is often the correct thing to build and should be called that.
A loop. The agent acts, observes what happened, and decides again. This is what separates an agent from a prompt chain: the next step depends on the result of the last one, and the number of steps is not known in advance.
Tools. The means of reaching outside the model — querying a database, calling an internal API, filing a ticket, sending a message. An agent without tools is a chatbot that talks to itself. In practice, tool exposure is now standardised through the Model Context Protocol, which means a tool implemented once is usable by whichever model you run next.
State. What has been tried, what was learned, what remains. Multi-step work fails without durable state, and a failure at step seven that restarts at step one is the most common cause of an agent burning budget without producing anything.
A stopping condition. How the agent knows it is done, and how it knows it is stuck. This is the component that teams reliably skip and then discover at three in the morning when an agent has been retrying the same failing call for six hours.
Why the distinction matters commercially
Three practical consequences, each of which shows up in a procurement or a risk review.
The control surface is different. A chatbot needs output filtering and retrieval that respects the requesting user's entitlements. An agent needs all of that plus action authorisation: which tools it may call, with what arguments, against which systems, up to what value threshold, and what requires escalation. A bank that approves an agent using its chatbot control framework has approved something it has not assessed.
The audit obligation is different. For a chatbot, "what did it say and on what basis" is usually enough. For an agent, an auditor will ask what it did — every tool call, every argument, in order, with the identity it acted under. If that record does not exist as a matter of design, it cannot be reconstructed afterwards. In a regulated Azerbaijani institution this is not optional, and it is exactly what an ISO/IEC 42001 audit asks to see.
The cost profile is different. A chatbot turn is one model call. An agent run is an unbounded number of them, and the number grows with task difficulty. Budgeting for agents using chatbot per-request economics produces the cost surprise that Gartner names as the leading cancellation driver.
Where enterprise agents actually fail
Six patterns, observed repeatedly rather than theorised.
Permission flattening. The agent runs under a service account with broad access, so every user who can ask it a question has, in effect, the union of everyone's permissions. This is the most serious real failure in enterprise AI and it is entirely preventable: every action must occur under the identity of the person on whose behalf the agent acts, enforced at retrieval and tool-call time rather than described in a prompt.
Compounding error. Each step is 95% reliable, so a ten-step task is about 60% reliable, and a twenty-step task is a coin toss. Agents do not fail loudly at step one; they drift. The mitigation is fewer steps, verification between steps, and refusing to design tasks whose success requires a long unbroken chain.
No stopping condition. The agent retries, reformulates, retries again. Every run needs a step budget, a cost budget and a wall-clock limit, all enforced outside the model.
Prompt injection through retrieved content. The agent reads a document, an email or a web page that contains instructions aimed at it. Because agents act, this converts a content problem into an action problem. Treat everything retrieved as data, never as instruction, and gate any tool that writes or sends behind a check that is not itself a model.
Tools that are too powerful. An agent answering an HR policy question does not need a tool that can issue a payment. The restriction must be structural — the tool is not in the registry for that context — not a sentence in a system prompt.
Being an agent at all. The most common failure. A great deal of work described as agentic is a fixed process with a decision point in the middle. That is a workflow with one model call, and it is cheaper, faster, deterministic and auditable. Reach for an agent when the sequence genuinely cannot be known in advance.
When an agent is the right answer
The honest test has three parts. Use an agent when all three hold.
- The steps cannot be enumerated in advance. Investigation, triage and reconciliation across inconsistent systems qualify. Approving an invoice against three rules does not.
- Verification is cheaper than execution. You can tell quickly whether the result is right. Where checking the work costs as much as doing it, autonomy buys nothing.
- The blast radius is bounded. The worst outcome of a wrong action is recoverable — a ticket to reopen, a draft to discard — not an irreversible payment or an external communication.
If the third condition fails, keep the human in the loop and call the system an assistant. That is not a lesser product; it is the correct architecture for actions you cannot undo.
Building the first one
The sequence that works, in order.
Start with one task, read-heavy, with one write at the end — the write being something reversible, like creating a draft or a ticket. Give the agent a small tool set: three to six tools, each with a narrow schema and validated arguments.
Run it under the requesting user's identity from the first day. Retrofitting per-user entitlement into a system that indexed everything under a service account means re-architecting retrieval, and it is the single most expensive rework in this field.
Log every step at the level an auditor would ask for: who asked, which model and version, which tools with which arguments, what came back, how long, what it cost. Cheap to add now, impossible to reconstruct later.
Build an evaluation set of fifty to a hundred real cases from your own domain before the first production use, not after the first incident. Without it, a model upgrade is a gamble taken in production — and models change more often than your agent will.
Then measure the thing that matters: not whether the agent completes tasks, but whether it completes them without a human quietly redoing the work afterwards.
Key points
- The line between chatbot, assistant and agent is who decides the sequence of steps — not model quality or conversational polish.
- An agent needs five components: a goal, a loop, tools, state and a stopping condition. Missing any one produces the failure modes people blame on the model.
- Agents require action authorisation and step-level audit, which chatbot control frameworks do not provide. Approving one under the other is a gap, not a shortcut.
- Per-user identity at retrieval and tool-call time is the single most important control. A shared service account flattens entitlements across the organisation.
- Compounding error means long chains fail. Design for few steps with verification between them.
- Most work described as agentic is a workflow with one model call. Build that instead — it is cheaper, deterministic and auditable.
HAVAA is Yukon Labs' orchestration platform for running agents inside the customer's perimeter, with identity propagation, tool governance and step-level audit built in. Background reading: what is AI orchestration and multi-agent systems in the enterprise.