We get asked this a lot, usually by someone who has already sat through a vendor pitch that used the word a dozen times without ever quite defining it. Fair question. "Agent" gets stuck on a chatbot with a system prompt and on a system that runs an unattended multi-day workflow, and those are very different products with very different failure modes.
Here's the definition we actually work from.
Three properties, not one
A system is an agent, in our usage, if it has all three of the following properties. Missing any one of them makes it something else, which is fine, just not an agent.
It works toward a goal across multiple steps. A single prompt-and-response isn't an agent, no matter how good the response is. An agent decides what to do next based on what happened after the last step, which means it's making more than one decision per task.
It acts on your live data and systems, not just what it was trained on. This is the part most demos skip. A model that answers questions from its training data is doing recall. An agent that queries your database, checks your ticketing system, or calls an internal API to get a current answer is doing something closer to what an employee does when they go find out.
It knows when to stop and hand off. This is the property that separates something you can trust with real work from something you have to babysit. An agent that always produces an answer, confident or not, isn't safe to point at production data. One that recognises "I don't have enough information" or "this needs a person to sign off," and routes accordingly, is a different kind of system, even if the underlying model is identical.
An agent is:
A reasoning system, powered by a large language model, that takes actions
>_
Database
Drive
SAP
DevSecOps
Observability
Where the term gets stretched
A chatbot wrapped around a single LLM call, even a very well-prompted one, doesn't meet the second or third condition. It has no access to your systems beyond what's in the context window, and it has no mechanism for declining to answer. Calling it an agent doesn't change what it can do, it just sets the wrong expectation for what happens when it's wrong.
Traditional automation has the opposite problem. An if-this-then-that workflow can absolutely act on live systems and can absolutely run multiple steps. What it doesn't have is judgement: it follows the branch it was built to follow, and when the input falls outside what the builder anticipated, it either breaks or does the wrong thing silently. That's not a criticism, most operational workflows should stay deterministic. It's just not what we mean by agent.
We use a six-level ladder internally to talk about this with clients, running from L0 (no agent, a person does everything through a UI) up to L5 (an autonomous agent that plans and completes multi-step tasks within a bounded mandate and escalates edge cases). Most of what gets marketed as an agent sits at L1 or L2: single-shot summaries or read-only retrieval. Those are useful, but they're closer to a smarter search bar than to something that acts.
Agent capability progression map
The part that actually matters
Autonomy on its own isn't the goal. A system that takes twelve unsupervised actions and gets the eleventh one wrong isn't better than a person doing the same task, it's worse, because nobody was watching. What we're actually trying to build is the judgement a good employee applies: knowing which exceptions matter, when a number looks wrong before you can prove it's wrong, and when to escalate instead of guessing.
That judgement has to come from somewhere. In practice it comes from grounding the agent in your real data and processes, then testing it against cases where you already know the right answer, the same way you'd check a new hire's work before trusting them with a client. We've written before about what that testing process actually looks like for a data-facing agent. The short version is that the model choice matters far less than most people expect, and the evaluation harness matters far more.
That's also why the system around the model ends up mattering as much as the model itself: input validation and PII redaction before a query reaches the model, tracing and eval sets to catch regressions, and a query layer that knows which system of record it's allowed to touch.
Getting compound value from an agent requires significant effort
record
A boundary case worth naming
Suppose you build a system that reads a support ticket, looks up the customer's account, drafts a reply, and sends it if the drafted reply matches a set of pre-approved templates, otherwise it queues the ticket for a human. That's an agent by our definition: it acts on live data, it makes more than one decision, and it has a real escalation path. Now suppose you strip out the escalation path and it sends every reply regardless of confidence. It still looks the same on a diagram. It's no longer something we'd put in front of a customer, because the property that made it trustworthy is the one that got removed.
That's usually the gap between an agent that survives contact with production and one that gets switched off after the first bad week: not the model behind it, but whether the judgement and the escalation are actually built in, rather than assumed.
>_ Written By
James Reid