AI assistants that know what they do not know
A chat demo answers questions well. An assistant in production has to answer from your actual content, hold a conversation across turns, recognise when it is out of its depth, and hand over cleanly. Most of that is not model work.
The demo answers well; production is a grounding and handoff problem
The failure that ends an assistant project is rarely that the model cannot write a good reply. It is that the reply is confidently wrong about something specific to the business, or that the conversation reaches the edge of what the assistant covers and there is nowhere for it to go. Both are engineering problems with known remedies, and neither is solved by a better model.
- Plausible answers that contradict your own documentation or policy
- Answers that are right in isolation and wrong after three turns of context
- No defined behaviour when the assistant does not know, so it improvises
- A handoff to a human that loses everything the customer already explained
- Behaviour that differs between the channel it was tested on and the channel it runs on
- A deflection figure nobody can substantiate, because nobody defined what resolving a query means
The people who usually bring us this problem
Head of Support / CX
Ticket volume is growing faster than headcount and you need to know which contacts can genuinely be handled without a person, and how the rest reach one properly.
CTO / VP Engineering
You have been asked to ship an assistant and want it built with defined failure behaviour rather than discovered in front of customers.
Head of Product
An assistant is part of the product experience and has to be accurate about how the product works — which makes grounding and scope the central design questions.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
One confident wrong answer costs more than the volume it saved
Automation earns its keep across many correct interactions and loses it in a handful of authoritative-sounding wrong ones. The asymmetry is what makes grounding a requirement rather than an enhancement.
A broken handoff loses the work already done
If escalating means starting again, the assistant has added a step to the customer's problem. Handoff quality decides whether the assistant reduces effort or moves it.
Unmeasured deflection is a claim, not a result
"Deflected 60% of contacts" means nothing without saying what resolved means and how it was established. Retrofitting that measurement after launch usually means the baseline was never captured.
Capabilities
Each of these is work we carry out, not an area we advise on.
Retrieval grounding
Answering from your actual content — documentation, policy, product data — with citations back to the source. The design question is what the assistant does when retrieval returns nothing useful, which is the case that decides whether it is trustworthy.
Scope definition and refusal behaviour
Stating what the assistant covers and engineering the edges deliberately, so out-of-scope questions get a useful route to a person rather than an improvised answer.
Conversation state and multi-turn handling
What carries between turns, how corrections are handled, and how the assistant behaves when a customer changes subject mid-conversation — the point at which naive implementations degrade badly.
Escalation and human handoff
Detecting the right moment to hand over, passing full context, and defining what the human receives. This is usually the highest-value part of the build and the most commonly under-engineered.
Channel constraints
WhatsApp, web widget, email and in-app are different products with different affordances — message length, formatting, attachments, response expectations. An assistant designed for one does not transfer unchanged.
Measurement that means something
Defining what resolution is, capturing a baseline before launch, and separating genuine containment from contacts that were abandoned or escalated anyway.
Safety and data handling
What the assistant must never disclose, what it must not be persuaded to do, and where customer data reaches a model provider — settled as a constraint before the design rather than reviewed after it.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Start from the contact reasons, not the technology
The volume, shape and repeatability of real contacts decide whether an assistant helps at all, and what it should be able to answer. A ranked list of actual reasons beats a plausible-sounding scope invented in a meeting.
Define resolution before launching anything
Containment, escalation and abandonment are separated and measured from day one, with a pre-launch baseline. Without this, every later claim about the assistant's value is unverifiable — including internally.
Ground it, and make the absence of grounding visible
Answers come from retrievable sources with citations. When nothing relevant is retrieved, the assistant says so and routes, rather than filling the gap — which is the single design decision that most affects whether it can be trusted.
Engineer the handoff as a feature
Escalation is designed, tested and measured like any other path, with the full conversation passed to the human. Treating it as an exception path is what produces the "please repeat your issue" experience customers remember.
Evaluate on real conversations, not scripted ones
Test sets built from actual contact transcripts, including the awkward ones — multi-topic, ambiguous, angry, out of scope. Scripted happy paths pass comfortably and prove very little.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Design
- Contact-reason analysis and scope definition
- Resolution, escalation and abandonment definitions
- Grounding sources and citation strategy
- Safety constraints and data-handling boundaries
Implementation
- Retrieval layer over the agreed sources
- Conversation state and multi-turn handling
- Scope boundaries and refusal behaviour
- Escalation path with context transfer
- Channel-specific adaptation
Operation
- Resolution, escalation and abandonment measurement
- Review of real conversations for grounding failures
- Source-content maintenance so retrieval stays accurate
Architecture and technology
System concerns
- Channel intake and normalisation
- Conversation state store
- Retrieval over authoritative sources
- Response generation with citations
- Scope and safety checks
- Escalation routing with context
Operational concerns
- Source content freshness and ownership
- Conversation review workflow
- Outcome measurement against the pre-launch baseline
- Data handling and retention across the provider boundary
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
You need an agent that takes actions, not one that answers questions
See AI Agents. The permission and termination concerns there do not apply to a purely conversational assistant.
Your problem is that AI systems cannot find or cite your content
See AI Search Optimization, which covers how assistants and answer engines discover and quote a site.
Frequently asked
Can you show us an assistant you have built?
We can demonstrate the architecture, retrieval approach and evaluation method against your use case during discovery. Ask us which adjacent engineering engagements best match your data and integration requirements.
How do you stop it making things up?
By grounding every answer in retrievable sources and treating the no-result case as a first-class outcome rather than a gap to fill. When nothing relevant is retrieved the assistant says so and routes to a person. That is less impressive in a demo and considerably more useful in production, and it removes most of the failure mode people actually worry about.
Will it reduce our support costs?
It can reduce the number of contacts needing a person, and we will not give you a percentage before we have looked at your contact reasons. What we will do is define resolution before launch and capture a baseline, so the effect can be measured rather than asserted afterwards. A vendor quoting deflection rates for your business without your data is quoting someone else's business.
Web widget, WhatsApp or both?
Whichever your customers already use, and the choice changes the build rather than just the integration. Message length, formatting, attachments and expected response latency all differ, and an assistant tuned for a web widget will feel wrong in a messaging thread. It is a product decision before it is a technical one.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.