The grounding checklist we run before an agent talks to a customer

Agent demos are easy. Somebody types a question, the agent answers in a friendly paragraph, the room nods. Then it goes near real customers and the failure modes arrive in a specific order: it answers questions it should have refused, it cites a knowledge article that was retired in 2023, it cannot tell two similarly named products apart, and it hands off to a human with none of the context the customer already gave it.

None of those are model problems. They are scoping, content and process problems that were skipped because the demo worked.

Here is what we make teams complete before an agent is allowed to speak to someone who is not on the project.

#Scope

1. Write the refusal list before the capability list

Teams naturally start with "what should it do". Start instead with what it must never attempt: pricing commitments, contractual terms, medical or financial advice, anything about an account other than the one in context, anything touching a legal dispute.

The refusal list is shorter to write, easier to get sign-off on, and it is the artefact that makes legal and risk comfortable. It also stops the scope creep where a Q&A agent quietly becomes an agent that issues refunds.

2. Name the top twenty intents, and only those

Pull the last quarter of real cases or chat transcripts and rank the intents by volume. Take the top twenty. That is version one. Every intent outside that list routes to a human without apology.

An agent that handles twenty intents excellently is a success. An agent that handles two hundred intents at 70% is a support ticket generator.

3. Decide read versus write, explicitly, per action

There is an enormous difference between an agent that reads an order status and one that changes a delivery address. Write actions need their own approval, their own audit trail, and usually their own confirmation step in the conversation.

#Grounding

4. Inventory the content the agent is allowed to cite

List every source: knowledge articles, product records, order data, policy documents, the site. For each one, answer three questions, who owns it, when was it last reviewed, and is it accurate today?

Content nobody owns should not be in scope. It will age, the agent will keep citing it, and the first person to notice will be a customer.

5. Retire before you index

Every organisation has knowledge articles that are duplicated, superseded or plain wrong. Humans navigate that by knowing which one is current. Retrieval does not. It will find the well-written obsolete article ahead of the terse accurate one.

Deduplicate and retire before grounding, not after the first bad answer.

6. Chunk for retrieval, not for reading

Long articles that cover eight topics retrieve badly, because the passage that matches the question drags in seven irrelevant topics. Split by answerable question. One article, one job.

7. Make the data model answer the question

If the agent needs to say "your order shipped on Tuesday", something must hold that date in a field the agent can read. A surprising number of grounding failures are just missing data: the status lives in the ERP, the agent is looking at Salesforce, and nobody built the sync.

Grounding work is data work. Budget for it accordingly.

8. Test the retrieval, not just the answer

Ask the question, then check which passages came back before you judge the wording. Good answers from wrong sources are worse than bad answers from right sources, because they are invisible until they are not.

#Guardrails and handoff

9. Design the escalation before the greeting

Write down the triggers: low confidence, out-of-scope intent, a detected complaint or vulnerability signal, three failed clarifications, an explicit request for a human. Then write down what transfers with the customer, the transcript, the identified account, the intent the agent believed it was handling, the actions it already took.

An escalation that dumps the customer into a queue to start over is the single fastest way to lose the trust the agent was supposed to build.

10. Decide what "I do not know" sounds like

It should be short, honest, and immediately followed by a route. Not an apology paragraph, not a guess dressed as a hedge. Write the exact wording and get it approved with the rest of the copy.

11. Log every interaction as an auditable record

For each conversation you want: the intent, the sources retrieved, the actions taken, whether it escalated, and the outcome. If this is not in place at launch, you have no way to answer the first question leadership will ask, which is "is it actually working".

12. Build the evaluation set before launch

Fifty to a hundred real questions, with the correct answer written by someone who does the job. Run them before every meaningful change to instructions, topics, actions or content. Without this you have no regression testing, and every improvement is a gamble.

#The honest summary

The work that makes an agent good is mostly not AI work. It is deciding what it may not do, cleaning up the content it will cite, filling in the data it needs to read, and designing the handoff for the moment it stops being the right answer.

Teams that treat those four things as prerequisites launch something useful. Teams that treat them as follow-up items launch a pilot that quietly gets switched off.

If you are scoping an agent programme and want a second read on the scope and grounding plan before you build, talk to an architect.