An agent does not answer questions. It does things, and that is both the point and the risk.
The word has been stretched until it covers a chatbot on a website. Take it narrowly here. An agent is given a goal, decides for itself which steps to take, and calls your systems to take them. It can create the ticket, move the booking, raise the credit note.
That is genuinely useful for a small number of jobs. It is also the first piece of software you will own that takes an action nobody specified in advance, which changes what has to be built around it.
An AI agent is a language model given a short list of tools and permission to use them. A tool is one action in your system: look up an order, check stock at a branch, cancel a booking. The model reads the situation, picks a tool, sees the result, and picks again until the job is done or it gives up.
Where it earns its place.
Next to plain automation
Both use the same models. The difference is who decides the path, and it changes the cost of being wrong.
- Fixed automation: you wrote the steps, the model does one of them
- An agent: you wrote the goal and the tools, the model chooses the order
- Fixed automation fails the same way twice, so it can be tested
Most of what people ask us to build as an agent is better built as fixed automation. We say so, and the conversation gets shorter.
What every agent we build comes with
None of these are optional, and all four are cheaper to put in at the start than to add after an incident.
- Its own login and its own role, never a shared admin account
- A short list of tools, each doing exactly one thing
- Limits written down: what it may change, up to what value, and what it may never touch
- A log of every action, with what it was trying to do and what it saw
- A way to hand over to a person, and a person who is expecting the handover
Where it earns its place
It is the same shape each time. Many small variations of one job, each needing two or three lookups before anything can be decided.
- First-line support that checks the order, the payment and the dispatch before replying
- Enquiries qualified against your own catalogue and stock before a salesman sees them
- Appointment and booking changes across a calendar with real constraints
How we build one
- One job
- Tools
- Limits
- Log
- Shadow run
- Release
- Choosing one job with a clear finish, not a general assistant
- Building each tool as an ordinary API with its own permissions
- Running it in shadow first, where it proposes and a person acts
- Releasing the low-risk actions first and keeping the rest proposed
The failure that actually matters
Not the agent saying something foolish. The agent acting confidently on a misunderstanding, at a speed a person cannot catch up with.
- Acting on instructions hidden inside a customer email or an uploaded file
- Choosing a tool that is almost right, on a record that is almost the same
- Behaving differently after the model is updated, with nothing in your code changed
- Being given a wider permission during a busy week and keeping it afterwards
Every one of these is contained by the same two things: narrow tools and a hard limit on what any single action can change.
When this is the right choice.
- A repetitive job whose variations are endless but whose finish line is clear
- Work that needs two or three systems checked before anything can be decided
- Systems with real APIs, because an agent can only act through what exists
- A team willing to run it in shadow and read the log before it goes live
When it is not.
- A job with one path, where fixed automation costs less and can be properly tested
- Anything that moves money or changes a ledger without a value limit and a person reviewing
- A business whose process lives in one head and has never been written down
- Systems with no way in, where there is nothing for the agent to act through
Questions we are asked about it.
How is an agent different from a chatbot?
A chatbot answers. An agent acts. If the thing on your website can only reply with information, it is a chatbot, however it is sold. The moment it can change a booking or raise a credit note, the questions you need to ask change too.
What stops it doing something expensive?
The tools it is given, and the limits inside them. An agent cannot do what it has no tool for, so a refund tool with a ceiling and an approval step above that ceiling is the real control. The model is never trusted to restrain itself.
Can it work on the software we already run?
Only where that software can be reached from outside. Where there is an API, the agent gets tools. Where there is none, it can read and propose, and a person still does the acting. We check this before agreeing scope, because it decides what is possible.
Who is responsible when it gets something wrong?
You are, the same as when a junior staff member gets it wrong, which is why the log and the limits exist. We build so every action can be traced, and so the costly ones still pass a person.
Will it still work when the model changes?
Mostly, but not identically, and this is a real running cost that vendors rarely mention. We pin the version and keep a set of cases the agent must pass before any model change.
Should we start with an agent?
Usually not. Start with one step your team repeats by hand, and learn how they feel about it. An agent is a better second project than a first one.
Services that use it.
What it sits with.
Not sure AI agents is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private