Agentforce will answer a question whether it knows the answer or not. That’s the part teams miss when they go from a demo to production. In the demo, someone asks a question the agent happens to be grounded for, gets a clean answer, and everyone nods. In production, a customer asks something slightly off to the side of what the knowledge base covers, and the agent fills the gap with something plausible-sounding and wrong. Nobody flagged it because the answer read fine.
Grounding is the fix, and it’s not one setting. It’s a set of retrieval patterns you have to choose deliberately, test against real questions, and keep auditing after go-live. Get it wrong and you’ve built a confident liar with a Salesforce logo on it.
What grounding actually does
An Agentforce topic doesn’t reason from nothing. Before the model generates a response, Salesforce retrieves content it thinks is relevant (Knowledge articles, Data Cloud records, data from a prompt template) and stuffs it into the context the model sees. The model’s job then becomes summarising and rephrasing that retrieved content, not inventing facts. Strip the retrieval step out, or retrieve the wrong thing, and the model falls back on its training data and whatever pattern-matching gets it to a fluent-sounding answer.
That’s the whole mechanism. Retrieval-augmented generation isn’t exotic. It’s giving the model the right paragraph at the right moment so it has something true to paraphrase instead of something to guess.
The retrieval patterns worth knowing
Knowledge grounding
The simplest pattern: point a topic at a Knowledge action, let Salesforce’s built-in relevance search pull matching articles, and let the model summarise them. This works well when your Knowledge base is actually current and well-tagged. It falls apart fast when articles are stale, contradictory, or written for internal agents rather than customers. I’ve seen a contact-centre team ship this straight from a Knowledge base that hadn’t had a content audit in two years. The bot was technically grounded. It was grounded in wrong information, confidently delivered.
Before you turn this on, run a content audit. Not a vibe check, an actual pass through the top fifty articles your topic will retrieve from, checked against what’s actually true today.
Data Cloud vector search
For anything beyond FAQ-style content, you’re grounding against a vector database built from Data Cloud: unstructured documents chunked and embedded, searched by semantic similarity at query time. This is where most of the real engineering work lives. Chunk size matters more than people expect. Chunk too large and you retrieve a paragraph with the right answer buried in three unrelated ones, diluting the signal. Chunk too small and you lose the surrounding context that made the answer correct in the first place. There’s no universal number here. I’d start around 300 to 500 tokens per chunk with meaningful overlap, then tune against your own eval set rather than trusting a default.
Metadata filtering is the other lever that gets ignored. If your vector index spans multiple products, regions, or policy versions, retrieval without a metadata filter will happily pull a correct-sounding answer from the wrong product line. Tag chunks at ingestion time and filter at query time. It’s unglamorous and it’s the difference between a grounded agent and one that’s grounded in the wrong document.
Prompt template grounding
The pattern that gets underused: grounding directly off record data through a prompt template, rather than off a document corpus at all. If the customer is asking “what’s my order status”, you don’t need semantic search over a knowledge article. You need the actual Order record merged into the prompt. This is deterministic, cheap, and nearly impossible to hallucinate against, because the field value either exists or it doesn’t. Reach for this first whenever the ground truth is a structured record rather than prose. Save vector search for the cases where the answer genuinely lives in unstructured text.
Where teams get burned
The most common failure isn’t a bad retrieval pattern. It’s confusing retrieval with validation. Grounding reduces the chance the model invents something, but it doesn’t guarantee the model only says what was retrieved. A model can still misread a retrieved chunk, blend two retrieved passages into a claim neither one makes, or answer a question the retrieved content doesn’t actually cover while sounding like it does. I’ve watched a demo agent cite a real, correctly retrieved article and still get the eligibility criteria backwards, because the article covered two scenarios and the model merged them.
That’s why grounding and testing aren’t separable phases. You need an eval set: real questions, with the correct answer written down by a human who knows the domain, run against the agent regularly, not just before launch. Score for factual accuracy against the retrieved source, not just “did it answer in a reasonable tone.” A response can be fluent, on-brand, and wrong.
A practical build order
When I’m setting this up for a topic, the sequence is roughly: identify whether the ground truth is a record (use a prompt template, skip vector search entirely), a policy or process document (use Knowledge grounding, after a content audit), or genuinely unstructured and large (use Data Cloud vector search, with deliberate chunk size and metadata filters). Then write twenty to thirty real questions covering the edge cases your support team actually fields, not the easy ones. Run them before launch and after every content change, because grounding isn’t something you configure once. The source content keeps changing, and the retrieval behaviour needs to keep up with it.
None of this requires exotic tooling. It requires treating “what does the agent actually know, and where did it come from” as a question you answer on purpose, every time, rather than something you assume because the demo went well.