What is an AI agent?
An AI agent is software that takes a goal and figures out its own steps to reach it, using a model to reason and tools to act. What sets it apart isn't how intelligent it is. It's that nobody wrote down the sequence it follows.
Start with the plainest version. Traditional software does what it was told, in the order it was told. You describe the steps, it performs them, and if it meets something the steps do not cover, it stops or fails. An AI agent is given an objective instead of instructions. It works out the steps itself, and it can handle situations nobody anticipated because it was never following a fixed list.
A short example makes the difference concrete. Asked to process an invoice, conventional automation follows a defined path: read these fields, check them against this table, route to that queue. An agent is told to get the invoice paid correctly. It might read the invoice, notice the purchase order number is missing, search for a matching order, find a discrepancy in the quantity, and escalate to a person with the discrepancy explained. Nobody scripted that path. It was assembled in response to what the agent found.
Why nobody agrees on the definition
The term is used inconsistently, and it is worth knowing why before evaluating anything sold as one. There is no standards body for what qualifies, so in practice vendors set the threshold wherever their product happens to sit. A chatbot that can call one function gets marketed as an agent. So does a system that runs unattended for hours across a dozen systems. Both claims use the same word for capabilities orders of magnitude apart.
That makes "is it an agent" a poor question and "how much does it decide" a good one. The useful reading is a range rather than a category: at one end, software that follows a fixed path with a model doing one step inside it; at the other, software that determines its own path, selects its own tools, and decides when it is finished. Most things being sold sit closer to the first end than their marketing implies, which is the subject of agent washing.
What differs an AI Agent from Automation?
One question settles it in most cases: who decided the order of the steps? If a developer or a business analyst wrote the sequence, it is automation, however much AI sits inside individual steps. If the software determines the sequence while running, it is an agent.
Three follow-on properties usually travel with that answer, and they are worth checking because they are what make an agent operationally different rather than just architecturally different.
- It can take actions, not just produce output. A system that returns a recommendation for a person to act on is doing something meaningfully different from one that issues the credit itself. The second changes what happens when it is wrong.
- It handles cases nobody enumerated. Automation meeting an unlisted condition stops. An agent attempts something. That is the benefit and the risk in one sentence.
- It decides when it is done. This is the property most often absent, and the next section explains why its absence causes more production incidents than any other single gap.
Automation with AI in it is not a lesser thing. For a high-volume process with a known shape, a fixed path with a model handling one interpretive step is usually the better engineering choice: it is cheaper, faster, easier to test, and it can be approved once. The reason the distinction matters is not status. It is that the two need completely different governance, and treating an agent like automation is how organizations end up unable to explain what their software did.
What is an AI agent made of?
Five parts: a goal, a reasoning model, memory, tools, and a stopping condition. The first four appear in every vendor diagram. The fifth is routinely left out, and its absence is behind most runaway cost and looping failures in production.
The components below describe what has to be present for an agent to function. How they are implemented varies enormously between frameworks and platforms, but the parts themselves are consistent.
- 01
A goalA stated objective, rather than a list of steps. How precisely it is scoped determines almost everything downstream, because a vague goal produces a wide search for ways to satisfy it. Failure mode: objectives broad enough to be technically satisfied in ways nobody wanted.
- 02
A reasoning modelUsually a large language model, deciding what to do next given the goal and what has happened so far. This is the part people mean by "the AI," and it is one component of five. Failure mode: confident reasoning over a wrong premise.
- 03
MemoryBoth short-term context within a single run and, in some designs, persistence across runs. Without it the agent forgets what it already tried. Failure mode: repeating an action already taken, which matters greatly if the action was a payment.
- 04
ToolsThe systems, APIs, and data the agent can actually reach and act on. Tools are where an agent stops being a text generator and starts having consequences. Failure mode: broader access than the task requires, inherited rather than granted.
- 05
A stopping conditionA definition of done, plus limits on steps, time, and spend, and a rule for when to hand off to a person. Failure mode: the agent does not fail, it continues, which is how a small task becomes a large invoice and a loop becomes an incident.
Component five deserves extra attention because of how quietly it fails. The other four fail in obvious ways: a bad tool call throws an error; a missing memory causes an obvious repeat. But an agent with no stopping condition just keeps going correctly, without ever wrapping up. So, the warning sign isn't an error alert, its rising cost, slower performance, and eventually someone having to step in manually. It's also the component least likely to show up in a demo, since demos end when the presenter decides to stop them.
What types of AI agents are there?
Two taxonomies are in circulation. The classical one from AI research grades agents by how they decide, from simple reflex through learning agents. The practical enterprise one groups them by the work they do. Both are useful, and they answer different questions.
The academic taxonomy is what turns up in textbooks and interviews. The functional grouping is what turns up in procurement. Knowing which one somebody is using saves a lot of confusion.
| Type | How it decides | Typical use | Limitation |
|---|---|---|---|
| Reflex | Reacts to the current input using fixed rules, with no memory | Simple filtering, alerting, and routing | Cannot handle anything requiring context |
| Model-based | Keeps an internal picture of the world and reasons over it | Monitoring where current state matters | Only as good as the model of the world |
| Goal-based | Plans a sequence of actions to reach a stated objective | Most enterprise agents sit here | Treats all successful paths as equal |
| Utility-based | Weighs competing options against a measure of value | Pricing, routing, resource allocation | Requires the value measure to be right |
| Learning | Adjusts behaviour based on the outcomes of past actions | Personalization and long-running optimization | Behaviour drifts, so it needs continuous evaluation |
In practice, enterprise conversations use a functional grouping instead: agents are described by the work they do, such as customer service agents, procurement agents, reconciliation agents, or security triage agents. That framing is more useful for scoping and worse for architecture, because two agents doing very different technical things get the same label. When several agents work together on one outcome, that is multi-agent orchestration.
How is an AI agent different from a chatbot, a copilot, or RPA?
A chatbot has a conversation. A copilot assists a person who remains firmly in charge. RPA replays a recorded sequence exactly, step for step. An agent decides its own path and acts on it independently. The clearest way to tell them apart is this: does the software choose its own path, and is a human built into that loop by design, or left out of it?
These four are the most confused terms in the category, largely because products routinely sit between them and are marketed as whichever sounds strongest.
| Term | What it does | Who decides the steps | Human in the loop |
|---|---|---|---|
| AI agent | Pursues a goal and takes actions in systems | The software, at runtime | By exception, at defined checkpoints |
| Chatbot | Answers questions in conversation | Mostly a scripted or retrieval flow | The user drives every turn |
| Copilot | Suggests and drafts inside a person's work | The person, who accepts or rejects | Always, by design |
| RPA | Repeats a recorded sequence of interface actions | A developer, in advance | Only when it breaks |
| Workflow | Runs a defined process across systems | A designer, in advance | At designed approval points |
| Assistant | Handles requests within a bounded scope | Varies, often a mix | Usually per request |
Two of these distinctions carry real consequences. Copilot versus agent is a question of who is accountable: a copilot's output passes through a person who reviews it, which is a control, whereas an agent acting directly removes that control and has to replace it with something else. And RPA versus agent is a question of brittleness against unpredictability: RPA does exactly the same thing every time and breaks when a screen changes, while an agent adapts and is correspondingly harder to predict. Neither property is better in the abstract. They suit different problems.
What goes wrong with AI agents in production?
Five failures recur, and none of them is the model being unintelligent. Unbounded runs, wrong premises, inherited permissions, no owner, and no record. Each is a property of how the agent was deployed rather than of how well it reasons.
This is the part of the subject that tends to be discovered rather than planned for, so it is worth stating before a first deployment rather than after.
- Unbounded runs. Without a stopping condition and spend limits, an agent that cannot complete its goal keeps trying. The result is cost and latency rather than an error, so nothing alerts.
- Correct reasoning on a wrong premise. An agent that reads an ambiguous field, interprets it plausibly, and acts is not malfunctioning. It reached a wrong conclusion competently, which is invisible to model testing. See data intelligence.
- Inherited permissions. Agents frequently run as the identity that created them, which is usually far broader than the task needs. The over-permissioning is silent until something reaches further than intended.
- No named owner. When an agent misbehaves, the first question is who is responsible for it, and in many estates nobody can answer. See agent registry.
- No usable record. Answering what an agent did, on what data, under whose authority requires per-action logging captured at the time. It cannot be reconstructed later, which becomes a compliance problem the first time it is asked for. See AI governance.
The pattern across all five is that they are operational rather than technical. An agent that reasons well and is deployed without limits, permissions, ownership, and a record is a well-built component inside a badly built system. That gap between the two is what the rest of this glossary is about, and the practice of closing it is AgentOps.