Data 360 and Agentforce: Why Data Is the Foundation of Enterprise AI

When people talk about an agent being "grounded," they usually mean it can retrieve accurate, current, permissioned information before it generates a response. That sounds like a prompting or retrieval-architecture concern, and vendors often present it that way because it is easier to sell a retrieval feature than to sell a data remediation program. In practice, grounding is only as good as the object model, record quality and access boundaries underneath the retrieval layer.

An agent that queries a well-modeled account, contract and case history will answer a renewal question correctly because the underlying data already tells a coherent story. An agent that queries a fragmented set of near-duplicate accounts, orphaned contract records and cases logged against the wrong entity will answer the same question with equal confidence and no more accuracy. The agent does not know the difference. It has no independent means of judging whether what it retrieved is complete or correct.

This is why organizations that treat AI as a model-selection exercise are solving the wrong problem first. The sequencing that actually works starts with the data foundation, moves to a governed semantic layer, and only then introduces agent behavior on top. Reversing that order produces agents that are articulate but unreliable, which is a worse outcome than no agent at all because it looks like progress.

There is a meaningful difference between an agent that retrieves from structured, governed business objects and one that retrieves from a pile of unstructured documents. Document retrieval is useful for unstructured knowledge such as policy text, product manuals or historical correspondence. It is a poor substitute for structured, transactional truth such as current account status, entitlement, balance or open-case count.

A common failure pattern is standing up a retrieval-augmented pipeline over exported PDFs and email threads because it is faster to configure than fixing the underlying CRM and ERP records. That approach can answer general questions convincingly but will be systematically wrong on anything time-sensitive, because documents decay the moment they are exported and carry no referential integrity back to the live system of record.

The more durable pattern is to expose governed, harmonized objects, the kind Data 360 is built to produce, as the primary retrieval surface, and to reserve document retrieval for genuinely unstructured content. Agents built this way answer transactional questions from live, reconciled data and reserve generative synthesis for the parts of the answer that are genuinely unstructured, such as summarizing a policy exception or explaining a clause.

Duplication does not just create noise. It creates specific, predictable failure modes in agent behavior. An agent asked to summarize a customer's history against a duplicated account will summarize only the half of the history attached to the record it happened to retrieve, present it as complete, and give no indication that a second record exists. The user has no way to know the answer is partial because the agent's language is identical whether the underlying data is whole or fragmented.

Unresolved identity produces a subtler failure. Two individuals who are genuinely different people, matched incorrectly to a single profile, can cause an agent to disclose one person's information in a conversation initiated by another, or to recommend an action based on a blended and inaccurate transaction history. This is not a hypothetical edge case; it is the direct consequence of running conversational AI over an identity layer that was adequate for batch marketing segmentation but was never built to withstand a real-time, personalized conversation.

The fix is not a model-side safeguard. It requires match rules, survivorship logic and reconciliation processes at the data layer that resolve identity before an agent ever queries the record. Attempting to compensate for identity errors through prompt instructions or output filtering treats a structural problem as a cosmetic one.

Organizations under pressure to show AI progress often want to skip straight to agent deployment because that is the visible, demonstrable part of the program. A more durable path treats the data foundation as the first deliverable and the agent as the second. That does not mean a multi-year data program before any AI is visible; it means scoping the first agent use cases narrowly enough that the required data domain can be harmonized and verified in a realistic window.

In practice this looks like selecting one or two high-value agent use cases, identifying the exact objects and fields those use cases depend on, and running a focused harmonization and identity resolution effort against that scope rather than attempting an enterprise-wide data cleanup before anything ships. This keeps the program honest about what "AI-ready" actually means for the specific use case in front of it.

Once the first use case is live and its data foundation is proven, the scope of the trusted data layer expands to the next use case, and so on. Over several cycles, the organization ends up with a genuinely unified data foundation, built incrementally against real business demand rather than as a speculative upfront investment that risks stalling before it delivers anything visible.

Data foundations decay. New source systems get connected, sales teams create records outside the intended process, and integrations drift as upstream systems change their own schemas. A governance model that is treated as a one-time cleanup before an AI launch will start degrading the day after launch, and the agent's answers will degrade with it, usually without anyone noticing until a customer or employee flags something clearly wrong.

The more resilient approach treats data quality, identity resolution and access governance as standing operational functions with clear ownership, not as a project phase that ends. This means monitoring match rates, tracking duplicate creation at the point of entry, and reviewing the objects agents are grounded against on a regular cadence, in the same way a production application is monitored for uptime.

Agentforce and Data 360 are designed to work together in this continuous mode: Data 360 supplies the harmonized, resolved, access-governed data products, and Agentforce consumes them through defined retrieval patterns. Treating that relationship as an ongoing operating model, rather than a one-off integration, is what keeps agent output trustworthy as the business and its data keep changing.