AI & Data
The full domain, and the other capabilities within it.
AI Agents
Agents that call your systems through defined tools, explicit permissions and a human approval step.
What this is
An AI agent is a language model inside a loop: it reads a request, picks from a fixed set of tools you define, calls them, and reads the result before deciding what to do next. The value is not the model. It is the tool definitions, the context you assemble, and the boundary you draw around what the agent may touch.
The failure mode we see most often is an agent given broad write access to a production system on the strength of a good demo. Demos run on happy paths; production runs on edge cases, stale data and ambiguous instructions. An agent with write access and no approval gate is a risk decision, not a feature, so we build the approval gate first and narrow it only where the blast radius is genuinely small.
When you need it
If more than one of these is true, this is usually the right place to start.
- A pilot agent works in a demo, but nobody can say what it will do with an unexpected request.
- Your team wants agents acting in ticketing, ERP or email, and security has not signed off on what they can reach.
- There is no record of which tools an agent called, with which arguments, on whose behalf.
- Every new use case is rebuilt from scratch because there is no shared tool layer or evaluation harness.
What the scope covers
- Use-case selection: which tasks are bounded enough for an agent, and which should stay a deterministic workflow.
- Tool definition and integration against your existing APIs, with typed inputs and least-privilege credentials.
- Context assembly - what the agent is allowed to see, from which sources, under whose identity.
- Guardrails, human approval steps and rollback paths for any action that writes or spends.
- An evaluation harness with a fixed task set, so a prompt or model change can be measured before release.
What you receive
| Deliverable | What it contains |
|---|---|
| Agent design document | The task boundary, tool inventory, permitted data sources and the actions requiring human approval, agreed before any code is written. |
| Tool and integration layer | Typed tool definitions over your APIs, each running under its own service identity and scoped credentials. |
| Guardrails and approval flow | Policy checks, rate and spend limits, and an approval queue that shows a reviewer the proposed change in full before it executes. |
| Evaluation harness and audit log | A repeatable task suite plus a structured log of every tool call, argument and outcome, retained for review. |
Reference architecture
A reference, not a template. Your estate decides which parts apply and in what order they arrive.
How success is measured
Targets are agreed with you before the work starts, and reported against for its duration.
- Task success rate against a fixed evaluation set your team defines and reviews, re-run on every prompt or model change.
- Rate of actions escalated to human approval, and how often a reviewer rejects or edits the proposed action.
- Completeness of the audit log: the share of agent actions traceable to a request, a tool call and an identity.
Questions we are asked
Can the agent do the work end to end without a human?
For read-only tasks - retrieval, drafting, summarising, classifying - usually yes, within a defined scope. For anything that writes to a system, moves money or contacts a customer, we start with human approval on every action and narrow it only where evaluation data supports narrowing it. Removing the approval step is a risk decision your organisation owns, not a technical default.
Which model should we use?
Model choice matters less than most vendors imply. Tool design, context quality and error handling decide whether an agent works, and models are swappable if you build for it. We keep the model behind an interface and let the evaluation harness choose, rather than committing to one at the design stage.
How do you stop the agent doing something harmful?
Three layers: the agent can only call tools you explicitly defined, those tools run with scoped least-privilege credentials, and write actions pass through policy checks and an approval queue. None of that makes the model reliable. It makes the consequences of an unreliable answer bounded and reversible.
What data does the agent see, and where does it go?
It sees only the sources listed in the design document, retrieved under an identity we agree with you. Where data residency or confidentiality rules apply, models can run inside your own cloud tenancy or against a regional endpoint. We document the data flow so your compliance team can review it before launch.
How do we know it still works after a prompt or model change?
That is what the evaluation harness is for. It holds a fixed set of tasks with expected outcomes, and every change is measured against it before it ships. Without one, each change is a guess and regressions surface as user complaints instead of failing tests.
When should we not use an agent?
When the task is deterministic and well understood, a workflow engine or a plain script is cheaper, faster and far easier to audit. Agents earn their cost where the input is unstructured and the path varies between requests. If your case belongs in the first category we will say so.
Continue reading
Enterprise AI & RAG
Retrieval-augmented generation over your own documents, with permission filtering at retrieval time, citations and an evaluation set your experts agree.
Computer Vision
Vision models on your camera and sensor feeds: annotation, edge inference, confidence thresholds, human review and drift monitoring after go-live.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.