# How data becomes grounding: Data 360 underneath an agent > Retrieval quality is a data modelling problem wearing an AI costume. The prompt is where teams look and almost never where the fault is. - Source: https://synconai.com/insights/data-360-agentforce-grounding - Publisher: SynconAI (https://synconai.com) - Desk: Data & Integration - Author: SynconAI Architecture Team, Solution & technical architecture - Published: 19 February 2026 - Updated: 29 August 2026 - Reading time: 9 minutes - Topics: Data 360, Agentforce, Grounding, Architecture, Retrieval ## Key points - An agent can only be as correct as the data model underneath it. Prompts cannot repair a retrieval problem. - Grounding is decided at four points: what you ingest, how you resolve identity, what you expose, and how it is described. - Two access paths bound what an agent can say: record sharing and content visibility. They are configured separately. - Freshness is a per-intent decision. Most service intents tolerate stale data far better than they tolerate an outage. --- A customer asks an agent when their order shipped. The agent answers confidently and gives the wrong date. The team spends a fortnight on prompt engineering. The actual cause was that the customer exists twice, once from the web store and once from the call centre, identity resolution never joined them, and the agent retrieved the profile with the older order against it. No prompt would have fixed that, and the fortnight was spent looking at the only layer that was working correctly. This is the most common shape of an Agentforce failure, and it is why the interesting part of grounding sits in [Data 360](https://www.salesforce.com/data/), which plenty of teams still know as Data Cloud, rather than in the agent. ## The path from source to answer There is a chain between a record in a source system and a sentence an agent says. Grounding quality is decided at four points along it, and each has a different owner and a different failure mode. | Point | The decision | Failure looks like | | --- | --- | --- | | **Ingest** | Which sources and which objects arrive at all | The agent says it has no information, when the business knows it does | | **Resolve** | How strictly identities are matched | The right answer about the wrong customer, or a customer split in two | | **Expose** | Which resolved fields the agent may retrieve | Correct data exists and is never used | | **Describe** | How those fields are named and explained | The right field exists, is exposed, and retrieval never selects it | Almost every grounding complaint we investigate resolves to one of those four rows. Knowing which one you are in takes about an hour and saves the fortnight. ::: takeaways When an agent is wrong about customer data, work backwards through ingest, resolve, expose, describe. Only reach for the prompt after all four are ruled out, which in practice is rarely. ::: ## Ingest: absence looks like ignorance The first question is unglamorous: is the data there at all. Programmes routinely connect a source system and assume that means the data is available, when what actually arrived was three objects out of eleven, because that was the scope of the initial connector work. The agent then behaves exactly as designed, reporting that it cannot find the information, and the business reads that as the AI being poor rather than the pipeline being partial. The related trap is refresh cadence. A source connected on a nightly schedule will answer questions about yesterday, correctly and confidently, and there is nothing in the answer to signal that it is a day old. If an intent depends on same-day data, nightly ingestion is not a smaller version of the right answer, it is the wrong architecture for that intent. Salesforce documents the connector surface on its [connectivity pages](https://www.salesforce.com/data/connectivity/data-cloud-connectors/), and the practical step is to write down, per intent, exactly which objects and which refresh cadence that intent requires. That document is what turns a vague sense that the data is connected into a checkable statement. ## Resolve: the failure that does not announce itself Identity Resolution is where grounding gets genuinely dangerous, and it is worth being precise about why. A **false split**, where one customer appears as two, is annoying and visible. The agent gives an incomplete answer, someone notices, and you go and fix the match rules. A **false merge**, where two customers are joined into one, is worse in a way that is easy to underrate. The agent now answers questions about a person using another person's data, confidently, with no error anywhere in any log. That is not a data quality problem. It is a data exposure, and it will be discovered by a customer rather than by you. ::: warn Loose match rules feel like progress because the unification rate goes up and the dashboard looks healthier. Tightening rules feels like regression for the same reason. Judge match rules on false merges found in sampling, never on the match rate. ::: The practical control is a sampled review: take resolved profiles that were built from more than one source, and have a human confirm they are genuinely the same person. Weekly at first. This is dull, and it is the only mechanism that catches a false merge before a customer does. ## Expose: two access paths, configured separately What the agent can retrieve is bounded by two independent models, and teams reliably audit one and forget the other. Record data is bounded by the sharing model, through the agent's running user. Knowledge and content are bounded separately, by their own visibility settings. An agent can be correctly restricted from a record and still surface an internal article describing the same information, because those two configurations do not know about each other. There is also a subtler effect worth naming. Unification changes what a single retrieval can assemble. A field that was safe when it required visiting four records is a different exposure once one query returns all four together, even though no individual permission changed. Salesforce's guidance on [cloud data security](https://www.salesforce.com/platform/cloud-data-security/) is the right starting point, and the org-specific work is yours. We set that argument out in full in [the security model behind an agent](/insights/agentforce-security-best-practices). ## Describe: the layer nobody owns This is the point most teams have never considered, and it is frequently the cheapest fix available. Retrieval selects fields based on how they are described. A field called `CUST_STAT_CD_2` with no description is invisible to retrieval no matter how correct its contents are. The same field named and described in the language a customer would use gets selected reliably. The work here is ordinary metadata hygiene: name fields in business language, write descriptions that say what the field means and when it is populated, and retire the duplicates that arrived from three different source systems. It is unglamorous, it takes days rather than months, and in our experience it produces a larger improvement in answer quality per hour spent than anything else on this list. ::: tip Before commissioning any grounding work, run this test. Take your ten most common questions, and for each one ask whether a competent new employee could find the answer using only the field names and descriptions the agent can see. Where they cannot, retrieval will not either. ::: ## Fresh or current: decide per intent The architectural question that gets settled once and should be settled repeatedly: does the agent read the unified profile, or call the source system live. Unified data is fast, consistent, and can be stale. A live call is current and introduces a dependency that will eventually be unavailable while a customer is waiting mid-conversation. The instinct is to answer this globally, and the better practice is per intent. An order history question tolerates several hours of staleness without anyone caring. An account balance before a payment does not. A delivery status sits somewhere between, and where it sits is a business decision rather than a technical one. Write the tolerance down next to each intent. That single column turns an argument between architects into a question the business can answer. ## Diagnosing the shipped-date answer It is worth walking the opening example back through the four points, because the method matters more than the example. **Was it ingested?** Check whether an order with that date exists in the unified profile at all. If it does not, stop here: this is an ingestion or refresh problem and nothing downstream is at fault. This takes minutes and rules out the cheapest cause first. **Was it resolved?** Search for the customer by every identifier you hold: email, phone, account number, loyalty ID. If more than one profile comes back, you have a false split and the agent answered from whichever one it found. If one profile comes back but contains orders the customer does not recognise, you have a false merge, which is the more serious finding and should be escalated rather than tuned quietly. **Was it exposed?** Confirm the field is within reach of the agent's running user. A field present in the profile and outside the running user's visibility produces exactly the same symptom as a field that was never ingested, which is why these two get confused so often. **Was it described?** If the field is present, resolved and exposed, look at its name and description. A shipped date stored in a field called **DT_02** with an empty description is unlikely to be selected when a customer asks when something shipped, and the agent will reach for whatever date field is better labelled instead. In the case that opened this article the answer was the second: two profiles, never joined, because the web store held an email address and the call centre held a phone number and nothing in the match rules connected them. ## Instrument so the diagnosis is possible The walkthrough above assumes you can see what the agent retrieved. Many deployments cannot, and that single gap turns a one-hour diagnosis into a fortnight of speculation. Three things are worth logging from the first day. **The profile identifier the agent resolved to.** Without this you cannot tell a false merge from a bad answer, because both look identical in the transcript. **Which fields retrieval selected.** This separates a describe problem from an expose problem, which are the two most easily confused and have completely different fixes. **The age of the data returned.** A correct answer from stale data is indistinguishable from a wrong answer unless you record when the underlying record last refreshed. None of these are visible in a conversation transcript, and all three are cheap to capture while you are building. Retrofitting them onto a live agent is possible and considerably less pleasant, and you will want them precisely when something has gone wrong and everyone is asking questions. ## Copy or reference, for grounding specifically Zero Copy changes the storage economics of unification, and it is worth being clear about what it does and does not change for an agent. What it changes is the duplicate-copy tax. Data that stays in a warehouse and is referenced rather than ingested is data you are not paying to store twice, and the profile can still be assembled across it. What it does not change is latency physics or availability. A referenced source is still a source that has to answer when the agent asks, and if it is slow or down, the agent is slow or answering without it. For a marketing segment built overnight that is irrelevant. For a customer waiting in a chat window it is the whole question. The practical rule we apply: reference for breadth, copy for the fields on the critical path of a live conversation. An agent that assembles most of its context from referenced sources and holds a small, fast set of copied fields for the intents customers actually wait on gets the economics without the exposure to a dependency it cannot control. ## What this means for sequencing The consequence for planning is the part most programmes get wrong. If an agent use case depends on unified customer data, the schedule is set by the unification, not by the agent build. Agent configuration is measured in days. Getting four source systems ingesting reliably, tuning match rules until sampling is clean, exposing and describing the right fields, and agreeing freshness per intent is measured in months. That is not an argument against doing it. It is an argument for scoping it as what it is: a data programme with an agent at the end, funded and staffed accordingly. The use-case scoring that makes this visible before anyone commits is in [Agentforce use cases that survive a business case](/insights/agentforce-use-cases), and the pre-ingestion decisions that make the unification worth having are in [getting Data 360 right the first time](/insights/data-360-implementation-best-practices). The teams who treat grounding as a configuration step inside an AI project are the ones who discover, four months in, that they are running a data migration nobody budgeted for. The teams who name it up front tend to ship later and stay live.