This page is for readers who want the detail: what we build with, how each kind of agent is designed, and the safeguards built in.
We are not tied to any AI company or cloud provider. For each part of an agent, this is what we choose from and how we decide.
The part that reads, reasons, writes and speaks.
We use the most capable models for difficult work and faster, cheaper ones for simple work. Where data must not leave your own servers, we use models that can run there. Switching to a newer model is a setting, not a rebuild.
The part that plans the steps and keeps track of the work.
We pick the simplest framework that does the job and keeps a clear record of every step. Long-running work is built so that nothing is lost if a system restarts.
How the agent finds the right document, record or number.
The agent searches your own documents and data, and can only see what the person using it is allowed to see.
How the agent works inside the software you already use.
We connect through each system’s official interface wherever one exists. Where it does not, the agent can operate the screens the way a member of staff would, under supervision.
How we know it works, before and after launch.
Every agent is tested against real examples you have approved, and every step it takes in live use is recorded.
Where the agent runs and where your data lives.
In your own cloud account, in your region, on the platform your security team already manages.
Product names are examples of the technology we work with and belong to their owners. They do not indicate a partnership.
Every solution we build follows one of nine proven designs, chosen to suit the kind of work and the risk involved. Open any one to see the diagram.
The agent takes a simple request, completes it in one system and confirms it is done.
Straight-line task. The task lives in one system and has one right answer, so the design stays deliberately small: take the request in, do the work, confirm it. Adding orchestration here would add failure points without adding value.
Typically built with: a fast, low-cost model tier; typed tool calls to one system; schema-validated output; trace logging.
The agent talks with people by phone or chat, answers their questions and completes their requests.
Conversational assistant. The work happens in conversation, so the defining feature is the clarification loop. When the agent is unsure it asks rather than guesses, and when it reaches the edge of its remit it hands over to a person with the full context.
Typically built with: a frontier model for dialogue; streaming speech-to-text and text-to-speech for voice; retrieval over approved knowledge; session memory with retention limits.
The agent reads large volumes of documents and answers questions, showing the source for every point.
Grounded research. Correctness depends on citing the right source. Hybrid retrieval that respects permissions and freshness feeds a reasoning step that has to ground every claim, and a claim with no source is removed before the reader sees it.
Typically built with: hybrid search with keyword and vector indexes; re-ranking; permission-trimmed retrieval; a frontier model with long context; citation verification.
The agent writes the first version of a document for a person to edit and approve.
Draft and review. The risk here is a wrong or ungrounded document, not a wrong transaction. So the design centres on a grounded first draft, an automated quality check against your standards, and a person who edits and signs before anything is published.
Typically built with: a frontier model for drafting; a second model as evaluator; templates and style rules as structured prompts; document and image generation tools.
The agent gathers the evidence, recommends a decision, and passes anything that is not simple to a person.
Decision with approval gate. A consequential judgement is being made, so the approve and refer branches are first-class parts of the design. Low-risk cases inside policy proceed, everything else goes to a person with the reasoning and evidence attached, and every decision is recorded.
Typically built with: a frontier model for reasoning; rules engine for hard policy limits; document extraction; append-only decision log.
The agent reads documents, checks the details and enters them into your systems.
Transaction processing. Money or records move in a system of record, so the design is built around extraction, validation, posting and reconciliation. Clean items go straight through. Exceptions are the only thing a person sees, and they arrive with the mismatch already explained.
Typically built with: document extraction with vision models; deterministic validation rules; erp and core-system connectors; idempotent workflow engine.
The agent keeps watch around the clock and alerts the right person when something needs attention.
Watch and escalate. There is no human trigger. The agent wakes on a signal, runs a continuous watch loop and escalates only when something crosses a threshold. That is why it has an event stream and a conditional branch where other patterns have an intake form.
Typically built with: event streaming and scheduled jobs; statistical baselines alongside model judgement; a fast model tier for the watch loop; a frontier model for diagnosis.
The agent analyses your data, explains what it shows and sets out the options.
Analytics on governed data. The agent reasons over enterprise data, so it sits on a governed data layer and a semantic model with agreed definitions. It writes queries and runs models rather than doing arithmetic in prose, which keeps its numbers consistent with the ones the business already trusts.
Typically built with: warehouse or lakehouse with a semantic layer; text-to-sql with query validation; optimisation and forecasting libraries; sandboxed code execution.
A lead agent splits a large job between specialist agents and brings their work together.
Orchestrator and specialists. The task spans domains that can run concurrently, so an orchestrator breaks it down, hands the parts to specialist agents and reconciles what they return. It is faster than one large agent, and each specialist can be tested on its own.
Typically built with: agent-to-agent orchestration with durable state; model context protocol tool servers; a mix of model tiers per specialist; distributed tracing across agents.
These are part of the build and are in place from the first day of live use.
We test every agent on real examples from your business, with answers your own experts have agreed. It goes live only when it passes.
You decide which actions the agent can take on its own and which need a person’s approval.
Every step the agent takes is recorded, so you can always see what it did and why.
The agent runs inside your own systems and sees only what it needs. Your data is never used to train AI models.
We design each agent around the laws and regulations that apply to your industry, and provide the documents your regulator expects.
You can pause the agent at any time and return to the manual process. Your team will have practised doing so.
Every action an agent can take is given one of these levels. You choose the level for each action.
Send us your design or your problem. We will tell you how we would approach it and why.