AI agent implementation

How an agent differs from a chatbot and from automation

Three things get called by the same word, and they differ in what they can do. A project's risk depends on the task, answer quality, the permissions granted and the consequences of an error, not on what the solution is called.

• A chatbot holds a conversation and provides answers. Incorrect information can affect a customer's decision, so we define which sources it answers from and when it passes the matter to a person.
• Automation follows a predefined sequence of steps. When something goes wrong, the fault is easier to locate, because the order of steps is known.
• An agent also chooses its own next steps and uses the tools made available to it. Its permissions determine whether it can only read data or also change it. That is why it needs boundaries, an action record, and a human on anything irreversible.

None of that is an argument against agents. It is an argument for reaching for one when the simpler thing genuinely will not do.

Coding agents in developers' hands are a separate matter — how to turn their use into a repeatable, reviewed process in a repository is covered under AI agents in your development team.

When an agent makes sense, and when simpler automation is enough

One question settles it: can the order of steps be written down in advance?

If it can, you do not need an agent. AI automation will handle that process more cheaply, more quickly, and in a way that is easier to test. A sequence you already know does not need something capable of inventing it.

If it cannot — because where to look at step two depends on what was found at step one, and there are dozens of paths — then writing the rules out becomes more expensive than building something that decides for itself. That is the moment for an agent.

In practice we recommend starting with automation and reaching for an agent only once it turns out there are too many rules. The reverse order is common and usually ends in a solution more expensive to maintain than the problem required.

Permissions: the first decision in the project

An agent that can act has to be told what it may touch. We settle that before the first line of code, in four steps:

• Read scope — which systems, and which parts of them, the agent reads from. As narrow as the task allows, by default.
• Write scope — what it is allowed to change. Usually a far shorter list than the read scope, and worth keeping that way.
• Operations requiring human approval — anything that cannot be undone: sending to a customer, a payment, deleting data, a status change that starts something else downstream.
• An action record — what the agent did and on what basis, in enough detail to reconstruct the decision afterwards.

That last point is often treated as an extra, but without it a mistake cannot be put right. Without the record, an agent's mistake is an event about which only one thing is known: that it happened.

Where the agent is to use the functions of the company's own system through an existing API, that permission scope becomes a controlled integration — how we build and test one is set out on our Connecting an AI assistant to your system (MCP) page.

Where the data goes

An agent working on company data has to process it somewhere, and where is a design decision rather than a foregone conclusion. With a third-party provider, fragments of that data leave your infrastructure; you then have to settle deliberately which data goes, to whom and on what basis. Where personal data is involved, the AI model provider's role is established per processing operation. For requests run on your instructions it is a processor: your processor if you contract with it directly, or a sub-processor if we engage it as part of the solution we build for you. Engaging it as a sub-processor requires your authorisation for sub-processing. To the extent it processes the data for its own purposes, it is a separate controller. Where not leaving your infrastructure is an absolute requirement, the alternative is a model running in your own infrastructure — dearer to operate, but it removes the external-transfer question altogether. We set out both options and the split of roles on our security and GDPR page.

Where an agent touches determinations with a significant effect on a specific person — employment, credit, access to a service — two separate sets of rules apply, and it is worth keeping them apart. The GDPR restricts decisions taken solely by automated means, so genuine human involvement changes the picture. The AI Act imposes its duties (a record of actions, oversight, documentation) according to the classification of the system, that is, the category it falls into, rather than the weight of any single decision. Recruitment and assessing the creditworthiness of natural persons are examples of high-risk uses, many others are not. Classification has to be settled on its own terms — set out alongside our AI Act technical compliance sprint.

What a first project looks like

A first agent should not be the most ambitious one. We start with a task performed often, on data that already exists, and where a mistake is visible immediately. For the first few weeks the agent runs alongside the existing process rather than in place of it — comparing the results produces a list of the cases it gets wrong, and that list is what sets the boundary between what it does alone and what goes to a person.

The stages, the concrete deliverable at the end of each, and the split of decisions are set out in our implementation methodology, and what we will not build — plus when we advise against a project — on what we don't do. An agent is one possible outcome of a wider AI implementation, not a separate world.

What it costs

An agent costs more than automating the same process, and it is worth knowing where the difference goes: not on the AI model, but on the boundaries it may act within and the record of what it did. The largest influences on a quote are the number of systems the agent needs access to and how reliable the results must be, that is, how rarely they may be wrong. We break every component down in our note on what an AI implementation costs.

Frequently asked questions

What actually is an AI agent?

We call it an agent when the solution does not merely answer but acts: it decides its own next steps and uses tools — reading from a system, writing to it, sending a message, raising a ticket. The difference from a chatbot is not the quality of the conversation, it is that an agent holds permissions. A chatbot that gets something wrong misleads someone; an agent that gets something wrong changes data in your systems. That is why an agent project starts with permissions rather than with choosing an AI model.

When do you need an agent rather than ordinary automation?

If the order of steps is known in advance, you do not need an agent and ordinary automation will be cheaper, faster and more predictable. An agent earns its cost only when the number of possible paths is too large to write down: the case needs checking in several places, and where to look next depends on what was found before. A good rule is to start with automation and reach for an agent only once it turns out there are too many rules.

What does implementing an AI agent cost?

More than automating the same process, for one reason: an agent that acts requires the boundaries it may act within to be built, and a record of what it did. The AI model itself is usually the smallest line. The largest variation comes from the number of systems the agent needs access to and how reliable the results must be, that is, how rarely they may be wrong. We break the components down in our note on what an AI implementation costs.

What happens when the agent gets it wrong?

That question has to be settled before go-live, not after the first incident. In practice it means three things: permissions scoped to what is genuinely needed, irreversible operations always gated behind a human, and a record sufficient to reconstruct why the agent did what it did. Without that third element you can neither repair the error nor evidence what happened.

Can an AI agent work on our company data?

Yes, and that is usually the point of the project — an agent with no access to your data adds little over a publicly available tool. It does require settling which data reaches the AI model and where that model runs. With a third-party provider, fragments of your data leave your infrastructure and you have to establish who receives them and on what legal basis; where not leaving your infrastructure is an absolute requirement, we consider a model running in your own infrastructure. We set out both options and the split of roles on our security and GDPR page.