Does Agentforce need Data Cloud? The honest Data 360 dependency map
Every Agentforce pricing call ends with the same question: do we have to buy Data 360 too? Here's the honest dependency map — what's provisioned free, what silently bills against it, and what genuinely requires a paid implementation.
The question always arrives about forty minutes into the pricing call, right after the Agentforce numbers land: “and do we need Data Cloud for this?” The answer you get depends on who’s in the room. The account executive says it’s included. The solution engineer says it’s required. The forum thread you read last night said you can skip it entirely. Somehow all three are telling a version of the truth.
The confusion is structural, not sales spin. Data 360 — the name Salesforce gave Data Cloud in October 2025 — relates to Agentforce in four distinct ways, and the words “need,” “included,” and “required” each attach to a different one. There’s the infrastructure Agentforce silently runs on, which is provisioned with the platform. There’s the grounding machinery — search indexes and retrievers — that lives on Data 360 whether or not you ever open its setup page. There’s the paid, implemented product with unified profiles and zero-copy warehouse access. And there’s the credit meter quietly ticking underneath two of the four.
This post maps the dependency honestly: what Agentforce does without any Data 360 implementation, what silently requires it, what’s genuinely better with it, and how the credits flow between the two products. By the end you’ll know which scenario you’re in — and, since this determines how you should negotiate the deal, we’ll say so plainly.
The short answer: provisioned, yes — purchased, it depends
Start with the unambiguous part. Salesforce’s own setup documentation for Agentforce developers states that Data 360 is required for the Einstein Trust Layer to function correctly, and must be turned on before you enable Einstein generative AI features. Trailhead is even blunter: Data 360 must be provisioned and enabled for all Agentforce use, and features like the Agentforce Data Library and the Einstein Trust Layer simply don’t work without it. So in the strict technical sense, yes — Agentforce needs Data Cloud. Every masked prompt, every audit record, every grounded answer touches it.
But “provisioned” is doing a lot of work in that sentence, and this is where buyers get spun around. Provisioning Data 360 means the infrastructure exists in your org. It does not mean you’ve implemented it — connected data sources, mapped objects, run identity resolution — and it does not mean you’ve bought a Data 360 SKU with a meaningful credit pool. Those are three separate things, and the gap between them is exactly where the honest answer lives.
The commercial side reflects this. Salesforce Foundations, included at no extra cost with Enterprise, Unlimited, and Einstein 1 editions, bundles access to Data 360 alongside Agentforce, with a free Flex Credit allocation (100,000 at the time Trailhead last documented it — the exact figures have shifted over time, so check the current Foundations terms). Salesforce Ben’s analysis of Agentforce misconceptions describes the same reality from the field: a full implementation and paid Data Cloud credits are not required — you can run Agentforce by “flipping the light switch” on Data Cloud via the zero-dollar SKU that Enterprise Edition customers get.
So reframe the question. Not “does Agentforce need Data Cloud?” — it does, and you almost certainly already have the entitlement. The real questions are: which Agentforce capabilities run on that provisioned instance, what do they consume, and at what point does your use case demand the actual paid, implemented product?
What Agentforce does without a Data 360 implementation
A useful amount, it turns out. Strip an agent down to its skeleton and it’s topics, instructions, and actions — and actions are just platform automation wearing a new interface. An agent that looks up an order, updates a case, books a meeting, or triggers a return is calling Flows, invocable Apex, and prompt templates against your CRM data. None of that requires you to ingest a single row into Data 360.
Concretely, an agent grounded only in the core platform can work with:
- CRM records and metadata. The agent reads and writes the same objects your users do, subject to the same sharing model. Case, Order, Account, custom objects — all reachable through standard and custom actions.
- Conversation context. What the customer said two turns ago is available to the planner without any data platform involved.
- Flow and Apex actions. Anything you can automate on platform — entitlement checks, callouts to your order system via named credentials, record updates — becomes an agent capability.
- Prompt templates with record merge fields. Grounding a prompt in the fields of the record at hand is native Prompt Builder behaviour, not a Data 360 feature.
For a service agent working a clean, well-modelled org, this is most of the job. In our experience the majority of first Agentforce use cases — order status, case deflection with structured data, appointment handling — are built almost entirely from this list. The billing for all of it runs on the Agentforce meter: Flex Credits per action, or the legacy per-conversation rate, not on Data 360 consumption.
One caveat keeps this section honest. Even here, the Einstein Trust Layer sits in the request path, and that layer depends on the provisioned Data 360 instance. You’re not implementing anything, you’re not paying for profile unification — but the plumbing is there, and it isn’t optional. “Agentforce without Data Cloud” is really “Agentforce without a Data Cloud project,” and that distinction matters for the next section.
What silently runs on Data 360: grounding, retrievers, and the audit trail
Here’s the part the pricing call tends to skip. The moment your agent needs to answer from content — knowledge articles, PDFs, your website — rather than from structured records, you’ve left Flow territory and entered retrieval-augmented generation. And in the Salesforce stack, RAG is a Data 360 workload, full stop.
The mechanism is concrete. The Agentforce Data Library — the standard way to ground agents in Knowledge, uploaded files, or web content — is described by Salesforce’s own training material as a quick-start that automatically configures a RAG solution with Data 360 using default settings. Under the hood, Data 360 ingests your content, splits it into chunks, converts the chunks to vector embeddings, and stores them in a Vector Data Model Object inside a Data Cloud search index. At runtime, a retriever queries that index and feeds the relevant passages into the agent’s prompt. Every grounded answer your agent gives is a Data 360 search operation.
This surprises teams because nothing in the agent-building experience says “you are now using Data Cloud.” You create a data library, point it at your Knowledge base, and it works. The ingestion, chunking, and indexing happen on infrastructure you may not know you have — which is precisely why Salesforce provisions Data 360 with Agentforce in the first place.
The Trust Layer has a similar hidden footprint. Einstein generative AI audit and feedback data — prompts, masked prompts, responses, toxicity scores, thumbs-up/down feedback — is stored in Data Cloud as a set of dedicated data model objects. Storing it is a setting you control, and Salesforce publishes separate billing considerations for audit and feedback data, because ingesting and querying that audit trail consumes Data 360 credits like any other workload. Turn it on — and for most regulated businesses you should — and your compliance trail becomes a small but permanent line on the Data 360 meter.
None of this requires you to buy a Data 360 implementation project. All of it requires Data 360 to exist and bills against its credit pool. That’s the “silent” dependency, and it’s the one your estimate is most likely to miss.
The dependency map, feature by feature
Laid out in one table, the pattern is easier to reason about than any yes/no answer:
| Agentforce capability | Runs on Data 360? | Needs a paid Data 360 implementation? | What it consumes |
|---|---|---|---|
| Actions on CRM data (Flow, Apex, record updates) | No — core platform | No | Agentforce Flex Credits (or conversations) |
| Prompt templates grounded in record fields | No — Prompt Builder | No | Flex Credits per prompt/action |
| Einstein Trust Layer (masking, policy enforcement) | Yes — provisioned instance required | No | Provisioning only |
| Audit trail and feedback storage | Yes — stored as Data Cloud DMOs | No, but it’s metered | Data 360 credits when enabled |
| Knowledge/file/web grounding (Data Library) | Yes — chunking, embeddings, search index | No, but it’s metered | Data 360 credits for processing, indexing, queries |
| Custom retrievers and search indexes | Yes — built in Data 360 | No, but it’s metered | Data 360 credits |
| Unified customer profiles (identity resolution) | Yes | Yes — real implementation work | Data 360 credits at material volume |
| Cross-system context via zero copy | Yes | Yes | Data 360 credits (federation, queries) |
| Calculated insights, segments feeding agents | Yes | Yes | Data 360 credits |
Read the middle column and the pattern jumps out: the line isn’t “with or without Data Cloud.” It’s between capabilities that merely run on the provisioned instance and capabilities that demand the implemented product. The top of the table is where most first agents live. The bottom is where the real Data 360 money — licences, credits, and consulting hours — actually goes.
Where the credits go: the licensing interaction nobody explains on the call
Two meters run under one deployment, and Salesforce’s own pricing examples acknowledge the split — the worked examples on the Agentforce pricing page carry a footnote that they don’t include other costs like Data 360 credits. The agent’s actions bill in Flex Credits. The agent’s grounding bills in Data 360 consumption. Same conversation, two ledgers.
The clearest official statement of the grounding side comes from Salesforce’s developer documentation on Agentforce billing, which spells out that when content sources are added through Data 360, Data 360 consumes Flex Credits or Data Services Credits to process, semantically index, and query that content — with named usage types for unstructured processing, intelligent processing, and querying. Which currency you burn depends on when you bought: Salesforce’s usage-type documentation distinguishes orgs on legacy Data Services credits from orgs that purchased or renewed after late February 2026, which can run on Flex Credits as the unified currency. If you’re renewing this year, ask which regime your paper puts you on — the fungibility of one shared credit pool across Agentforce and Data 360 is genuinely useful, and it’s worth confirming rather than assuming.
Scale matters here, so anchor it with the published numbers. On the Data Cloud platform services rate card, unstructured data processing lists at 60 credits per MB in production, while queries are cheap per unit; credits themselves list at $500 per 100,000. For a service agent grounding on a knowledge base measured in hundreds of megabytes, that’s typically hundreds of dollars a year, not tens of thousands — real, but not deal-shaping. The bill changes character only when you start unifying profiles or federating warehouse tables, because those usage types carry much heavier multipliers. Rates and packaging have changed several times, so verify the current rate sheet before you model anything.
Whatever you deploy, watch it in Digital Wallet, which breaks consumption out by usage type across both products. Turn the alerts on during the pilot. The teams that get surprised are the ones who discover the second meter on an invoice instead of a dashboard.
What a paid Data 360 implementation actually adds
Everything so far says you can go a long way on the provisioned instance. So what does the real product — the one with an implementation project and a credit commitment — buy an agent? Three things, and they’re substantial.
Unified profiles. An agent answering “where’s my order?” from CRM data sees what your org sees. If the customer’s commerce history lives in one system, their support history in another, and their marketing consent in a third, the agent’s picture is partial. Data 360’s identity resolution produces one profile from the fragments, and Trailhead’s Agentforce material is explicit that this is the difference between agents grounded in disjointed records and agents grounded in a unified, real-time customer view.
Cross-system context without migration. Zero copy lets Data 360 treat tables in Snowflake, BigQuery, Databricks, and other partner platforms as queryable objects without ETL. For agents, that means grounding in warehouse data — product telemetry, order history at scale, propensity scores — that will never live in your CRM. This is the capability that separates a personalization agent from a records clerk.
Insight-driven behaviour. Calculated insights (lifetime value, churn risk) and segments computed on unified data give agents something to reason with beyond raw fields. A retention agent that knows the caller’s value tier behaves differently from one that knows their case number.
Notice what’s absent from the list: basic knowledge grounding. You don’t buy Data 360 to make an agent answer from your help articles — that works on the provisioned instance. You buy it when the answers require data your CRM doesn’t hold.
Two scenarios that set your negotiation posture
All of this reduces to a question you can answer before the next call: does your agent need data that isn’t already in Salesforce?
Scenario one: a service agent on clean CRM data. Order status, case updates, FAQ deflection from Knowledge. Everything it needs is on platform. Your dependency map is the top half of the table — provisioned Data 360, Data Library grounding, audit trail — and your Data 360 exposure is a modest consumption line, not a licence. Negotiation posture: keep the deal an Agentforce deal. Model the grounding credits from the rate card, take the Foundations allocation, and politely decline any bundled Data 360 SKU you can’t tie to a named use case. If a large Data 360 line appears in the quote “because Agentforce requires it,” that’s conflating provisioning with purchase — push back with exactly that distinction.
Scenario two: a personalization or retention agent needing external data. Recommendations from commerce history in a warehouse, retention offers driven by churn scores, any use case where the phrase “single view of the customer” is load-bearing. Now the bottom half of the table is your critical path, and pretending otherwise just moves the cost from the contract to a mid-project change order. Negotiation posture: negotiate Data 360 explicitly and first — credit commitments sized from a proof of concept, zero-copy connections named, identity resolution scoped — because it’s the foundation the agent stands on, not an add-on. Buying Agentforce first and discovering the data project later is the most expensive sequencing mistake we see.
Most organisations are honestly in scenario one for their first agent and scenario two for their third. That’s fine. What’s not fine is signing scenario-two paper for a scenario-one project, or the reverse.
Understanding the basics
Is Data Cloud required for Agentforce?
Technically yes — Salesforce’s documentation states Data 360 (formerly Data Cloud) must be provisioned and enabled for all Agentforce use, because the Einstein Trust Layer, audit trail, and grounding infrastructure run on it. But provisioning is not purchasing: the entitlement comes with Agentforce via Salesforce Foundations on Enterprise Edition and above, and no paid Data 360 implementation is required to build agents that act on CRM data.
Does Agentforce grounding consume Data Cloud credits?
Yes. When an Agentforce Data Library or custom retriever grounds an agent in knowledge articles, files, or web content, Data 360 processes, chunks, indexes, and queries that content — and Salesforce’s billing documentation confirms this consumes Flex Credits or Data Services Credits under usage types like unstructured processing and querying. For typical knowledge bases the cost is modest, but it’s a second meter alongside Agentforce action pricing and belongs in any serious estimate.
When do I actually need to buy Data 360 for Agentforce?
When your agent needs data that doesn’t live in Salesforce. Unified customer profiles across systems, zero-copy access to warehouse tables, and calculated insights like churn risk all require a genuine Data 360 implementation with a sized credit commitment. A service agent answering from CRM records and knowledge articles doesn’t need any of that — so tie any Data 360 purchase to a named use case, not to the assumption that Agentforce demands it.
Trying to work out which half of the dependency map your Agentforce plans sit in — before you sign for the wrong one? Talk to us — we map this for buyers every week.
