"Agent" is doing a lot of work in vendor marketing right now, and it is worth pinning down, because the difference between a chatbot and an agent is the difference between something that can be wrong and something that can be wrong and act on it.
The distinction in one line
A chatbot produces text. An agent produces text and takes actions — it can call other software, read a record, write a record, send something, or decide to try again.
Ask a chatbot to reschedule a delivery and it writes you a lovely paragraph about rescheduling the delivery. Ask an agent, and it looks up the order, checks the route, changes the date in the system, and emails the customer. One drafted a suggestion. The other changed your data.
What an agent is actually made of
- Tools. Functions it is permitted to call — "look up customer," "create ticket," "send email." Nothing else. The tool list is the boundary of what it can do, and it is the most important security decision in the build.
- A loop. It decides which tool to use, sees the result, and decides again, until the task is done or it gives up. This is what makes it feel autonomous.
- A stopping condition. A step limit, a cost ceiling, or an explicit "done" signal. Without one you get a system that retries forever and bills you for the privilege.
- Guardrails. What requires human approval, what is never permitted, and what gets logged.
Where agents genuinely earn their keep
The pattern that works: multi-step tasks where the steps are known but the sequence depends on what is found along the way.
- Triage with lookup. Read an inbound request, check the account, categorize it, route it, and draft a reply for review.
- Reconciliation. Compare two systems, find the mismatches, and prepare a correction list for a person to approve.
- Research and assembly. Gather data from several internal sources into a single briefing document.
- Monitoring with escalation. Watch for a condition, gather context when it occurs, and open a ticket with the context attached.
Notice how many of these end at "for review." That is not timidity — it is the design that makes agents deployable.
Where they go wrong
- Too many tools. Give an agent forty capabilities and it will choose badly. Narrow tool sets outperform broad ones, consistently.
- Write access granted casually. Read-only agents are dramatically safer. Every write capability should be justified individually, not granted as a bundle.
- Compounding errors. In a ten-step task, a small mistake at step two becomes a confident wrong answer at step ten. Checkpoints matter more than model quality.
- No cost ceiling. A loop that retries is a loop that spends. Cap it.
- Prompt injection. If the agent reads untrusted content — inbound email, a web page, a submitted document — that content can contain instructions. An agent with tools and no input isolation is a genuine security problem, not a theoretical one.
How to deploy one without regret
Start read-only. Let it observe, categorize, and draft for a few weeks while you compare its output to what your team would have done. Then grant one write capability — the lowest-stakes one. Then the next.
Keep a full audit log of every tool call from day one, not after the first incident. And decide in advance which actions can never happen without a person clicking approve: anything that spends money, contacts a customer, or deletes something is a reasonable starting list.
Do you actually need one?
Often not. If the task is one step, you need a custom AI application, not an agent, and it will be cheaper and more predictable. If the sequence never varies, conventional automation is more reliable than a model deciding each time.
Agents are worth the extra complexity when the path genuinely branches based on what is found. That is a smaller set of problems than the marketing suggests — but for those problems, nothing else works as well.
We scope this as part of application development, and the tool-permission design usually needs input from the same people who own your security posture.
Describe the workflow and we will tell you whether it needs an agent or something simpler.