# The grounding checklist we run before an agent talks to a customer > A demo agent answers anything. A production agent has a defined blast radius, a source for every claim, and a route to a human. The gap between them is mostly unglamorous data work. - Source: https://synconai.com/insights/agentforce-grounding-checklist - Publisher: SynconAI (https://synconai.com) - Desk: AI & Agentforce - Author: SynconAI Agentforce Practice, AI agents & automation - Published: 11 August 2026 - Reading time: 5 minutes - Topics: Agentforce, AI, Grounding, Guardrails, Service Cloud ## Key points - Scope first: an agent that can attempt anything will confidently attempt the wrong thing. - Every answer needs a retrievable source. If the content is not curated, the agent is improvising. - Escalation is a feature, not a failure. Design the handoff before you design the greeting. - You need an evaluation set before launch, not a dashboard after it. --- 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. :::warn The permission question people forget An agent acts under a user. Whatever that user can see, the agent can surface. Review the agent user's profile, permission sets and sharing the same way you would review a new integration user, because that is exactly what it is. ::: ## 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. :::tip What good looks like at week four Containment rate is the vanity metric. Track it, but read it next to escalation quality, repeat-contact rate within seven days, and the proportion of answers where retrieval returned the source a human would have used. An agent that contains 60% of contacts cleanly beats one that contains 85% and generates callbacks. ::: ## 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](/contact-us).