The architecture
user turn
│
├─ classify: question / action request / escalation signal
│
├─ resolve context: account, entitlements, open tickets, history
│
├─ retrieve: knowledge base, scoped to this user's permissions
│
├─ generate: grounded answer with citations
│
├─ act (optional): a bounded, permitted tool call
│
└─ decide: answered / clarify / escalateMost of this is RAG. What makes it a support assistant rather than a search box is the first and last steps: understanding what the user is actually trying to do, and knowing when to stop trying.
The context resolution step is what distinguishes an enterprise assistant from a public one. A user asking “why was I charged twice?” needs their account, their recent transactions and their open tickets in scope. Answering that question from a generic knowledge base is useless.
Grounding, and permission to fail
The single most valuable instruction in a support assistant's prompt is the one that lets it decline.
Answer only from the sources provided.
If the sources do not contain the answer, say so and offer to connect
the user with a human. Do not infer policy, pricing, or entitlements
that are not stated in the sources.Two structural supports for this. Cite sources on every substantive answer, so the user and any reviewer can check. And separate informational answers from commitments — the assistant may explain a policy; it should not promise a refund, waive a fee, or state an entitlement, unless a tool call has actually verified it.
Escalation is the important design
Escalation is usually treated as failure handling. It should be treated as a first-class path, because it is what the user remembers.
| Trigger | Signal | Action |
|---|---|---|
| Low retrieval confidence | Nothing relevant found | Escalate immediately — do not attempt |
| Explicit request | “Talk to a person” | Escalate at once, no friction, no retry |
| Repetition | Same question asked twice | The answer is not landing — escalate |
| Frustration | Sentiment or language shift | Escalate before it worsens |
| High stakes | Billing dispute, outage, cancellation | Escalate by policy regardless of confidence |
| Action beyond permission | Refund, contract change | Escalate with full context |
What must survive the handoff
The single worst pattern in support automation is the handoff that asks the user to start over. The human must receive the full transcript, the account context already resolved, the sources the assistant used, what it attempted, and why it escalated.
Done well, escalation makes the assistant valuable even when it cannot answer: it has already gathered context that the agent would otherwise spend three minutes collecting. That is a real productivity gain that survives the assistant being wrong.
Multi-turn state
Support conversations are rarely one question. State that must persist across turns:
- Resolved entities — which account, which site, which session is under discussion.
- What has been tried — so the assistant does not suggest the same failed step twice.
- Established facts — things the user has told you.
- Escalation posture — how close this conversation is to needing a human.
The common defect is dumping the entire transcript into the context on every turn. It works for five turns, then fills the window, and the earliest content — the system instructions and the user's original problem — is what gets truncated. The assistant then drifts, confidently, from a task it has partly forgotten.
Summarise older turns into a compact state object, pin the system prompt and the original request, and retrieve durable facts rather than carrying them. Same discipline as agent memory management.
Measuring it honestly
| Metric | Measures | Watch for |
|---|---|---|
| Resolution rate | Issues genuinely resolved | The number that matters |
| Escalation quality | Did the human get usable context? | Rarely measured, highly predictive of agent trust |
| Repeat contact rate | Same user, same issue, within 48h | The honesty check |
| Faithfulness | Answers supported by sources | Sampled review |
| Time to escalation | How long before a human is reached | Long times mean the assistant is obstructing |
| Containment rate | Conversations without a human | Do not optimise this |
Failure modes
| Failure | Cause | Mitigation |
|---|---|---|
| Confidently wrong policy | Retrieval missed; no permission to fail | Explicit refusal instruction; check recall |
| Loops on the same suggestion | No memory of what was tried | Track attempted steps in state |
| Escalates everything | Confidence threshold too tight | Tune against the golden set, not intuition |
| Escalates nothing | Containment being optimised | Add repeat-contact to the scorecard |
| Leaks another account's data | Retrieval not scoped to the caller | Filter inside the query — never post-hoc |
| Cites withdrawn policy | Stale index | Re-index on source change; carry effective dates |
| Tone mismatch in a crisis | One register for all situations | Detect high-stakes context and adjust |
The data-scoping row is a security incident rather than a quality issue. A support assistant sits directly on customer data, and the caller's permissions must be applied inside the retrieval query. This is the same rule as governance generally, and it matters most here because this is the surface an outsider talks to.
Production lessons
- Design escalation first. It determines whether users trust the system.
- Never optimise containment. Pair it with repeat contact rate or drop it.
- Give explicit permission to say “I don't know”.
- Separate information from commitments. Explaining a policy is not promising a refund.
- Pass full context on handoff. Making a user repeat themselves undoes any goodwill.
- Scope retrieval to the caller inside the query.
- Honour “talk to a human” immediately. No retry, no friction.
- Summarise state rather than replaying the transcript.
- Sample and review real conversations. Users do not report confidently wrong answers — they act on them.
Frequently asked questions
Three things: multi-turn state so the conversation holds context, the ability to take bounded actions through tools, and a designed escalation path to a human. The escalation design is what decides whether users trust it.
Because containment is trivially maximised by making escalation difficult, which is exactly what made earlier chatbots unpopular. Track repeat contact rate alongside it — if both rise together, the assistant is deferring problems rather than resolving them.
Immediately on explicit request, on low retrieval confidence, on repeated questions, on frustration signals, and by policy on high-stakes issues like billing disputes. The human must receive the full transcript, resolved account context, sources used and the reason for escalation — never make the user start over.
Instruct it to answer only from provided sources and to say so when they do not contain the answer, cite sources on every substantive response, and separate informational answers from commitments so it can explain a policy without promising a refund or waiving a fee.
Resolved entities such as which account or session is under discussion, what has already been tried, facts the user has stated, and how close the conversation is to escalation. Summarise older turns into a compact state object rather than replaying the whole transcript, which fills the context window and truncates the original request.