TLDR
- Enabling Agentforce provisions Data Cloud in your org. That is why the answer looks like "yes" from the setup screen. Provisioned is not implemented.
- If your agent reads and writes CRM records, you do not need a Data 360 modelling project. Flow actions, Apex actions, and prompt templates with record merge fields cover it.
- You genuinely need Data 360 when the agent must answer from unstructured content, or when it needs one identity-resolved profile across systems that do not share a key.
- The work that actually decides whether an agent behaves is upstream of both: duplicate records, ownership accuracy, picklist consistency, and field-level permission hygiene.
- Budget the remediation before the platform. Teams that sequence it the other way pay for ingestion of data they later have to clean anyway.
Where this sits: this post is about the architecture decision. For the license and Flex Credit numbers, see the Agentforce pricing guide. For everything license pricing does not cover, see Agentforce implementation cost in 2026.
The Short Answer
No, Agentforce does not require you to buy and build Data Cloud for every agent.
Yes, Agentforce requires Data Cloud for a specific and fairly well-defined set of capabilities.
The confusion is real and it has a cause. When you turn Agentforce on, Salesforce provisions Data Cloud in the org. You will see Data Cloud objects, a Data Cloud setup node, and Data Cloud terminology in the Agent Builder interface. From an admin's chair that looks like a hard dependency. Then a partner quotes a Data 360 implementation and the number is large enough to stall the project.
What actually happened is that two different things got collapsed into one word. Data Cloud as a provisioned platform capability arrives with Agentforce. Data Cloud as an implemented data programme (ingestion pipelines, data streams, data model objects, identity resolution rulesets, retrievers, indexes) is a separate project with separate cost and separate prerequisites.
You need the second one less often than you have been told.
"Data Cloud is enabled" is a provisioning fact. "Data Cloud is implemented" is a project outcome. An Agentforce pilot can succeed on the first without the second. Vendors quoting a Data 360 build should be asked which grounding path they are proposing and why the cheaper path was ruled out.
How Agentforce Actually Gets Its Context
An agent is only as good as what it can see at the moment it answers. Salesforce gives you several ways to feed it context, and they differ enormously in cost and setup effort. This is the table that should drive the decision.
| Grounding path | What it reaches | Data Cloud needed? | Typical setup effort |
|---|---|---|---|
| Record context | The record the user is on, plus related records | No | Hours |
| Prompt template merge fields | Named fields on standard or custom objects | No | Hours to days |
| Flow actions | Anything a Flow can query or update | No | Days |
| Apex actions | Anything Apex can query, transform, or call out to | No | Days to weeks |
| MuleSoft / HTTP actions | External systems via API at runtime | No | Weeks |
| Data Library retrievers | Unstructured content: articles, PDFs, transcripts | Yes | Weeks to months |
| Unified profile grounding | Identity-resolved customer across sources | Yes | Months |
Read that column of "No" values carefully. Five of the seven grounding paths do not touch a Data Cloud implementation at all.
Record and prompt-template grounding
This is the cheapest useful thing Agentforce does, and it is badly underused. A prompt template can pull named fields off an Opportunity, its Account, its open Cases, and its recent Activities, then hand that structured context to the model. No ingestion, no data model objects, no retrievers.
If your use case is "summarise this account before my call", "draft a follow-up based on what was discussed", or "tell me why this deal slipped", you are in prompt-template territory. The engineering effort is measured in days.
Flow and Apex actions
Actions are how an agent does things rather than just says things. A Flow action lets the agent create a task, update a stage, log a call, or run a validation. An Apex action extends that to anything you can express in code, including callouts to systems Salesforce does not natively integrate with.
Actions are also where risk concentrates, because this is the point at which an agent writes to your org. That is a testing and permissions problem, not a Data Cloud problem. We cover it in why Agentforce pilots fail.
Where Data Cloud becomes non-optional
Two capabilities genuinely require it.
Retrieval over unstructured content. If the agent needs to answer from a 400-page policy PDF, a library of knowledge articles, or two years of call transcripts, that content has to be chunked, embedded into a vector index, and retrieved semantically at query time. That machinery is Data Cloud. There is no supported way to bolt a production-grade RAG pipeline onto Agentforce without it.
Identity resolution across systems. If "the customer" exists as a Salesforce Account, a billing record in NetSuite, a support identity in Zendesk, and a product login in your own app, and no shared key joins them, you need identity resolution rulesets to produce one profile. That is Data Cloud's core job and it is genuinely good at it.
When You Genuinely Need Data 360
Five scenarios where the answer is a clear yes.
1. Knowledge-grounded service agents. A customer-facing agent deflecting support volume needs to cite your actual documentation, not general knowledge. Retrieval over a knowledge corpus is the whole product. Data 360 is required.
2. Answers that must span unstructured history. "What has this customer complained about before?" is not answerable from picklists. It requires retrieval over case comments, emails, and transcripts.
3. Cross-system customer view with no shared key. Multiple source systems, no reliable common identifier, and a requirement that the agent reason about the whole relationship. Identity resolution is the only sane path.
4. Real-time behavioural triggers. Agent actions that fire on streaming signals such as product usage or web behaviour, where the trigger data never lands in CRM objects.
5. Volume that would break governor limits. When grounding needs to scan far more data than a synchronous Apex query can return, moving that workload into Data Cloud is an architecture decision, not a preference.
When You Do Not
Four scenarios where a Data 360 project is premature spend.
1. Internal agents over structured CRM data. Pipeline hygiene, forecast summaries, quote assembly, territory questions. All structured, all reachable by Flow and Apex.
2. Task execution rather than question answering. Agents that update records, create follow-ups, or route approvals do not need retrieval. They need well-scoped actions and permission review.
3. Small, stable document sets. If the corpus is a dozen documents that rarely change, the content can often be summarised into prompt templates or a custom object. Vector retrieval is the wrong tool for twelve PDFs.
4. Single-system customer data. If Salesforce is already the system of record and other systems key off the Salesforce ID, identity resolution has nothing to resolve.
A team scopes a Data 360 build for an internal RevOps agent whose entire job is reading and updating Opportunity records. Six weeks and a large invoice later, the agent still gives inconsistent answers, because the underlying problem was 11% duplicate Accounts and an ownership field that had not been accurate since the last territory change. Grounding architecture cannot fix data quality.
What Data 360 Setup Actually Involves
If you have decided you need it, here is the honest shape of the work. Vendors summarise this as "connect your data". It is more than that.
Source analysis. Which systems, which objects, which fields, what update frequency, what volume. This is where most estimates go wrong, because nobody counts the custom objects until week three.
Data stream configuration. Setting up ingestion per source, with mapping, refresh cadence, and error handling. Straightforward per stream, but the count is what hurts.
Data model mapping. Mapping source fields into the canonical model. Every unmapped or mis-mapped field is a future wrong answer.
Identity resolution rulesets. Defining match rules and reconciliation rules. Tuning these is iterative and requires someone who knows the business meaning of the data, not just its shape.
Retriever and index configuration. For unstructured content: chunking strategy, embedding, index refresh, and relevance testing. Relevance testing is the step teams skip and then regret.
Consumption governance. Data Cloud consumption is metered. Without limits and monitoring, a badly scoped retriever can generate meaningful spend quietly.
Validation. Proving the unified profile is actually correct for a sample of real customers. Non-negotiable, frequently cut.
The Remediation Work That Comes First
This is the part of the conversation that gets skipped, and it is the part that decides whether the agent is trustworthy.
Ingesting messy data into Data Cloud produces cleanly modelled messy data. Identity resolution on records with inconsistent name and address formatting produces confidently merged wrong profiles, which is worse than no merge at all. Retrieval over a knowledge base containing three conflicting versions of the refund policy produces an agent that cites the wrong one with total fluency.
The remediation that typically has to happen first:
Duplicate resolution. Not just running a dedupe tool, but deciding survivorship rules and fixing the intake process that created the duplicates. Otherwise you dedupe once and drift back within two quarters.
Ownership and territory accuracy. Agents surface records based on ownership and sharing. Stale ownership means the agent shows the wrong person the wrong pipeline.
Picklist and taxonomy consistency. Free-text where a picklist should be, or a picklist with 40 values of which 6 are used. Both degrade grounding quality.
Field inventory and deprecation. Most mature orgs carry a large tail of custom fields that are populated for a fraction of records or not at all. Mapping dead fields into a data model is pure cost. A technical debt audit is the usual way to find them.
Knowledge base deduplication and ownership. For retrieval use cases, someone has to own content freshness. Conflicting or outdated articles are the single largest source of confidently wrong agent answers.
Permission and sharing model review. Data Cloud does not automatically inherit CRM sharing semantics for every grounding path. What the agent can retrieve and what a given user is allowed to see need to be reconciled deliberately. A permissions audit is the right starting point.
In our experience running org audits, this remediation runs four to eight weeks for a mid-sized org with a few years of accumulated configuration. It is not glamorous and it is not optional.
The Readiness Checklist
Score yourself before you scope anything. This is deliberately narrow: it is about whether a Data 360 build would pay off, not general Agentforce readiness. For the broader version, use the 47-point Agentforce readiness checklist.
Use case definition
- You can state, in one sentence, the question the agent must answer or the action it must take.
- You can name the exact records or documents a human would open to do that job today.
- You have confirmed those sources are not already reachable via Flow, Apex, or a prompt template.
Data quality
- Duplicate rate on primary objects is known and below your tolerance, with survivorship rules agreed.
- Ownership data reflects the current territory or account assignment model.
- Required grounding fields are populated on more than 90% of relevant records.
- Picklist values in grounding fields are consolidated, with free-text alternatives eliminated.
Unstructured content, if applicable
- The knowledge corpus has a named owner and a review cadence.
- Conflicting or superseded documents have been retired, not just deprioritised.
- You have a relevance test set: 20 to 50 real questions with known-correct source documents.
Identity, if applicable
- Source systems and their identifiers are inventoried, and you know which pairs lack a shared key.
- Match and reconciliation rules have a business owner who can adjudicate edge cases.
Governance
- Consumption limits and monitoring are defined before ingestion starts.
- Field-level security and sharing expectations for agent-retrieved data are documented.
- You have a rollback plan for agent-initiated writes.
Fewer than 10 yes answers means the Data 360 conversation is premature. Fix the upstream items first and the platform decision gets both cheaper and clearer.
What This Does to Cost
Two separate budget lines, and conflating them is how projects get approved on bad numbers.
The platform line is licenses and consumption: Agentforce pricing plus Data Cloud credits. Those numbers, including per-conversation and Flex Credit rates, are broken down in the Agentforce pricing guide.
The services line is everything above: remediation, modelling, retriever tuning, testing, and the ongoing admin capacity to keep it working. That is covered in Agentforce implementation cost in 2026.
The trap is approving the platform line, discovering the services line in month two, and either stalling the project or shipping an agent nobody trusts. Scope both together or neither honestly.
A Decision Path You Can Actually Use
Work through it in order and stop at the first yes.
- Does the agent need to answer from documents, articles, or transcripts? Yes means Data 360.
- Does it need one profile across systems with no shared key? Yes means Data 360.
- Does grounding require scanning volumes beyond synchronous query limits? Yes means Data 360.
- Otherwise: build on prompt templates, Flow actions, and Apex actions. Spend the saved budget on data remediation and testing, and revisit Data 360 when a real retrieval use case appears.
Most internal RevOps and admin-support agents stop at step four. That is the finding that saves the most money, and it is the one least likely to come from a vendor selling a platform build.
How We Approach It
Clientell is a Salesforce services team with an AI agent option, not a platform vendor looking for a reason to sell you ingestion. That shapes the sequence we recommend.
We start with an org audit rather than an architecture diagram: duplicate rates, ownership accuracy, field population, automation overlap, and permission structure across the objects the proposed agent would touch. That produces a specific list of what has to be fixed and an evidence-based answer to whether Data 360 is actually on the critical path. Roughly speaking, most of the orgs we assess for a first agent do not need a Data 360 build for that first use case.
Where remediation is needed, we do it as services work with your admin team in the loop, because they are the people who will own the org afterwards. The agent capability adds capacity to that team, handling the repetitive audit-and-fix passes that nobody has time for, with a human approving changes before they land. It does not take the admin out of the loop, and any vendor telling you it should is describing a governance problem rather than a product.
If you want the assessment before committing budget, the Agentforce readiness audit covers the agent-specific questions, and the Salesforce data quality audit covers the upstream data work. Both produce a written findings document you can take to a vendor conversation, whether or not that vendor is us. If you would rather walk through it live, book a demo.
Frequently Asked Questions
Does enabling Agentforce automatically enable Data Cloud? Yes, Data Cloud is provisioned in the org when Agentforce is enabled, which is why the dependency looks mandatory in setup. Provisioning is not the same as an implemented Data Cloud programme with ingestion, modelling, and retrievers.
Can an Agentforce agent read Salesforce records without Data Cloud? Yes. Record context, prompt template merge fields, Flow actions, and Apex actions all reach CRM data directly without any Data Cloud modelling.
Do I need Data Cloud to ground an agent in Salesforce Knowledge? For production-grade retrieval across a real knowledge corpus, yes. The retrieval and indexing layer sits on Data Cloud. Very small, stable document sets can sometimes be handled through prompt templates instead.
What is Data 360? Data 360 is Salesforce's current branding for the Data Cloud platform. The underlying capabilities, ingestion, harmonisation, identity resolution, and retrieval, are the same ones people have been calling Data Cloud.
How long does Data Cloud setup take for Agentforce? For a scoped, single-use-case retrieval build, plan several weeks once data is clean. The variable that dominates the timeline is upstream remediation, which commonly runs four to eight weeks on its own.
Should we clean our data before or after implementing Data Cloud? Before. Ingesting unresolved duplicates and stale ownership produces cleanly modelled bad data, and identity resolution on inconsistent records can merge profiles incorrectly with high confidence.
Is Data Cloud consumption included in Agentforce licensing? Treat them as separate lines. Consumption is metered and can move independently of agent licensing, which is why consumption limits and monitoring belong in scope from day one. Check current terms with Salesforce, as packaging has changed more than once.