Retrievers in Data 360: the grounding layer that decides what your agent actually reads

There’s a failure mode in grounded agents that looks like a model problem and is almost never a model problem. The agent answers confidently, cites a document, and the answer is wrong — or stale, or from the wrong product line, or true but irrelevant to what the customer asked. Teams reach for a better prompt, a bigger model, a stricter Trust Layer. None of it helps, because the mistake was made one step upstream of the model: the wrong passages were handed to it in the first place.

That handoff is the job of the retriever, and it’s the most under-discussed component in the whole Data 360 grounding stack. People talk endlessly about the search index — keyword, vector, hybrid — and about which model the agent runs on. The retriever sits between them, and it’s the part that decides which indexed chunks actually reach the prompt. Get it right and the model has a fair shot at a grounded answer. Get it wrong and no prompt engineering in the world will save you, because the fact the agent needed never made it into the context window.

What a retriever actually is

Start with the pipeline, because the retriever only makes sense in its place in the chain. Retrieval-augmented generation (RAG) in Data 360 is the framework for grounding an LLM prompt by adding accurate, current, and relevant information from your own data before the model answers. The mechanics run in four stages:

1. Source. Structured records in a data model object (DMO), or unstructured content — knowledge articles, PDFs, web pages — landed into Data 360.
2. Search index. The content is parsed, chunked, and embedded into a search index. A single search index indexes exactly one DMO. This is the layer where you choose keyword, vector, or hybrid retrieval.
3. Retriever. The component that runs a query against the index at request time, applies your filters, and returns the top passages.
4. Prompt template or agent action. The retrieved passages get merged into a prompt, and the model answers using them.

The retriever is stage three, and the reason it’s a distinct, configurable object — rather than an invisible part of the index — is that the same indexed data can be queried in very different ways depending on the use case. One retriever might return three tightly filtered chunks from a single knowledge base; another might merge results across several indexes and rerank them. The index is the library; the retriever is the request slip that says exactly what to pull and how much.

The search index decides what can be found. The retriever decides what actually gets handed to the model. Those are different jobs, and conflating them is why so many “the agent is hallucinating” tickets are really retrieval-configuration tickets.

One convenience worth knowing up front: Data 360 automatically creates a retriever for every search index you build. That default retriever is the bridge between the index and a prompt template, and for simple cases it’s all you need. You build your own only when you need behavior the default doesn’t give you — specific filters, a chosen set of output fields, a tuned result count, or a merge across sources.

Individual vs. ensemble: the choice that shapes the answer

Data 360 gives you two retriever types, and picking the wrong one is a quiet source of bad answers.

Individual retriever

An individual retriever queries exactly one search index, which means it queries exactly one DMO. You reach for it when you need a custom retriever for a specific use case — a filtered view of one knowledge base, a particular set of return fields, a result count tuned to the prompt. It’s the workhorse. When your grounding data lives in one well-scoped place, an individual retriever is the right and simplest answer.

The constraint to internalize: one retriever, one index, one DMO. If your grounding needs to span a knowledge base and a set of product records and a table of policy documents, a single individual retriever can’t reach all three. That’s what the second type is for.

Ensemble retriever

An ensemble retriever bundles several retrievers into one. At query time it runs each member retriever, merges the result sets, and dynamically reranks the combined results by similarity to the query — so the most relevant passages float to the top regardless of which source they came from. The prompt template then references a single retriever instead of three, and the model sees one clean, relevance-ordered set of passages.

The ensemble isn’t just a convenience wrapper. It changes the economics and the quality of the answer in three ways:

• Better ranking across sources. Instead of stapling together three separate result blocks and hoping the model sorts out which matters, the ensemble reranks everything against the query, so a highly relevant chunk from source B outranks a marginal chunk from source A.
• Fewer irrelevant passages in the prompt. Merging and reranking lets it keep the genuinely relevant results and drop the filler, which keeps the context window focused.
• Lower cost and latency. Referencing one ensemble retriever instead of several individual ones in a prompt consumes fewer Einstein Requests, which reduces both latency and consumption cost.

The rule of thumb: individual retriever when your grounding lives in one place, ensemble when the answer legitimately spans sources. Don’t reach for an ensemble to paper over a data-model problem — if two of your “sources” are really the same entity split across DMOs, fix the mapping first. But when a support answer genuinely needs both the product manual and the customer’s entitlement record, the ensemble is what lets one retriever serve both.

The three settings that decide whether the answer is any good

Whichever type you build, three configuration choices do most of the work. They’re easy to skip in the setup wizard and expensive to get wrong.

Filters. A retriever can carry search filters that scope what it’s allowed to return — by default it’s set to return across all documents, which is exactly what you don’t want in a multi-tenant, multi-product, or multi-region knowledge base. This is the single most common miss. An agent for the North America consumer line should not be grounding on EMEA enterprise documentation, and the thing that stops it is a filter on the retriever, not a hopeful sentence in the prompt. Scope the retriever to the segment of data the use case is actually about.

Output fields. You choose which fields the retriever returns as grounding. More is not better. Returning a wall of every column pushes token cost up and dilutes the signal the model is trying to use. Return the fields that answer the question — the article body, the resolution steps, the policy text — and leave the internal metadata out of the context window.

Number of results. The retriever returns the top N chunks, and N is a real lever. Too few and the passage the agent needed sits at rank four while you asked for three. Too many and you’ve stuffed the prompt with marginal chunks that cost tokens and invite the model to latch onto the wrong one. There’s no universal number; it’s a tuning exercise against real questions, and it’s the first dial to move when an agent is almost getting answers right.

And one setting that isn’t about answer quality but about trust: enable citation settings so the retriever surfaces its sources. A grounded answer the user can’t trace back to a document is a grounded answer they won’t trust the second time it’s wrong. Citations are also how you debug retrieval — when an answer is off, the cited chunk tells you immediately whether the problem was retrieval (wrong chunk pulled) or generation (right chunk, bad summary). This is the same lineage-and-traceability discipline that separates an agent you can operate from one you can only apologize for.

Wiring a retriever into a prompt — and where the Data Library did it for you

Once a retriever exists, a prompt template consumes it. In Prompt Builder you add the retriever as a resource — Insert Resource → Retrievers → Configure Retrievers — and pass it the user’s query, so the template’s Knowledge Base Information is populated by the retriever’s results at generation time. The model then answers using both the question and the retrieved passages, which is what keeps the response tied to your indexed content instead of the model’s parametric memory. That prompt template, in turn, becomes an Agentforce action the agent can call.

Here’s the part that confuses people who go looking for the retriever they think they should have built: if you set up grounding through the Agentforce Data Library, the retriever already exists. Creating a Data Library provisions the entire stack in one motion — data streams, objects and mapping, a vector search index, a retriever, a prompt template, and the agent action — so the fastest path to working RAG never makes you touch a retriever by hand.

That’s genuinely the right starting point for most teams. The reason to understand the retriever anyway is that the day the Data Library’s defaults stop fitting — you need a filter it didn’t add, an ensemble across a source it doesn’t manage, a smaller result count to cut token cost — you have to drop down a layer and configure the retriever directly. The Data Library is the abstraction; the retriever is what it’s an abstraction over. Knowing the layer underneath is the difference between “the agent grounds fine” and “I can fix the agent when it doesn’t.”

Governance doesn’t stop at the retriever — and neither should your review

A retriever that returns the right chunks to the wrong user is a data-leak, not a feature. Filters scope what a retriever can return by topic or segment, but they are not a substitute for access control. Whether a given user is allowed to see a given record is enforced by the broader Data 360 governance and sharing model, and it’s a separate design task from tuning retrieval quality. Treat them as two reviews: one that asks “is the retriever pulling the relevant passages?” and one that asks “is this user allowed to see them?” The first is a quality problem; the second is a security problem; a good grounded agent has to pass both.

This is also why the data space a retriever lives in matters. Retrieval scoped to the correct data space is the coarse boundary; filters are the fine one; the sharing model is the security one. Design all three deliberately rather than discovering them when an answer surfaces something it shouldn’t.

The takeaway

The retriever is the least glamorous and most decisive part of grounding an agent on Data 360. The search index determines what’s findable; the retriever determines what the model actually reads. Build an individual retriever when your grounding lives in one index and one DMO; reach for an ensemble retriever when the answer genuinely spans sources and you want one reranked, relevance-ordered result set for less token cost. Then spend your time on the three settings that matter — a filter that scopes to the right slice of data, an output-field list tight enough to keep the signal clean, and a result count tuned against real questions — and turn on citations so you can trust and debug what comes back. Most teams should start with the retriever the Agentforce Data Library builds for them; the value of understanding the layer underneath is that you can fix it the day the defaults stop fitting. Getting the grounding layer right so an agent answers from your data instead of guessing is the heart of our Data & AI strategy work.

Understanding the basics

What is a retriever in Salesforce Data 360?

A retriever is the component that runs a query against a Data 360 search index at request time and returns the most relevant chunks to ground a prompt or an Agentforce agent. It sits between the search index and the prompt template: the index makes content findable, and the retriever decides which passages actually reach the model, applying any filters and returning the top results. Data 360 automatically creates a retriever for each search index, and you build a custom one when you need specific filters, output fields, a tuned result count, or a merge across sources.

What’s the difference between an individual retriever and an ensemble retriever?

An individual retriever queries a single search index — and therefore a single DMO — and is the right choice when your grounding data lives in one place. An ensemble retriever bundles several retrievers, runs them together, merges the result sets, and dynamically reranks the combined results by similarity to the query, so the most relevant passages surface at the top regardless of source. The ensemble also lets a prompt reference one retriever instead of several, which consumes fewer Einstein Requests and reduces latency and cost. Use an individual retriever for single-source grounding and an ensemble when the answer legitimately spans multiple sources.

Do I have to build a retriever myself to ground an Agentforce agent?

No. If you set up grounding through the Agentforce Data Library, it provisions the whole stack for you — data streams, objects and mapping, a vector search index, a retriever, a prompt template, and the agent action — so you never touch a retriever by hand for the common case. You configure a retriever directly when the Data Library’s defaults no longer fit: when you need a filter it didn’t add, an ensemble across sources it doesn’t manage, a different result count, or a specific set of return fields. Understanding the retriever is what lets you fix grounding when the abstraction stops fitting.

---

Building a grounded agent and finding the answers are almost-but-not-quite right? That’s usually the retriever, not the model. Talk to us — tuning the grounding layer so an agent answers from your real data is a normal week for our data and AI team.