
AI agents in business: understanding, choosing and deploying
What separates a chatbot from an AI agent, how to pick the first use case that pays, how to deploy without breaking your processes, and how to measure what it really gives back.
An AI agent does not merely answer: it acts. It reads your emails and files them, offers a slot and confirms the appointment, qualifies an inbound prospect and creates their record, follows up a quote left unanswered. While you are doing something else.
It is also the most overused word of the year. Almost anything containing a language model now gets called an “AI agent”, including slightly talkative contact forms. This guide is here to sort things out: what an agent really is, when it brings something a simpler tool does not, how to deploy one without breaking what already works, and how you know it is working.
Chatbot, assistant, agent: three words, three different things
The confusion is expensive, because it leads to buying the wrong tool. A chatbot follows a decision tree: it recognises a question among those it has been taught and returns the matching answer. A conversational assistant generalises that with a language model: it formulates answers nobody dictated to it, but it stays locked inside the conversation. An agent crosses the line: it is allowed to act on outside systems.
| Chatbot | Conversational assistant | AI agent | |
|---|---|---|---|
| Logic | Fixed decision tree | Answer generation | Reasoning, then action |
| Output | Predetermined text | Original text | Text and actions |
| Tools | None | None | Calendar, email, CRM, API |
| Memory | None | The current conversation | The context of your business |
| Risk | An off-target answer | A wrong answer | A wrong action — hence the supervision |
That last row is the most important one. The day a system is allowed to write to your CRM or to send an email signed in your name, the question is no longer “does it answer well” but “what is it allowed to do on its own”. That is where the quality of a deployment is decided, far more than in the choice of model.

When a chatbot is enough — and it often is
There is no particular nobility in deploying the most sophisticated technology available. If your need fits in one sentence — “answer the ten questions everybody asks” — a good chatbot, or even a properly written FAQ page, will do the job, cost less and never break down in creative ways.
The chatbot remains the right call for answering a stable FAQ, pointing people to the right page, collecting a simple piece of information before handing over. The agent becomes useful as soon as the task involves several steps or requires acting inside another tool: checking a calendar before offering a slot, reading a message to decide who should handle it, enriching a prospect record before routing it.
Three questions are usually enough to settle it. Does the task have several steps that follow on from one another? Do you have to read from or write to another system to finish it? Does the answer depend on a context that changes every day? Two “yes” out of three, and an agent is justified. Three “no”, and you will save time and money by keeping things simple.
The opposite mistake exists too, and it is more painful: deploying a chatbot where an agent was needed. The visitor asks a real question, the script goes round in circles, and the experience leaves a worse memory than nothing at all would have.
Choosing the first use case
The first agent should not be the most impressive one. It should be the one with the best chance of succeeding, because its success funds and legitimises the ones that follow. A good candidate combines four traits: the task comes back at least every week, it eats up an amount of time you can put a figure on, its rules can be described out loud in five minutes, and a mistake there can be undone.
That last point rules out the most tempting tasks straight away. Invoicing, signing, publishing in the brand's name: a bad idea for a first agent, not because it is technically difficult, but because an incident there costs you the team's trust, and a project that loses the team's trust never recovers.
The first deployments that hold up, in most organisations, look like this:
| What the agent takes on | Why it works |
|---|---|
| Sorting and pre-drafting inbound emails | Daily volume, clear rules, mistakes can be undone |
| Booking appointments from a message or a call | The result can be checked at a glance in the calendar |
| Qualifying inbound prospects | Good and bad prospects show up through stable signals |
| Following up unanswered quotes | Nobody does it, everybody knows it ought to be done |
| First-line support replies | The escalation rate measures quality continuously |
Each of these cases matches an agent we build regularly; the detail by business function is set out on the AI agents page, and by industry on AI agents by industry.
The anatomy of an agent
An agent that works combines four building blocks, and failures almost always come from the third or the fourth rather than the first.
The model is the reasoning engine. It matters less than people think: at this stage of maturity, most large models handle a well-described task correctly. Switching models rarely fixes an agent problem.
The instructions describe the role, the tone, the limits and above all the edge cases. It is the document you would write to train a new recruit, with the same demands: what is not written down will not be done, and what is written ambiguously will be done badly.
The tools are the concrete accesses — inbox, calendar, CRM, document base, invoicing system. An agent is only worth what it can consult: half of all disappointments come from an agent being asked for a judgement that none of the data available to it makes possible.
The supervision defines what goes out on its own and what goes through approval. It is not a temporary spare wheel: it stays, moving towards the heavier actions as the agent proves itself on the lighter ones.
Deploying: five steps, no nasty surprises
Map the task. Write the procedure out as you would for a new employee: what triggers it, the steps, the edge cases, and the point at which help has to be asked for. This step often reveals that the procedure did not really exist, and that two people on the team were doing it differently. That finding alone is worth the trip.
Set the guardrails. Explicitly separate what the agent does on its own from what it proposes. Filing an email: on its own. Sending a quote: a proposal. The boundary is not technical, it is economic — on which side does a mistake cost more than the review does?
Connect the tools. Integrations run through named accesses, limited to the strict minimum, revocable and logged. An agent that needs to read the calendar does not need to modify it, and an agent that answers prospects has no business seeing the accounts.
Test in draft mode. For a few days to a few weeks, the agent proposes its actions without carrying them out. You correct, it learns your exceptions, and you get a figure: the share of its proposals you approve without editing them. Below eighty per cent, it is too early to let go of the reins.
Widen gradually. Autonomy is granted by type of action, not in one block. You start with the least risky actions, watch the numbers for two or three weeks, then move on.
You can watch this cycle run without installing anything: the site's demos run real agents on a fictional dataset, with their proposals, their approvals and their mistakes all on show.
A full case: qualifying your prospects automatically
This is the deployment that pays back fastest, because it acts directly on revenue rather than on comfort. The principle: not all prospects are equal, and spending the same time on a ready buyer as on a browser wastes the scarcest resource in the business.
Qualifying means crossing two dimensions. The profile answers “is this my customer?” — industry, size, need, budget. The intent answers “are they ready?” — what they have looked at, asked for, downloaded. A director in the right industry who reads an article is not worth the same as an unknown visitor who asks for a quote, and neither of the two is worth what a director in the right industry who asks for a quote is worth.
| Signal observed | Weight in the score |
|---|---|
| Quote or appointment request | Very strong |
| Repeat visits to the pricing page | Strong |
| Guide download | Medium |
| Reading a blog article | Weak |
| Origin outside the area or off target | Negative |

The mechanics come down to six moves. Capture of every enquiry, wherever it comes from. Enrichment of the missing information from public sources. Scoring by crossing profile and intent. Routing: hot prospects land with a human straight away, warm ones enter a content sequence, cold ones stay on standby. Notification to the right person, with the context, not just a name. Calibration, finally: every month, the scores awarded are compared with the sales actually closed and the weightings are corrected. Without that last point, a scoring system becomes a documented superstition.
The gain shows up first in the time to first response. A prospect contacted back within minutes of their enquiry does not have the same probability of converting as one contacted back the next day, and that difference is one of the few that every study in the sector finds. The agent does not make your pitch any better; it simply means you get there before the others do.
Measure, or forget it
Three figures are enough, provided you record them before the deployment and not after.
The time given back each week, measured on the precise task and not on a general impression. The processing time, from trigger to completed action. The error rate, meaning the share of actions you would have done differently — a figure that has to fall week after week, failing which the problem lies in the instructions, not in the model.
An agent that gives back eight hours a week gives back more than a month of work per quarter. That is a common order of magnitude on a sorting or qualification task, and it is also the threshold beyond which the team stops treating the agent as a gadget. Our automation calculator estimates that time from your own volumes, and the price list sets out alongside it what each type of agent costs.
The traps that keep coming back
Aiming too wide from the start. The agent that does everything does nothing reliably. A narrow scope and a measurable result beat a spectacular demo that nobody uses a month later.
Removing supervision too soon. Autonomy is earned through the numbers. It is also withdrawn: an agent whose error rate climbs back up after a change in your processes should go back to proposal mode, without that being experienced as a failure.
Neglecting the data. An agent that does not have access to the information it needs makes things up. That is not a design flaw in the model, it is a scoping flaw: it was asked for a judgement without being given anything to judge with.
Forgetting the team. An agent changes a working routine. The deployments that fail are rarely the ones where the engineering was bad; they are the ones nobody wanted to use because nobody had been consulted on what it should do.
Where to start
One task, one week of observation, one decision. Pick the repetitive thing that annoys you most on a Monday morning, time it honestly for five days, and see whether it ticks the four criteria from chapter three. If it does, you have your first use case; if not, the next one on the list will do the job.
To see concretely what an agent looks like in operation, the demos are open without an account. To place the cost, the price list is published in detail. And if you would rather describe your case than have us guess it, write to us: the reply includes an honest opinion on whether automating is worth it, including when that opinion is no.
Frequently asked questions
What is the difference between a chatbot and an AI agent?
A chatbot answers, an agent acts. The chatbot follows a script written in advance and returns text. The agent understands an intent, decides on the steps and uses tools — calendar, inbox, CRM, knowledge base — to see the task through. An agent can do everything a chatbot does; the reverse is not true.
How long does it take to deploy a first AI agent?
On a single, tightly defined use case, allow one to three weeks between scoping and go-live, a good share of it in draft mode, where the agent proposes its actions without carrying them out. A broader scope does not take longer to build: it takes longer to become reliable.
Is my data safe?
An agent only sees what it is given to see. The design work consists precisely in deciding which accesses it receives, read or write, and which actions require human approval. Accesses are named, revocable and logged, and the processing falls under the GDPR like any other tool plugged into your data.
Do I need to have a CRM before starting?
No. An agent can write to a shared spreadsheet just as well as to a CRM. A CRM becomes useful when the volume of prospects exceeds what a spreadsheet can keep track of, not before.
Can an AI agent get things wrong?
Yes, and that is precisely why supervision is part of the setup rather than a contradiction of it. You measure the error rate from day one, you keep human approval on irreversible actions — sending a quote, deleting a record, committing an amount — and you widen autonomy at the pace of the numbers, not at the pace of enthusiasm.
Put this into practice
Want us to handle it for you?
We put these exact methods to work on your business to deliver measurable outcomes.
Start my project

