How Agentforce Connects with Data Cloud in Salesforce

If you've been exploring Salesforce's AI capabilities, you've probably heard two buzzwords a lot: Agentforce and Data Cloud. They sound like two separate products — and technically they are — but together they form the real "brain and memory" combo that makes Salesforce AI agents actually useful in the real world.

In this post, I'll break down how these two pieces connect, using simple language, real-world analogies, and a diagram to help you visualize the flow.

First, a Quick Recap

Agentforce is Salesforce's platform for building autonomous AI agents — digital assistants that can understand a request, reason about it, take actions (like updating a record or sending an email), and respond to customers or employees, largely on their own.

Data Cloud is Salesforce's customer data platform (CDP). Think of it as a giant, organized warehouse that pulls in data from every corner of your business — CRM records, website clicks, purchase history, support tickets, even data sitting in external systems — and stitches it all together into one clean, unified view of a customer.

Here's the simple way to remember the relationship:

Agentforce is the brain that thinks and acts. Data Cloud is the memory that gives it facts to think with.

Without Data Cloud, an agent is smart but "forgetful" — it only knows what's in the immediate conversation. With Data Cloud plugged in, the agent suddenly has instant access to a customer's full history, preferences, and real-time context.

Why This Connection Matters

Imagine a customer asks an AI agent, "What's the status of my last order and can I get a discount on my next purchase?"

For the agent to answer well, it needs:

1. The customer's order history (maybe sitting in an e-commerce system)
2. Their support ticket history (maybe in Service Cloud)
3. Their loyalty tier or engagement score (calculated from browsing behavior)
4. Real-time inventory or promotion data

That's data scattered across multiple systems. Data Cloud's job is to unify all of this before the agent ever sees it, so the agent doesn't have to go hunting through ten different systems — it just asks Data Cloud, and gets a clean, trustworthy answer back in seconds.

The Diagram: How Data Flows from Sources → Data Cloud → Agentforce

Breaking Down Each Stage

Stage 1 — Data Sources

Everything starts with raw data scattered across your business: CRM records, purchase history, website behavior, support cases, even PDFs and emails. On its own, this data is messy and disconnected — which is exactly the problem Data Cloud solves.

Stage 2 — Data Cloud Does the Heavy Lifting

This is where the magic of organization happens:

• Ingest – Data Cloud pulls in data from all your sources, either in real-time (streaming) or in scheduled batches.
• Harmonize – Different systems label things differently (e.g., "Cust_ID" vs "CustomerNumber"). Data Cloud maps everything into one consistent format.
• Unify (Identity Resolution) – This is the standout feature. Data Cloud automatically figures out that "John D." on the website, "J. Doe" in support tickets, and "John Doe" in Sales are the same person, and merges them into a single Unified Customer Profile.
• Vectorize – For unstructured content like documents, chat transcripts, or knowledge articles, Data Cloud converts the text into embeddings (a mathematical representation of meaning), stored so they can be searched by meaning, not just keywords. This is what enables semantic search.
• Insights & Segments – Data Cloud can also calculate things like "Lifetime Value" or "Likely to Churn" scores (called Calculated Insights), and group customers into Segments, all of which agents can tap into.

Stage 3 — Agentforce Puts the Data to Work

Once the data is unified and organized, Agentforce connects to it through a few key mechanisms:

• Data Cloud Retriever – A configured connection that tells the agent exactly where in Data Cloud to look for relevant facts (a profile field, a segment, a knowledge article, etc.) when it needs an answer.
• Grounding – This is the process of injecting real, verified data into the AI's prompt before it generates a response, so the agent isn't guessing or "hallucinating" — it's answering from real facts.
• Atlas Reasoning Engine – Agentforce's reasoning layer. It looks at the customer's request, decides what information it needs, calls the right retriever to fetch it from Data Cloud, and plans the next step.
• Prompt Builder – The tool that merges Data Cloud data directly into the instructions given to the AI model, so responses are contextual and accurate.
• Topics & Actions – Once the agent has the facts it needs, it can trigger real actions: update a record, send an email, create a case, or apply a discount, using Flows, Apex, or Invocable Actions.

Stage 4 — The Response (and the Loop Continues)

The customer or employee gets a response that's actually personalized and accurate, because it was built on real, unified data rather than a generic guess. And here's the elegant part: the new interaction (what was asked, what was resolved) can flow back into Data Cloud, keeping the customer's profile fresh for the next interaction.

A Simple Analogy

Think of Data Cloud as a librarian who has spent months organizing a massive, chaotic library into a perfectly indexed system — every book cross-referenced, tagged, and easy to find.

Agentforce is the researcher who walks in, asks the librarian a specific question, gets handed exactly the right books and page numbers in seconds, and then writes up a clear, accurate answer.

Without the librarian (Data Cloud), the researcher (Agentforce) would be wandering the stacks alone, possibly grabbing the wrong book — or worse, making something up because they couldn't find the right one.

Key Terms to Remember

Term	What It Means
Unified Customer Profile	A single, merged view of a customer built from many data sources
Identity Resolution	The process of matching records that belong to the same real-world person
Data Spaces	Logical containers that separate data by brand, region, or business unit
Calculated Insights	Metrics Data Cloud computes automatically (e.g., churn risk, lifetime value)
Vector Database / Embeddings	A way of storing text so it can be searched by meaning (semantic search)
Grounding	Feeding an AI model real, verified data so its answers are accurate, not guessed
Retriever	The configured link that tells Agentforce where to fetch data from in Data Cloud
Atlas Reasoning Engine	Agentforce's "thinking" layer that plans steps and decides which actions to take

Why This Matters for Your Business

When Agentforce and Data Cloud work together, you get AI agents that are:

• Accurate – Answers are grounded in real, verified customer data, not guesses.
• Personalized – Every response reflects the customer's actual history and preferences.
• Fast – Data is pre-unified, so agents don't need to query five different systems live.
• Trustworthy – Since answers are grounded in real data, there's far less risk of AI "hallucination."
• Always improving – Every new interaction adds fresh data back into the profile, making future responses even sharper.

Final Thoughts

At the end of the day, Agentforce is only as good as the data it can see. Data Cloud is what gives it that sight — a single, unified, real-time view of the customer, ready to be retrieved the moment it's needed.

If you're implementing Agentforce, investing time in setting up Data Cloud properly (clean ingestion, solid identity resolution, well-structured Data Spaces) will directly translate into smarter, more reliable AI agents for your business.

Have questions about setting up your own Agentforce + Data Cloud integration? Feel free to reach out — happy to help you map it out.

lets Built a Multi-Agent Telecom AI Assistant on Salesforce — Then Gave Claude Access to It Too

Lets Built a Multi-Agent Telecom AI Assistant on Salesforce — Then Gave Claude Access to It Too

Most Agentforce demos you see online are a single agent answering FAQ questions. This is a capstone project I built to go further: a team of four coordinated agents that diagnose network outages, explain bills, walk customers through SIM replacement with real identity verification, and — the part I'm most excited to share — can be reached directly from Claude through a Salesforce MCP server. Here's the full build, architecture, and what I learned shipping it.

TL;DR: One customer-facing Orchestrator agent routes conversations to three specialists — Network Diagnostics, Billing & Plan Advisor, and Technical Support — all written in Agent Script, grounded in real Salesforce data, and backed by RAG for device manuals and policy documents. It's deployed two ways: as a live chat widget on an Experience Cloud self-service portal, and as a connector any Claude user can talk to via a Salesforce MCP server. Compliance isn't an afterthought — SIM replacement enforces KYC verification and OTP validation in the script itself, with mandatory human escalation on any failure.

The Business Problem

Telecom support has a shape most industries don't: the same customer conversation can touch a network outage, a confusing bill, and a broken modem in the same five minutes — and somewhere in there they might also need to replace a lost SIM, which means real identity verification, not just a friendly chatbot. A single-purpose bot answers one of those well and shrugs at the rest. The brief behind this capstone was explicit about that: multi-agent orchestration for support, diagnostics, and billing; RAG grounding against device manuals and service policies; omnichannel delivery through an Experience Site; and Agent Script-driven workflows for identity verification, SIM replacement, and number portability — the exact places where a hallucinating agent would be a genuine liability, not just an inconvenience.

Architecture at a Glance

The design keeps one agent owning the whole conversation. Instead of bouncing the customer between bots, the Orchestrator delegates to specialists as tools and keeps the context and the relationship — so a customer can mention a network issue and a billing question in the same thread without repeating themselves.

Four layers, top to bottom:

• Channels — the Experience Site chat widget, Claude via MCP, and voice.
• Orchestrator — a single Agent Script file that greets the customer, verifies identity, classifies intent, and hands off.
• Specialist subagents — each scoped to one domain, each with its own reasoning instructions and its own action list.
• Actions and data — Apex invocable actions, Flow actions, and knowledge/RAG retrieval, all sitting on top of standard field-level security so the agent never sees more than the requesting user could.

Meet the Agent Team

Agent	Job	Guardrails baked in
Orchestrator (Agent Router)	Greets the customer, confirms identity, classifies intent, routes to the right specialist, logs every routing decision	Never exposes internal object or API names to the customer; never invents an answer instead of pulling real data
Network Diagnostics	Checks outages by zip code, walks through device-specific troubleshooting, opens a ticket only after a remediation attempt fails	Won't open a duplicate ticket for an outage already being tracked
Billing & Plan Advisor	Explains invoices line by line, recommends plans based on real usage history, executes plan changes	Only processes a change through the dedicated Flow action, and only after the customer explicitly confirms the new plan and price
Technical Support	Device setup, Wi-Fi/modem troubleshooting, broadband installation scheduling, SIM replacement and activation	Never bypasses KYC, never skips OTP, caps retries at three attempts, escalates every security failure to a human

The Data Model Behind It

Nothing here is fictional plan copy — every answer the agent gives is grounded in actual records:

Object	Purpose
Account (Person Account)	Subscriber profile, KYC status, fraud risk flag
Product2	Plan catalog — data limit, price, contract term
Subscription__c	The customer's current plan/line
Device__c	Registered devices, warranty, firmware version
SIM__c	SIM/eSIM status and replacement history
Invoice__c	Billing history, payment status, late fees
Case	Service tickets, including agent-created diagnostics
OTP_Verification__c	Hashed OTP storage for identity checks
Network_Outage__c	Outage data keyed by zip code

Inside the Agent Script

This is where the project earns the "engineering," not just "prompting." Here's a trimmed, cleaned-up look at the Orchestrator's router logic:

start_agent agent_router:
  label: "Agent Router"
  description: "Welcome the user and determine the appropriate subagent based on user input"

  reasoning:
    | - Always greet the customer and confirm their identity before discussing
    |   any account-specific detail.
    | - If the user asks about a network_issue -> hand off to Network_Diagnostics_Agent.
    | - If the user asks a billing_question or requests a plan_change ->
    |   hand off to Billing_Plan_Advisor_Agent.
    | - If the user asks about technical_support (device/Wi-Fi/modem) ->
    |   hand off to Technical_Support_Agent.
    | - If the user asks about sim_replacement or number_portability ->
    |   invoke the corresponding subagent.
    | - Never expose internal system names, DMO names, or raw API responses
    |   to the customer.
    | - Never answer from a generic assumption — always answer from real
    |   retrieved data.
    | - Log every routing decision via the Log_Interaction action before closing.

    actions:
      go_to_Network_Diagnostics_Agent: @utils.transition to @subagent.Network_Diagnostics_Agent
      go_to_Billing_Plan_Advisor_Agent: @utils.transition to @subagent.Billing_Plan_Advisor_Agent
      go_to_Technical_Support_Agent: @utils.transition to @subagent.Technical_Support_Agent

Notice the two rules that do the most work: never expose internal system names and never answer from assumption. Those two lines are the difference between a demo and something you'd actually let a paying customer talk to — they force every specialist to ground its answer in a real Apex or Flow action instead of the model's own guess.

Compliance You Can Trust: The SIM Replacement Walkthrough

SIM replacement is the highest-stakes flow in the whole agent — get it wrong and you've handed a stranger someone else's phone number. So it's scripted deterministically, not left to the model's judgment:

The rules that make this safe are stated explicitly in the script itself, not just implied by good intentions:

• Never bypass KYC verification. If KYC_Status__c isn't Verified, processing stops immediately and the case escalates to a human — no exceptions.
• Never skip OTP validation, and never generate a random OTP and hand it to the customer directly — it's only ever sent to the registered email.
• Cap retries at three attempts. A fourth failed OTP entry escalates automatically.
• Every security-related failure escalates. The agent is never the last line of defense on identity.

That's the pattern worth stealing for any regulated workflow you put behind an agent: let the LLM handle the conversation, but let hard-coded logic — not model judgment — own the parts where being wrong actually hurts someone.

Going Live: Two Ways In

1. The Experience Cloud Self-Service Portal

This is the channel real customers use:

1. Enable Messaging Settings in Setup.
2. Configure Routing Configuration.
3. Create a Queue with Messaging Session as a selected object.
4. Build and publish a site in Experience Builder.
5. Commit and activate the service agent you want to deploy.
6. Create a new channel under Messaging Settings.
7. Create and publish an Embedded Service Deployment.

Once that's live, the chat widget on the portal is the Orchestrator — customers never know how many specialist agents are working behind it.

2. Bringing the Agent to Claude via MCP

This is the part worth a second look, because it's not something most Agentforce tutorials show: the same agent, reachable from Claude through a standard Salesforce MCP server.

1. In Setup, go to External Client App Manager and create a new external client app (e.g., "Claude Integration").
2. Enable OAuth settings, and set the callback URL to Claude's standard MCP callback: https://claude.ai/api/mcp/auth_callback.
3. Grant the OAuth scopes that matter here: Perform requests at any time (refresh_token, offline_access) and Access Salesforce hosted MCP servers (mcp_api).
4. Under Security, require PKCE for supported authorization flows, and issue JWT-based access tokens for named users.
5. Copy the Consumer Key and Consumer Secret.
6. In Claude, go to Settings → Connectors → Add Custom Connector, and paste in the org's MCP URL along with the Client ID and Client Secret.
7. Set tool permissions to Always allow, start a new chat, and confirm the connector is enabled for that conversation.

From that point on, anyone with the right access can ask Claude a question and have it reach into the same Salesforce org — same data model, same guardrails — through the org's MCP server, instead of only through the chat widget on the portal.

What Building This Taught Me

A few things stood out that don't show up in the Trailhead version of Agentforce:

• Guardrails belong in the script, not the prompt. "Never bypass KYC" reads like an instruction, but it only works because it's enforced as a deterministic branch, not a polite request to the model.
• Multi-agent only feels seamless if one agent owns the conversation. The moment you let the customer talk to three separate bots instead of one Orchestrator quietly delegating, the experience falls apart.
• MCP turns an agent into a platform. Once the Orchestrator is reachable through a standard MCP server, it stops being "a chatbot on our website" and becomes a capability other tools — like Claude — can use directly.

What's Next

Number portability is the next workflow to script the same way SIM replacement was — same compliance shape, different regulatory checks. I'd also like to push Data Cloud further upstream, so the Network Diagnostics subagent is reasoning over live telemetry instead of a periodically-updated outage object.

If you're building something similar — or you've hit the same "guardrails in the script vs. the prompt" question — I'd love to hear how you approached it in the comments.