Knowledge assistants
Cited answers drawn from your approved policies, procedures and prior work, with retrieval limited to what the person asking is entitled to see.
The human decides
Whether to rely on the cited source before acting on it.
AI that acts.
You stay in control.
Agents that plan, connect and execute — with human oversight.
Definition
What agentic AI actually is
An AI agent is a system that pursues a goal across multiple steps rather than answering one question at a time. Given an objective, it plans an approach, gathers what it needs from your systems, takes the actions it has been permitted to take, checks its own work, and stops for a human decision at the points you have defined. The distinction that matters commercially is not intelligence — it is that an agent can complete work, while a chatbot can only describe it.
Most of the cost in knowledge work is not the decision, it is the preparation for the decision: finding the documents, extracting the figures, checking them against a rule, assembling the summary. Agents address that preparation directly, which is why they change the economics of processes that have resisted automation for years — the ones where every case is slightly different and a rules engine could never cover them all.
The risk profile changes with the capability. A chatbot's worst case is a confident wrong answer; an agent's is a confident wrong action. That is why we design permissions and approvals before we design capability.
The six terms that matter
- Tool use
- An agent reaches your systems through explicitly defined tools — a database query, an API call, a document search — each with its own permissions. It cannot do anything a tool has not been written and authorised for.
- Grounding
- Answers are produced from retrieved source material rather than from the model's training data, with citations back to the document. Grounding is what makes an answer checkable.
- Human in the loop
- A defined point where a person reviews, approves or rejects before the process continues. The agent prepares; the person decides.
- Evaluation
- A maintained set of test cases with known correct answers, run on every change, measuring accuracy and appropriate refusal. It is the difference between believing a system works and knowing it does.
- Orchestration
- The coordination layer that sequences steps, handles failure and retry, enforces approval gates, and records what happened at each stage.
- Audit trail
- A durable record of every step an agent took, what it retrieved, what it decided and who approved it — the evidence an auditor or investigator will ask for.
Chatbot versus agent
The difference, dimension by dimension
Both are built on language models. Everything that matters commercially is in how they are engineered around one.
| Dimension | Basic chatbot | AI agent |
|---|---|---|
| What it does | Responds to a question with text | Pursues a goal across several steps and completes a task |
| Where knowledge comes from | Model training data, or a single document set | Live retrieval from your systems, with citations to the source |
| Ability to act | None — it can only describe an action | Calls permitted tools to read, write, notify or update within defined scope |
| Handling uncertainty | Typically answers anyway, fluently | Escalates to a person, or declines, when evidence or confidence is insufficient |
| Multi-step work | Each exchange starts again | Maintains state across steps, retries failures, and reports where it stopped |
| Oversight | The user reads the answer and decides what to do | Approval gates at defined points, with a full audit trail of every step |
| How quality is known | Impression, and user complaints | Measured against an evaluation set on every change, with regression detection |
| Failure mode to design against | A confident, wrong answer | A confident, wrong action — which is why permissions and approvals come first |
Where it applies
Ten use cases, and what a person still decides
Every use case below names the decision that stays human. If we cannot name one, the use case is not ready to be automated.
Compliance checking
Submissions and documents evaluated against a versioned rule set, producing structured findings that each cite the clause they relate to.
The human decides
The compliance determination itself, recorded against their name.
Document processing
Classification and field extraction from inbound documents, validated against expected formats and reference data, with per-field confidence surfaced.
The human decides
Confirmation of any field below the agreed confidence threshold.
Customer service automation
Enquiries classified, enriched with account context, and answered from approved guidance where the pattern is known.
The human decides
Approval of the response before it reaches the customer.
Workflow orchestration
Multi-step processes coordinated across systems — intake, validation, routing, approval, notification — with exceptions raised rather than absorbed.
The human decides
Approval at each gate the process design defines as material.
Incident analysis
Incident records summarised and compared, surfacing recurring contributing factors across sites, systems or periods.
The human decides
The causal conclusion and any resulting corrective action.
Report generation
Recurring reports drafted from underlying records, with every figure traceable to the data that produced it.
The human decides
Review and sign-off before the report is issued.
Research and decision support
Source material gathered, compared and summarised with citations, presenting an evidence base rather than a recommendation to adopt.
The human decides
The decision, and the weight given to each source.
Operational monitoring
Operational data watched for deviation from plan, raising prioritised, contextualised exceptions instead of raw alerts.
The human decides
Which exceptions to act on, and how.
Software development assistants
Agents that write tests, perform first-pass review, keep dependencies current and produce documentation — under the same review gates as any other contributor.
The human decides
Code review and approval before anything is merged.
Human oversight
The controls we build into every agent
Oversight only works when it is enforced by the system rather than expected of the operator. These are decided during design, before implementation.
Approval gates on material actions
Actions with financial, legal, contractual or personal consequence require a named human approval before they execute. Which actions qualify is agreed with you during design and enforced in the orchestration layer, not left to the model's judgement.
Scoped tool permissions
An agent can only do what a tool has been written and authorised for. Tools are least-privilege by default, read-only unless a write is required, and scoped to specific records rather than whole datasets.
Confidence thresholds and escalation
Where a step produces a confidence signal, thresholds determine whether it proceeds or escalates. Thresholds are configured per field and per process by the process owner, and reviewed against measured outcomes.
Grounding and refusal
Answers are constrained to retrieved source material. When the source material does not support an answer, the correct behaviour is to say so — and we test for that explicitly, because a system that never refuses is a system that will eventually invent.
Complete audit trail
Every run records the objective, the steps taken, what was retrieved, what was decided, which tools were called and who approved what. Retention is agreed in advance against your records obligations.
Reversibility
Automated actions are designed to be reversible where the process allows it, and irreversible actions are placed behind human approval. Where reversal is impossible, that is called out during design rather than discovered later.
Untrusted input handling
Documents, emails and web content an agent reads are treated as untrusted input. Instructions embedded in them are not obeyed: content and instructions are kept separate, and tool permissions bound the damage if separation fails.
Continuing evaluation
A maintained evaluation set runs on every change and on a schedule in production. Model behaviour drifts, inputs drift, and an agent that was accurate at launch is not automatically accurate a year later.
Security and governance
The questions an assessor will ask
We settle these during design and record the answers, because they are usually the constraints that decide the architecture.
Data boundaries
We establish which data an agent may access, where it is processed, where it is stored and how long it is retained — before implementation, and recorded as an architecture decision.
Permission inheritance
Retrieval respects the permissions the user already has. An assistant must never become a route to information someone could not otherwise open, which means access control lives in the index, not in the prompt.
Model selection and processing terms
Model choice is driven by your data-handling requirements as much as by capability: where inference runs, what the provider's retention and training terms say, and whether a self-hosted option is required.
Transparency to affected people
Where automated processing affects a person, they should be able to find out that it was used and how a decision was reached. We design for that disclosure rather than treating it as a later legal question.
Accountability
Every automated process has a named owner in your organisation who is accountable for its outcomes. An agent is a tool operated by someone, not an autonomous party.
Documented limitations
We record what the system does not do, where it is known to be weak and what it must not be used for. Undocumented limitations become other people's incidents.
Integration
Working with the systems you already have
Agentic AI does not require replacing your platform. It requires reaching it safely.
- We connect to the systems you have, through the interfaces they already expose — APIs, databases, document repositories, message queues — rather than requiring replacement.
- Each connection is a defined tool with its own permissions, timeout and failure behaviour, so an unavailable system degrades one capability instead of stopping the process.
- Where a system has no usable interface, we say so early and price the integration work honestly rather than assuming it away.
- Identity is federated with your existing provider, so access reflects your current permission model and is revoked when an account is.
- Nothing is deployed into a production path without an agreed rollback, and the first deployment runs alongside the existing process rather than replacing it.
Solution patterns
Five shapes most agentic work takes
Ordered roughly by risk. Starting with a read-only pattern is usually the right first move, because its worst outcome is a wrong answer that a citation makes checkable.
Grounded assistant
Retrieve → cite → answer, with refusal
A read-only agent over an approved corpus. The lowest-risk pattern to start with: it cannot change anything, and its failure mode is a wrong answer that a citation makes checkable.
Suited to
Recurring internal questions where the answer exists in documents but is hard to find.
Extract and confirm
Classify → extract → validate → human confirm
Structured data pulled from unstructured documents, validated against expected formats and reference data, then confirmed by a person with confidence shown per field.
Suited to
High-volume document intake where re-keying is the bottleneck and accuracy is verifiable.
Check and recommend
Evaluate against rules → cite clause → human decides
Assessment against an explicit rule set, producing findings a competent person confirms or overrides. The rule set stays reviewable and versioned; the determination stays human.
Suited to
Compliance, quality and eligibility review where consistency matters and the rules are written down.
Orchestrated workflow
Multi-step process with gates and exceptions
A process coordinated across systems, with approval gates at material steps, retries for transient failure, and exceptions raised to a person with context attached.
Suited to
Processes spanning several systems where handoffs currently cause delay and rework.
Monitor and escalate
Watch → detect deviation → contextualise → escalate
Continuous observation of operational data, raising prioritised exceptions with the relevant context rather than a raw alert someone has to interpret.
Suited to
Operations where problems are currently found late and cost rises with detection time.
Worked examples of these patterns
Illustrative solution pattern
Grounded knowledge assistant
An assistant that answers staff questions from your approved documents, cites its sources, and declines when the corpus does not cover the question.
Read the full write-upIllustrative solution patternDocument intake and extraction
Structured data extracted from inbound documents, with confidence surfaced and a person confirming before anything is committed.
Read the full write-upIllustrative solution patternAutomated compliance checking
Submissions checked against a written rule set, with every finding citing its clause and a competent person confirming the outcome.
Read the full write-upIllustrative solution patternService desk triage and resolution
Inbound requests classified, enriched and routed, with straightforward cases resolved from approved guidance and the rest escalated with context.
Read the full write-upThese are illustrative solution patterns — designs we build, not completed engagements. Each page states that explicitly, and expected outcomes are labelled as design intent rather than measured results.
Implementation approach
From candidate use case to production
Seven steps, each with a decision point where stopping is a legitimate outcome.
Assess candidate use cases
We look at volume, repeatability, how verifiable the output is, and what the consequence of an error would be. Cases where errors are cheap and checkable go first; cases where they are neither should wait.
Prove feasibility on your data
A bounded proof of concept against your real documents and systems, with a pass threshold agreed before it starts. If it does not meet the threshold, we say so and stop.
Design controls before capability
Data boundaries, tool permissions, approval gates and audit requirements are settled before the build, because retrofitting them means rebuilding.
Build with evaluation from day one
The evaluation set is written alongside the agent, not afterwards. Without it, there is no way to tell an improvement from a regression.
Pilot in parallel
The agent runs alongside the existing process with a single team, so its output can be compared against the current one before anything depends on it.
Extend on evidence
Scope grows based on measured accuracy and reviewed logs — including the questions it refused — rather than on enthusiasm.
Operate and re-measure
Continuing evaluation, monitoring and periodic review, because model behaviour and input patterns both change over time.
Have a use case in mind?
Describe the process you would like to automate. We will tell you whether it is a good early candidate, what the risks are, and what a bounded proof of concept would need to demonstrate.
We reply to every enquiry within one business day.