Agentic AI

A chatbot responds within a conversation: you ask, it answers, and the next move is yours. An agentic system can determine and carry out several steps towards an objective, using tools to read from and act in other systems and adjusting based on what those tools return. The distinction matters less than people expect, though. A great deal of useful automation sits between the two, and a tool-enabled assistant is not automatically an agent. We are usually more interested in whether a workflow can reach a defined completion condition than in what to call it.

Probably not, at least not first. We start with the simplest architecture that can meet the objective, and a great many valuable use cases need one model, a clear set of tools and a controlled workflow rather than a group of agents negotiating with each other. Multiple agents add coordination failure modes that are difficult to debug and expensive to evaluate. Where genuinely distinct specialisations are involved we will design for it, but we would rather earn that complexity than assume it.

It depends on reversibility, impact and regulatory context, and it is a spectrum rather than a setting. At one end the system recommends and a person acts. In the middle it prepares an action and waits for approval. At the other end it executes within boundaries defined and tested in advance. Most workflows end up using more than one level, with higher-risk actions gated and routine ones not. We design that division explicitly rather than discovering it in production.

That depends on what those systems expose. A documented API, clear authentication and predictable transaction behaviour make the work straightforward. Missing or partial interfaces make it a piece of integration engineering, which we can do, but it should be scoped rather than assumed. Part of discovery is assessing your estate honestly: what can be read, what can be written to safely, where permissions can be carried through, and which systems are better left out of the first workflow.

With least-privilege access, separation of read and write capability, approval gates on sensitive actions, and validation of what the model passes to a tool rather than trusting it. Before production, a representative evaluation set, failure-mode testing and sandboxed runs against real access boundaries. Afterwards, observability over every tool call, stopping conditions, rate limits, incident handling and a named human owner. None of this is an addition to the service. It is most of the engineering.

Anything an agent reads — a document, an email, a web page, a record returned by a tool — can contain text written to steer the model rather than inform it. We assume that will happen. Content the model reads is kept separate from the instructions it operates under, tool inputs are validated before execution regardless of where they originated, actions with consequences sit behind approval gates or fixed limits, and the evaluation set includes deliberately adversarial inputs. The aim is not a model that can never be misled, because no such model exists. It is a system in which being misled cannot cause harm the design has not already bounded.

The same design decisions that make an agent safe make it defensible. During discovery we establish which personal data the workflow touches, where the model runs and where the data stays (EU-region cloud deployment, private endpoints and self-hosted models are all options), and how long anything is retained. Every action the system takes is logged together with the reasoning, tool calls and human approvals behind it, so that a decision can be reconstructed afterwards. Where a workflow falls into an area the EU AI Act treats as higher risk — employment decisions, creditworthiness, access to essential services — the human oversight, documentation and transparency that regulation requires are the operating model we would have built anyway. We document it up front rather than retrofitting compliance later.

By measuring the current process before we change it. A baseline of cycle time, manual touchpoints, error rate and volume, then the same measures afterwards alongside task success rate, escalation rate, quality against agreed criteria and cost per completed task. We avoid single-figure productivity claims because they rarely survive scrutiny. A bounded pilot with agreed measures is slower to quote and considerably easier to defend.

No. The service is led by architecture and use case rather than by a platform, and model selection is a design decision we make with you and document the reasoning for, including where a smaller or cheaper model meets the quality requirement. Workloads differ in what they need from a model, and a choice that suits one part of a workflow often does not suit another.