Capability
AI integration
Assistants and automations doing one defined job inside your own systems, built so that the boundaries, the failure behaviour and the data handling are decided at design time rather than discovered later.
There is no shortage of ways to put a chat window on a website. The difficult part is everything around it: what the assistant is allowed to say, what it does when it does not know, what it is permitted to act on, and what happens to the information people type into it.
We build assistants that do one job well and refuse the rest. A narrow scope is not a limitation we apologise for. It is the thing that makes the behaviour predictable enough to put in front of your customers.
What these are usually asked to do
Customer facing
- Answering questions about services, coverage, pricing and availability.
- Taking enquiries and qualifying them before they reach a person.
- Booking and quote requests, collecting what is needed to reply properly first time.
- Guiding somebody to the right product or service when the range is large.
- Handing over cleanly to a phone number or an inbox the moment it is out of scope.
Internal
- Staff knowledge assistants answering from your own documented procedures.
- Drafting work that a person then reviews, rather than sending anything unattended.
- Pulling information together across systems that do not talk to each other.
- Automations that run a routine job and report what they did.
Design rules
What we build in as standard
These are not optional extras. They are the reason the thing can be put in front of customers, so they are in every build.
Content it reads is data, never instructions
Anything the assistant takes in, a customer message, a web page, an uploaded document, is treated as information to report on. Instructions hidden inside that content are not followed. This is the single most common way assistants are made to misbehave, and it is designed out rather than patched later.
A defined job, and a defined refusal
The assistant is given one job and the boundary is written down. Outside it, it says it cannot help and hands over to a person. Being clear about what it will not do is what makes what it does do dependable.
Consequences need a person
Reading and answering can run unattended. Anything that sends, commits, charges or decides something about somebody either goes through a person or is restricted to actions that are safe to get wrong. Which applies is settled in the scope, in writing.
The data path is decided before the build
What information the assistant can reach, what leaves your systems and who processes it are design decisions, not consequences of whichever tool was convenient. You get that written down, because you need it to answer your own privacy obligations.
Honest limits
Worth knowing before you commission one
- A language model can be wrong fluently. Narrow scope, a clear handover and a person on anything consequential are how that is managed, not eliminated.
- An assistant is only as good as what it is given to answer from. If your procedures are not written down anywhere, that work comes first and we will say so.
- Running costs sit with the model provider and scale with use. We estimate them during scoping and they are yours, not billed through us at a markup.
- We do not build open-ended general-purpose assistants. Without a defined job there is nothing to test against and no way to say whether it is working.
Questions we get asked
What stops it saying something wrong to a customer?
Scope, mostly. An assistant built to answer questions about your services, book appointments and take enquiries is given exactly that and nothing else, and it is built to say it does not know rather than to fill a gap. Broad, open-ended assistants are much harder to make safe, which is why we do not build them.
What is prompt injection, in plain terms?
It is when text the assistant reads, from a web page, a document, an email or a customer message, contains instructions aimed at the assistant rather than information for it. A poorly built assistant follows them. We build so that content the assistant reads is treated as data to be reported, never as instructions to be obeyed, and so that anything with a real consequence needs a person.
Can it take actions, or only answer questions?
Both, but we separate them deliberately. Reading and answering is low-consequence and can be automatic. Anything that writes, sends, charges or commits is either confirmed by a person or restricted to a narrow set of actions that are safe to get wrong. Which of those applies is written into the scope rather than decided during the build.
Where does our data go?
That depends on the design and we settle it before building. It is entirely possible to build something useful that never sends customer data to a model provider at all. Where data does leave your systems, you are told exactly what, to whom, and under what terms, because you need that to answer your own privacy obligations.
Is there a legal position we should know about?
If your assistant is reachable by people in the EU, the EU AI Act includes transparency obligations that have applied since 2 August 2026, broadly requiring that people are told they are dealing with an AI system. UK data protection law also constrains decisions made about people without meaningful human involvement. We build to those expectations as standard and flag where your circumstances need a proper legal opinion. We are not a law firm and this is not legal advice.
What happens when it does not know the answer?
It says so and hands over, to a phone number, an email address or a person. An assistant that guesses confidently is worse than no assistant, because the failure is invisible until a customer acts on it.
Who owns it?
You do. Where it runs on your accounts, you hold it directly. Where we host it, the accounts are in your name and the configuration is handed over with everything else.
Start with a conversation
Tell us what the system has to do and what it has to work alongside. You will get a written scope and a price before anything is committed, and your enquiry goes straight to the person who would build it.