The word has been applied to a support chatbot, a scheduled script that renames files, a customer service macro, and a research system that reads fifty documents and writes a briefing. Those are not the same category of thing, and a definition that covers all of them is not a definition — it is a marketing term. Which is a practical problem rather than a semantic one: if you are evaluating proposals, two vendors can quote you wildly different pieces of work and both call it an agent.

So here is a narrower definition, the parts of a real one, and the cases where the honest answer is that you do not need an agent at all. If you are reading a proposal and want the rest of the vocabulary defined plainly, that is a separate page.

A working definition

An AI agent is a system that is given an objective rather than a sequence of steps, has tools it can use to pursue that objective, and decides for itself which tools to use and when to stop. All three properties have to be present. Remove any one of them and you have something else — usually something simpler, cheaper and more predictable, which may well be what you actually want.

It is given an objective, not a script
A script says: read the field, look up the record, send template B. An agent is told what outcome is wanted and works out the route. This is the property that makes agents useful on tasks with variation, and the same property that makes them harder to test — the same input can legitimately produce two different sequences of actions.
It has tools it can actually use
A model that can only produce text is not an agent, however capable it is. An agent can read a database, call an API, search a document store, send an email. The tools are what let it affect the world, and they are also where most of the engineering, most of the cost and nearly all of the risk live.
It runs in a loop with a stopping condition
An agent acts, observes what happened, and decides whether it is finished. That loop is the thing people mean by “agentic”. It is also why a stopping condition is not optional: a loop without one either stops arbitrarily or does not stop, and both are production incidents.

What an agent is not

Most of the confusion in this market is four adjacent things wearing the same label. None of them is inferior — each is the correct choice for a different shape of problem, and picking the simplest one that works is not a compromise.

A model
A large language model is a component. On its own it takes text and returns text, with no ability to look anything up or do anything. Calling a model behind a text box an agent is the most common category error in this market.
A chatbot
A conversational interface. A chatbot may be built on an agent, and increasingly is, but the chat window is the front door rather than the system. Plenty of the most valuable agents have no interface at all and are triggered by an inbox or a queue.
Workflow automation
A defined sequence of steps with defined branches. If you can draw the whole thing as a flowchart and the flowchart is correct every time, you want workflow automation and not an agent — it will be cheaper to build, cheaper to run, and far easier to verify.
RPA
Robotic process automation drives an existing interface the way a person would, clicking through screens. It solves the problem of a system with no usable API. It is not reasoning about anything, and it breaks when the interface moves.

The distinction that matters commercially is the third one, because it is the one that decides the price of your project. We have written about how to tell workflow automation and agents apart in the cases where it is genuinely ambiguous, since that judgement is where most of the wasted budget in this field goes.

The parts of a working agent

A demo needs two of these. A system your business depends on needs all of them, and the gap between those two lists is most of what a build actually consists of.

Instructions
What the agent is for, what it must never do, and what it should do when it is unsure. This is a business document that happens to be written for a machine, and it is usually the part that has never been written down for the humans either.
Tools
The specific operations the agent can perform, each one scoped deliberately. An agent with credentials for an operation will eventually perform that operation, so the tool list is a permissions decision and not a convenience one.
Retrieval
Access to your own material, so answers come from your documentation rather than from general training. Without it, an agent asked something outside its knowledge will answer anyway — fluently, specifically and wrongly.
Memory
What the agent carries between steps and between sessions. Frequently less than people expect, and deliberately so: an agent that remembers everything is an agent that has quietly become a data retention question.
Guardrails and escalation
The things it is not permitted to decide alone, and the named place unfinished work goes. The worst acceptable outcome of an agent failing is that the process reverts to manual — silence is not an acceptable outcome.
Evaluation
A set of real cases with known correct handling, run whenever anything changes. This is what separates an agent you can improve from one you can only hope about, and it is the component most often skipped.

What agents are genuinely good at

The tasks where an agent beats both a person and a flowchart have a recognisable shape. There is variation in the input, so a script cannot cover it. The judgement required is real but shallow — the kind a competent new hire could be taught in a week rather than a year. It happens often enough that the saving is visible. And a mistake is recoverable.

Support triage, document and invoice processing, lead qualification and routine research and reporting all tend to fit that shape, which is why they come up in almost every conversation. The category matters less than the shape, though — plenty of support queues are too varied to be a sensible first project.

When you do not need an agent

This is the part vendors leave out, and it is the most useful section of any page like this one. Four cases where an agent is the wrong tool:

  • The process is fully deterministic. If the flowchart is correct every time, an agent adds cost, latency and a source of variability to something that had none.
  • It happens rarely and the stakes are high. The accuracy bar is expensive to reach and the saving is small, which is the worst trade available.
  • The rules are genuinely contested. If two experienced people disagree about correct handling and both are defensible, you have a policy question. Automating it picks a side silently.
  • The difficulty is a symptom of something upstream. If a task is painful because a form collects the wrong fields, fix the form. An agent papering over a broken input is a permanent cost added to avoid a one-off fix.

Working out which of these applies to a specific process is not a technical exercise, and it is considerably cheaper than a build. It is the whole reason to measure a workflow before committing to automate it, and the reason a serious assessment sometimes ends with a recommendation to leave a process alone.

The short version

An agent is given an objective rather than a sequence, has tools it can use, and decides when it is done. If your problem does not need all three of those, you probably want something simpler — and the simpler thing will be cheaper to build, cheaper to run and easier to trust.

The question is never whether an agent could do the task. It is whether the task needed something that could decide.