Client project, anonymised

A support assistant that knows when to say "I don't know"

Support teams drown in the same questions. An assistant can answer most of them from the help docs and past tickets. The hard part is the few it must not answer, and knowing which those are.

A project our founder led before starting Keelwork. The client is not named, under NDA; the story, the architecture and the numbers are real.

Service: AI agents
Stack: Knowledge base + resolved tickets, Retrieval + grounding, Confidence routing, Human-in-the-loop

Most support tickets are the same few questions asked a thousand ways, and almost all of them are answered somewhere the team has already written down. An assistant can take those. The work, and the risk, is in the small number it must not take, and in being right about which is which.

Where it stood at launch, against the targets agreed with the client:

42%conversations resolved without a humantarget 40%, measured at launch
0.6%replies with an unsupported claimtarget under 1%
4.4/5customer rating on AI-handled repliestarget 4.3
94%handoffs that truly needed a humantarget 95%, still open

The questions repeat; the risks do not

Open any support queue and the shape is the same. How do I reset my password. Where is my invoice. Why was I charged twice. The same handful of questions, reworded endlessly, and the answers already sit in the help centre and in thousands of tickets an agent has already resolved well.

Then, scattered through that volume, are the ones that look identical and are not: a refund the company has not agreed to, a change to an account that needs identity checks, a legal or safety question, an angry customer about to churn. An assistant that treats those like a password reset does real damage.

So the assistant’s job is not “answer support tickets.” It is “answer the ones you can answer well, from a source, and get out of the way on the ones you cannot.” A demo does the first half. Production is the second half.

What a support demo skips

A demo answers one tidy question in one turn. A production assistant has to handle the rest:

Conversations, not questions. Customers reply, clarify, and change the subject. The assistant has to hold the thread.
Tone and policy. It cannot promise a refund, invent a discount, or guess at a policy. Those are commitments the company has to honour.
It has to escalate. The correct action on a sensitive or uncovered question is to hand to a human, cleanly, with the context the human needs.
It lives inside the support tool. Agents see a suggested reply, not a separate app, and customer data stays where it already is.

Answer from the docs, and from what agents already said

The assistant grounds every reply in two sources: the help centre, and the tickets agents have already resolved well. Past resolutions are often better answers than the docs, because they are how a real person phrased it to a real customer. It drafts a reply from the retrieved passages, keeps the citation, and runs it through a guardrail before anything reaches the customer or the agent.

The request path. The same grounded draft can become an auto-reply, a suggestion an agent approves, or an escalation. The routing decides which.

Three outcomes, not one

The assistant does not choose between answering and staying silent. It chooses between three outcomes, on every message, from how well it is grounded, how confident the retrieval is, and how sensitive the topic is.

Knowing when not to answer. The thresholds are tuned against the eval set, and they tighten automatically on sensitive topics.

Escalation is a first-class output, not a failure. When no retrieved passage supports an answer, or the topic is one the company has marked sensitive, the assistant hands to a human with the conversation and the sources it did find, so the agent starts warm rather than from scratch.

The agents teach it

Every suggestion an agent edits or approves is a label. If an agent rewrites a drafted reply, the difference is signal: the draft was close but wrong somewhere. If they approve it untouched, that is a clean positive. Those signals feed two things: the eval set grows with real cases, and retrieval learns which documents actually resolved which questions.

Why it improves in place. The team does not label a dataset; their normal work is the label, and every resolved ticket makes the next draft better.

What we measure, and how

The numbers fall into three groups, each defined so it means something.

Containment and routing asks whether it helped without hurting. Containment is the share of conversations resolved without a human. Escalation precision is the share of its handoffs that genuinely needed one, so we are not just pushing easy tickets back to agents to flatter the containment number. We watch both together, because either one alone is easy to game.

Answer quality asks whether customers were well served. Grounded-and-cited is the share of replies backed by a retrieved source. The unsupported-claim rate is the share of replies with a statement no source backs, scored by a faithfulness judge. The customer rating is the thumbs or CSAT on AI-handled replies, kept separate from human-handled ones so the two never blur.

Economics asks whether it is worth running. Cost per conversation sums retrieval and generation. First-reply latency is the 95th percentile, because a slow first reply is the one customers feel.

Measure	Target	Sample run
Containment, resolved without a human	40%	42%
Escalation precision	95%	94%, still open
Grounded, cited replies	98%	99%
Unsupported-claim rate	under 1%	0.6%
Customer rating, AI-handled	4.3 / 5	4.4 / 5
Cost per conversation	under $0.05	$0.03
First-reply latency, p95	10 s	11 s, still open

The numbers are a sprint’s targets with one run on a sample queue to make them concrete. Escalation precision and latency are open on purpose: the assistant is handing back a few tickets a human did not need, and the first reply is a second slow, and both are named work rather than surprises.

Containment is the number everyone wants to push, and the one most worth being careful with. We hold it only as far as quality and escalation precision hold with it.

Where the volume goes. A third of conversations still get a human in the loop by design, with the assistant doing the first draft.

Where it breaks, and what we watch

The stale answer. A policy changes, the help doc is updated, the assistant keeps citing the old one until the index catches up. We reindex on document change and watch answer age.
Over-escalation. Hand back too much and agents stop trusting it; it becomes a slower path to the same work. Escalation precision is the metric that catches this.
Under-escalation. Worse: answering a sensitive question it should have passed up. The sensitive-topic rules and the guardrail are aimed here, and these cases get human review in the eval set first.
The over-promise. A fluent reply that commits the company to something, a refund, a date, a discount, it cannot. The guardrail blocks commitments the assistant is not authorised to make.
Multi-turn drift. Over a long conversation the assistant loses the thread and answers the wrong turn. We cap context and, past a point, route to a human rather than guess.

Every conversation, its retrieved sources, its routing decision, and the agent’s edit are traced, so a bad reply can be replayed and explained.

What a sprint like this leaves behind

The assistant, its eval set, its routing thresholds, and the connection to the support tool, running in the client’s own stack. The team keeps working as they did; their edits quietly train it. Containment rises over the first months not because the model changed, but because the eval set and the retrieval learned from the queue, and that is the part the client owns outright.