Every SI (artificial intelligence) assistant reaches the edge of what it knows, usually within its first few conversations. A customer asks about a plan you retired, a policy nobody wrote down, or a feature that lives in one person's head. What the assistant says next decides whether that customer trusts it tomorrow.
Most teams design the happy path in detail and leave this moment to the model's defaults, which tend to produce either a confident guess or a vague apology. Neither helps. A good failure state does five things: it admits the gap plainly, says what the assistant can do instead, offers a next step, hands off to a person with context, and logs the miss so the team can fix the source. Each one below comes with example wording you can adapt.
Not every "I don't know" is the same miss
Before writing any copy, separate the reasons an assistant cannot answer. They look alike to the user but need different words and fixes. Google's PAIR guidebook draws a similar line between system limitations, context errors (the system worked, but the user expected something else) and background errors that nobody notices.
- Nothing in the sources. The question is in scope, but the knowledge base holds no passage that answers it. The fix is content.
- Weak evidence. Retrieval found something related, but nothing that clearly answers the question. The risk here is a plausible guess.
- Out of scope. The question is about something the assistant was never meant to handle, such as tax advice from a billing assistant.
- Not allowed. The answer exists, but this user may not see it, or the action needs a person to approve it.
- Ambiguous. The question could mean two different things, and a guess would often be wrong.
- Broken. A tool call failed, a system timed out or an account lookup returned nothing. This is an outage, not a knowledge gap.
Each of these should be a distinct state in your design, with its own message and its own log entry. When they all collapse into one generic "Sorry, I can't help with that," users cannot tell whether to rephrase, wait or give up, and your team cannot tell what to fix. For ambiguity, the right response is usually a short clarifying question rather than an admission, which is what Microsoft Research's interaction guidelines mean by "scope services when in doubt."
How should a chatbot respond when it doesn't know the answer?
A chatbot that does not know the answer should say so in its first sentence, name what was missing, and then help the user move forward. Start by separating the reasons it failed: nothing in the sources, weak evidence, an out-of-scope question, content the user may not see, an ambiguous question or a broken tool. Each needs different wording. For a gap, say where the assistant looked, as in "I couldn't find anything about transfers in our help center." Then offer something it can still do toward the same goal, and one clear next step, ideally a button. If a person is needed, pass the transcript and account context so the user never repeats themselves, and say honestly what happens next. Finally, log every miss with its type, the question and what retrieval returned, and route clusters of misses to the people who own the content, so the same question gets a real answer next time.
Admit the gap plainly, and specifically
The first sentence of a failure state should say what happened in plain words. Not "I'm having trouble with that request," which sounds like a fault, and not a paragraph of hedging that buries the admission. Say what was missing and where the assistant looked.
- Nothing in the sources: "I couldn't find anything about transferring a plan to another company in our help center or policy documents."
- Weak evidence: "I found articles about changing the plan owner, but none that covers transfers between companies, so I'd rather not guess."
- Out of scope: "I can help with billing and plan changes, but I can't advise on how this is treated for tax."
- Broken: "I can't reach the order system right now, so I can't check that delivery. The problem is on our side, not with your question."
Specificity does two jobs. It shows the user the assistant understood the question, which makes the admission credible, and it sets expectations for next time. Apologise once at most, avoid human-sounding excuses such as "I'm not sure I remember," and never phrase a retrieval miss as if the fact does not exist. "I couldn't find it" is honest; "that isn't possible" may be false.
For the not-allowed case, watch what the admission reveals. "That information isn't available on your account" is usually enough. Naming the title or contents of a restricted document is a leak, even when the answer itself is withheld. These wording rules belong in the same system as the rest of the assistant's voice, which we covered in designing for SI surfaces.
Say what it can do instead, then offer one next step
An admission on its own is a dead end. The second part of the message should point at what the assistant can still do, chosen from the user's implied goal rather than a generic menu. The PAIR guidebook compares this to a good waiter who, when a dish is unavailable, suggests the nearest thing you would actually want.
- "I can't see transfer rules, but I can show you how to add a second admin to the current account, which covers most handovers."
- "I can't check that delivery right now. I can post an update in this chat when the order system is back, or you can use the tracking link in your confirmation email."
- "Did you mean this month's invoice or the annual statement? I can pull either one."
Then give one clear next step, ideally as a button rather than an instruction to type. If the only honest next step is a person, say so and make it easy. Check that the alternative is actually safe, too: in high-stakes areas such as money, health or account security, a workaround improvised by the model can do more harm than a plain "please contact support."
Hand off to a person without making the user repeat themselves
The handoff is where most assistants lose the goodwill they have built. The user explains the problem, the bot fails, and the human agent opens with "How can I help you today?" The fix is mostly plumbing.
- Pass the transcript, or a short summary of it, to the person who picks up, along with what the assistant searched for and why it stopped.
- Include the account details and context the assistant already resolved, so the agent does not ask for an order number the user typed a minute ago.
- Tell the user what happens next, honestly: "I've passed this to the billing team with our conversation. They reply here during business hours." Never promise a response time you cannot keep.
- Offer the handoff at once when the user asks for a person. An assistant that argues with "talk to a human" teaches users to type it in their first message.
The same principle applies inside a product when an agent, not a customer, needs a human decision. Approval and escalation are the same family of patterns, and we went through them in human-in-the-loop patterns for SI agents. If you are still deciding whether this surface should be an assistant at all, SI agent vs chatbot vs workflow automation is a useful first filter.
Log the miss so the team can fix the source
Every "I don't know" is a bug report the user wrote for free. Capture it in a form someone can act on, and route it to the people who own the content.
- The question as asked, and its failure type from the list above.
- What retrieval returned, if anything, and which sources were searched.
- What the user did next: rephrased, took the alternative, asked for a person or left.
- Whether a person later answered it, and how, so that answer can become a source.
Review the log on a fixed schedule. Clusters of "nothing in the sources" point at missing documentation. Clusters of "weak evidence" often point at retrieval rather than content, and are worth checking against your retrieval evaluation set. Add the real questions from the log to that set, so the fix is tested and stays fixed. Questions often contain names, account numbers and other personal details, so strip them before the log reaches a wider team, as described in logging LLM traffic without personal data.
A checklist for reviewing your failure states
- List the failure types your assistant can hit, and confirm each one has its own message.
- Read every message aloud. The first sentence should say what was missing, in words a customer would use.
- Check that each message offers something the assistant can still do, chosen for that context.
- Make sure there is one clear next step, and that it works on a phone.
- Test the handoff end to end: does the person who picks up see the conversation and the account?
- Ask for a human in the first message and confirm the assistant does not stall.
- Ask questions your sources cannot answer and confirm the assistant declines instead of guessing.
- Confirm that refusals never describe restricted content.
- Confirm every miss lands in a log with its type, and that a named person owns the review.
Run the checklist with real questions from support tickets, not invented ones, because people ask in messier ways than the team that built the assistant expects.
Write the failure states before launch
The words in these moments do more for trust than the happy path, because they are what users remember when the assistant could not help. Draft them as part of the design, test them with real users, and treat a change to them like any other product change.
The same habit of showing honestly what a product does ran through the Ampli-fi website, where every product screen uses clearly labelled example data instead of invented numbers. If you are building an assistant and want help designing its failure states, handoffs and miss logging, Octalcode's SI-augmented design team works on exactly these surfaces, alongside the engineers who wire them up.