An agent does not merely answer — it acts, reading from your systems and writing back to them. So we start the project with what it is allowed to touch, rather than with which model to use.
Three things get called by the same word, and they differ in permission scope — and it is permissions, not answer quality, that determine a project's cost and its risk.
None of that is an argument against agents. It is an argument for reaching for one when the simpler thing genuinely will not do.
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.
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:
That last point is often treated as an extra, and it is the condition of being able to fix anything. Without the record, an agent's mistake is an event about which only one thing is known: that it happened.
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 model provider is normally a sub-processor, and the client approves that choice. 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 regimes come into play and they are worth not conflating. The GDPR restricts decisions taken solely by automated means, so genuine human involvement changes the picture. The AI Act imposes its duties — event logging, oversight, documentation — according to theclassification of the system rather than the weight of any single decision; recruitment and consumer creditworthiness are high-risk uses, many others are not. Classification has to be settled on its own terms — set out alongside our AI Act readiness audit.
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. An agent is one possible outcome of a wider AI implementation, not a separate world.
An agent costs more than automating the same process, and it is worth knowing where the difference goes: not on the 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 the level of certainty required. We break every component down in our note on what an AI implementation costs.
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 the state of your data. That is why an agent project starts with permissions rather than with the model.
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.
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 model itself is usually the smallest line. The largest variation comes from the number of systems the agent needs access to and the level of certainty required. We break the components down in our note on what an AI implementation costs.
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.
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 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.
Describe the process in a few sentences. We will tell you whether we see an agent in it or whether simpler automation is enough — including when that means a smaller project.
Book a free consultation