It should say so, and then something useful should happen. A well-built support agent that cannot find a grounded answer tells the customer it cannot confirm that point, hands the question to a person or books a follow-up, and logs the gap for the knowledge base owner. It must not guess, stall, or loop the customer.
Why is "I don't know" the right answer?
Because the alternative is worse. An agent without a source for its answer will produce one anyway if allowed, drawn from what sounds plausible. Customers act on those answers: they wait for a refund that is not coming, miss a deadline, pay a fee they did not owe. A clear "I can't confirm that" followed by a real next step costs the customer a little time. A confident wrong answer can cost them money and costs you their trust.
There is also a quieter benefit. Every "don't know" is a precise signal of a gap in your knowledge or systems. A human team absorbs gaps through experience and never writes them down. An agent's refusals can be counted, grouped and fixed.
What should the agent do, step by step?
- Recognise the gap. Retrieval returns nothing relevant, sources conflict, or the question needs data the agent cannot reach. Any of these means stop.
- Say so plainly. "I can't confirm that from the information I have." No hedged half-answer.
- Offer the best next step. A person now, a follow-up by a stated time, or a self-service route that does have the answer.
- Hand over with context. The note says what the customer asked, what the agent checked, and why it could not answer, so the person does not start again.
- Log the gap. The question goes on the knowledge base owner's list with the contact reason attached.
What does that look like by type of gap?
| Type of gap | Example | What the agent does | Who fixes it |
|---|---|---|---|
| Knowledge missing | A question about a new product feature | Says it cannot confirm; offers a person | Knowledge base owner |
| System data unavailable | The order system does not respond | Says it cannot check right now; offers a callback | Engineering |
| Sources conflict | Two articles give different return windows | Does not choose; hands over | Policy owner |
| Outside scope | A question about tax treatment of a payment | Says it cannot advise; points to the right route | Nobody: correct refusal |
| Needs judgement | "Is this charge fair?" | Explains the charge; offers a person for the judgement | Nobody: correct handover |
Two examples are worth singling out. Customers often ask about their bill in ways no article anticipates, and the agent should explain only what the billing record shows, as in whether an AI agent can answer questions about a customer's bill. And customers asked to re-confirm their identity documents frequently ask why; the general purpose of those checks is explained in what KYC is, but the reason for a specific request may sit in records the agent cannot see.
An illustrative example
Take a parcel delivery company whose agent answers on a messaging app. A customer asks whether a parcel can be redirected to a neighbour after it has left the depot.
The knowledge base covers redirection before dispatch but says nothing about after. The agent replies: "I can't confirm whether that's possible once a parcel has left the depot. I've passed your question to our delivery team, and they'll reply here within two hours." It hands over with the tracking number and the question. The gap is logged.
The delivery team answers the customer. The knowledge base owner sees the gap that week, adds an article, and the next customer who asks gets an answer in seconds. The same pattern for tracking questions is set out in answering order status questions with an AI agent, and the channel specifics in answering customers on messaging apps.
What controls make "don't know" work?
- Reward it in testing. Include cases where the right answer is "not covered" and score them as passes. An agent tested only on answering will learn to answer.
- Never a dead end. Every "don't know" comes with a next step. A bare refusal is a failure.
- Real follow-up times. Times quoted to customers come from the queue system or a published standard, not from the model.
- Gap log with owners. Each logged gap has an owner and a target date.
Customers judge agents heavily on these moments. How to tell whether they trust it afterwards is covered in how to know if customers trust an AI support agent.
Where Pryme fits
In Pryme, an answer without a supporting source is refused at the moment of action, and the verdict is filed with the reason. Attest's grounded and refusal gates check that the agent says "don't know" when it should. More is in the AI support agent that knows when to say no.
Questions people ask
Won't customers be frustrated by "I don't know"?
Less than by a wrong answer, provided a real next step follows. Frustration comes from dead ends, not honesty.
How many "don't know" answers are too many?
There is no fixed number. Look at the trend per contact reason: falling means gaps are being fixed; rising means the knowledge base is falling behind.
Can the agent search the web for an answer?
Not for anything about your products or policies. Web content is external and may be wrong or out of date.