The word "agent" has been stretched to cover everything from a chatbot with a search button to a fully autonomous system managing a supply chain. The distinction that actually matters in engineering terms is narrow and useful.
The definition that matters
A system is an agent when it decides the sequence of its own actions.
A chatbot receives a message and returns a message. A pipeline follows a fixed path you designed. An agent is given an objective, and at each step it chooses what to do next based on what it has learned so far. That loop — observe, decide, act, observe again — is the whole idea.
An agent with read-only tools is a research assistant. An agent with write access is a member of staff. They deserve very different levels of scrutiny.
The anatomy of an agent
A goal. Stated in natural language or structured form: "reconcile this month's invoices against purchase orders and flag discrepancies over $500."
A set of tools. Functions the agent can call — query a database, send an email, create a ticket, issue a refund, call an internal API. Tools are the agent's hands, and the tool list is the real boundary of what it can do.
A reasoning loop. The model decides which tool to call, reads the result, and decides again. Modern implementations run this loop until the goal is met, a step budget is exhausted, or a stop condition fires.
Memory. Short-term context of what has happened in this run, and sometimes long-term memory across runs.
Guardrails. Limits on what the agent may do without approval — spending caps, allowed endpoints, forbidden actions, escalation rules.
Agent vs pipeline: when to use which
This is the decision that determines whether a project succeeds, and most teams get it wrong in the direction of too much autonomy.
| Pipeline | Agent | |
|---|---|---|
| Path | Fixed, designed by you | Chosen at runtime by the model |
| Predictability | High — same input, same route | Lower — varies run to run |
| Debugging | Straightforward | Requires full trace logging |
| Cost per run | Predictable | Variable, can spike |
| Best when | The steps are known | The steps depend on what is found |
Use a pipeline when you can draw the flowchart. If you can write down the steps, encoding them directly is cheaper, faster, more reliable, and far easier to audit than asking a model to rediscover them on every run.
Use an agent when the path genuinely cannot be known in advance — an investigation where each finding determines the next query, a troubleshooting flow across many possible systems, a research task over an open corpus.
Single agent or many
Multi-agent architectures get a lot of attention. In practice, most problems solved by a "team of agents" are solved more reliably by one agent with well-designed tools, or by a pipeline that calls a model at two or three specific points.
Multiple agents earn their complexity when subtasks are genuinely independent and can run in parallel, or when you want an adversarial check — one agent proposes, another critiques. Otherwise, coordination overhead and compounding error rates usually outweigh the benefit.
What makes agents hard in production
Error compounds. An agent that is 95% reliable per step is about 60% reliable over ten steps. Shortening the loop is usually more effective than improving the model.
Cost is unbounded by default. An agent that retries, reconsiders, and re-reads can burn many times the tokens of a fixed pipeline. Step budgets and spend caps are not optional.
The tool list is the attack surface. Anything the agent can call, a prompt injection can potentially trigger. An agent that reads untrusted web content and also has a send_email tool is a data exfiltration path.
Non-determinism breaks conventional testing. You cannot assert exact outputs. You need evaluation over distributions of behaviour, which is a different discipline — see AI evals.
Controlling what an agent may do
Once an agent can act, the security question stops being "who logged in" and becomes "which agent is acting, on whose behalf, with what authority." Every consequential action should pass an explicit check: is this agent identified, is this action within its granted permissions, and does its recent behaviour look normal.
That is the model behind Guardian Agent Defense — identity for every agent, per-action policy, behavioural detection, and enforcement that can allow, challenge, escalate, block, or contain.
The requirements behind that model are published as our Controlled Autonomy Standard, and the 24-control checklist turns them into a working assessment.
Frequently asked questions
What is the difference between an AI agent and a chatbot?
A chatbot exchanges messages; an agent takes actions. If the system can only produce text for a human to read, it is a chatbot no matter how sophisticated its reasoning. The moment it can call a tool that changes something — create a record, move money, send a message — it is an agent, and it needs authorization controls a chatbot never did.
Are AI agents reliable enough for production?
For bounded tasks with good tools and a human approval step on consequential actions, yes — they are in production across many organizations today. For long-horizon autonomous work with write access and no oversight, reliability is still the limiting factor because per-step error compounds. The practical answer is to shorten the loop and gate the irreversible actions.
What is agentic AI?
"Agentic AI" is an umbrella term for systems that exhibit agency — choosing actions toward a goal rather than responding to a single prompt. It covers single agents, multi-agent systems, and pipelines with agentic sub-steps. It describes a property, not a specific architecture.
How many tools should an agent have?
Fewer than you think. Agents degrade noticeably as the tool list grows, because selecting correctly among many similar options is itself a hard task. Most reliable production agents run with five to fifteen well-named, clearly-documented tools. If you need more, split into several narrower agents or route to them from a pipeline.
Do AI agents replace RPA?
They overlap but solve different problems. RPA is excellent at high-volume, deterministic, rule-stable processes and is cheaper to run. Agents handle variation, unstructured inputs, and exceptions that would break an RPA script. The strongest deployments we see use RPA or straight code for the deterministic backbone and call a model only at the points that genuinely require judgement.