Agents take actions in your systems, which is both their value and their risk.
The word agent is often used for a chatbot on a website. Here it is used narrowly. An agent is given a goal, decides which steps to take, and calls your systems to take them. It can create a ticket, move a booking or raise a credit note.
That is 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 that 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
Much of what is requested as an agent is better built as fixed automation, and we say so.
What every agent we build comes with
None of these four is optional, and each is cheaper to add at the start than 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
The pattern is the same each time: many small variations of one job, each needing two or three lookups before a decision.
- 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
The failure that matters is an agent acting confidently on a misunderstanding, at a speed a person cannot follow.
- 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
Both risks are contained by 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. A system that can only reply with information is a chatbot. Once it can change a booking or raise a credit note, different questions apply.
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. It is never left to the model 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?
The business is responsible, as it is for any staff member’s work. That is why the log and the limits exist. Every action can be traced, and costly ones still pass a person.
Will it still work when the model changes?
Mostly, but not identically. This is a running cost. The model version is pinned, and a set of cases the agent must pass is kept before any model change.
Should we start with an agent?
Usually not. Start with one step your team repeats by hand. As a project, an agent works better second than first.
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
- A reply within one business day
- Your details stay private
Start with your requirements
Seven short steps that tell us what you need. An engineer reads them before getting in touch.
Share your requirements