Article · Agentic AI Fundamentals
What Is an AI Agent: Definition, Components and What It Is Not
An AI agent is software that takes an objective, decides on its own the sequence of steps to meet it, and executes them against real systems, escalating to a person when a case exceeds what it has been authorized to do. That is the short definition, the one I give a board. The long one has to separate two things the market blurs on purpose: what an agent is on the inside, and what an agent is not even when it looks the part on screen.
This page lays out the anatomy. If you want the step-by-step mechanics of how it reasons and decides on each pass, I cover that separately in how do AI agents work. And if you are coming from the business level, the entry point to the whole topic is AI agents for business.
The definition, piece by piece
Break down the sentence above, because every word does work.
Takes an objective. Not a literal command or a script. You tell it what you want done — “reconcile these invoices against their orders” — not how to key in each step. That is the first difference from classic software, which needs you to spell out the procedure.
Decides the sequence of steps. The agent interprets the specific case and chooses what to do next: which system to query, which rule to apply, whether it is missing a piece of data. Different cases produce different sequences, and that is where the value sits. It handles the exception without anyone having anticipated it one by one.
Executes against real systems. It does not answer in a chat window: it enters your ERP, reads your mailbox, writes to your CRM, posts an entry. It acts. Without this part you have an assistant that suggests, not an agent that works.
Escalates when it exceeds its mandate. A serious agent knows its limits. The rare case, the high amount or the doubt above a threshold go to a person with the context prepared. Autonomy without this brake is not a virtue, it is a risk.
The five components of an agent
When I open an agent up to explain it to an executive, I always find the same five pieces. None is optional in anything meant to run for real.
| Component | What it provides |
|---|---|
| Model | The reasoning engine: interprets the case and decides the next step |
| Instructions | Your operation’s rules, objective and limits, written down |
| Tools | The concrete actions on your systems, each with explicit permissions |
| Memory and context | What the agent knows about the case and your company while it works |
| Controls | Where it stops, what it escalates, and what gets recorded of each decision |
The model is an LLM — those from Anthropic, OpenAI or Google as a category — that reasons about the case. It is the easiest piece to replace and the one that least defines your system. It is treated as a utility, picked per task and swapped without rebuilding the process.
The instructions are the part that is genuinely yours. A generic model does not know your business rules, your exceptions or your criteria. Encoding that — what counts as a valid case, what to do with a deviation, when to stop — is the specific work that turns a clever model into an agent that runs your operation. I have written about how that definition gets encoded in operating model as code.
The tools are the functions the agent can invoke to act: check stock, issue the invoice, read the inbox. Each with concrete permissions for what it may read and what it may write. An agent is as capable as the tools you gave it and as safe as the limits on those tools.
Memory and context are what the agent carries: the state of the case, what it has decided so far, the knowledge of your company it needs so as not to answer into a void. Without memory, every step starts from zero and the agent gets lost the moment a case runs longer than two moves.
The controls are the points where a person reviews or decides, the escalation thresholds, and the trace that records what the agent received, which rule it applied and what it did. It is the piece a board looks at before approving anything, and the one I treat as non-negotiable in AI agent governance.
These five pieces fit into a wider architecture as the system grows — orchestration, evaluations, observability — which I break down in AI agent architecture. To understand what an agent is, the five are enough.
What an AI agent is not
The market’s most expensive confusion is calling things “agents” that are not. Two in particular.
A chat is not an agent. A conversational assistant takes a question and returns text. However good the text, that is where it ends: it does not enter your systems, it executes nothing, it leaves no result beyond the answer on screen. It is a tool a person uses, and the person still does the work. Useful, but a different category. A chat answers, and an agent acts.
A script is not an agent. An automated flow — a macro, a chain of recorded steps, an RPA robot — runs a fixed sequence someone programmed in advance. It works while the case matches the script, and it fails, or does something worse than failing, the moment an exception shows up. It does not interpret: it repeats. An agent occupies exactly the gap between the chat and the script: it genuinely executes, like the script, but it decides based on the case, which the script cannot.
The practical test I use: if the system touches no real system, it is a chat, not an agent. If it touches systems but breaks on the first case that was not in the script, it is a script, not an agent. An agent acts and decides.
An operational example
Picture a distributor receiving dozens of supplier invoices a day. The work is to reconcile each against its order and delivery note, approve the ones that match, and set aside the ones that do not.
An agent for this takes the objective (“reconcile these invoices”), reads each document (a reading tool), queries the order and delivery note in the ERP (query tools), applies the tolerance rule you set (instructions), approves the ones that match within the margin (a write tool, with a bounded permission), and sets aside with a note the ones that do not — new supplier, amount out of range, missing delivery note — for a person to look at (control and escalation). Every decision is recorded (trace).
A chat would only have explained how to reconcile. A script would have approved everything matching its exact pattern and jammed on the first odd invoice. The agent does the work and knows when it should not do it alone.
From definition to operation
Understanding what an agent is comes first. Next is knowing which work in your company it can execute reliably and how to build that without ending up with a pretty prototype that never reaches production. The first is covered by the business pillar, and the second, with an operator’s judgement, is in how to build an AI agent. And if what you want is the internal mechanics — why it is right sometimes and wrong others — continue with how do AI agents work.
Frequently Asked Questions
What is an AI agent in simple terms?
Software you tell what result you want, not how to get it, and it decides the steps and executes them against your systems: it reads, queries, applies a rule, writes, and escalates to a person when unsure. The key is that it acts and decides, not just answers.
What is the difference between an AI agent and a chatbot?
A chatbot converses: it takes a question and returns text, and there its work ends. An agent executes: it enters your systems and produces a real result. The chatbot is a tool a person uses, and the agent does the work within limits you have set.
What components does an AI agent need to work?
Five: a model that reasons, instructions with your rules and limits, tools to act on your systems, memory and context so it does not start from zero at each step, and controls that set where it stops, what it escalates and what gets recorded. Without any one of them you do not have an agent you can run seriously.
Is an automation flow or an RPA robot an AI agent?
No. An automated flow repeats a fixed sequence someone programmed and breaks when the case leaves the script. An agent interprets the specific case and decides what to do, even in situations no one anticipated one by one. Classic automation does not interpret, it just executes what was recorded.