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.

Salesforce Interview Tips: How to Crack It in 2026

 

Let's be honest — the words "Salesforce interview" can make even a confident admin's stomach drop a little. You've done the Trailhead badges, you've got the certification, and yet that nagging voice still whispers, "What if they ask something I've never touched?"

Take a breath. Here's the good news: cracking a Salesforce interview in 2026 isn't about memorizing every object relationship on the platform. It's about showing up prepared, thinking like the person who'll actually sit in that seat, and demonstrating that you can solve real problems — not just recite definitions. This is your career-growth playbook, written the way a mentor would explain it over coffee, not the way a textbook would.

The interview has changed — and that's actually good news for you

If you interviewed for a Salesforce role a few years ago, forget what you remember. The bar has moved. Interviewers today expect solid platform fundamentals as the baseline, not the finish line. On top of objects, automation, and security, you're now expected to speak fluently about AI — specifically the difference between Einstein and Agentforce, and when to reach for one over the other.

That might sound intimidating, but here's the reframe: it also means fewer candidates are actually prepared for it. If you walk in with genuine hands-on understanding of automation-first design, data governance, and Agentforce judgment, you're already ahead of a big chunk of the room.

The diagram above lays out the shape of a typical modern loop — from your application screen all the way to the final panel. Not every company runs all five stages, and some compress the technical and AI rounds into one conversation, but knowing the shape of the game helps you prepare for each part deliberately instead of cramming everything into one giant study session.

What interviewers are silently scoring you on

Before we get to the tactics, it helps to know what's actually happening on the other side of the table. Most interviewers, whether they say it out loud or not, are quietly evaluating four things:

1. Do you actually understand the platform, or did you memorize answers? The difference shows up fast when they ask a follow-up "why."
2. Can you think in scenarios, not just definitions? Real Salesforce work is messy — duplicate data, sharing rule conflicts, a Flow that worked in sandbox and broke in production.
3. Do you know when not to use a shiny new feature? Especially with Agentforce. Knowing when a deterministic Apex trigger beats an autonomous agent is quickly becoming a senior-level signal.
4. Are you someone people will actually enjoy working with? Culture fit and communication carry real weight, especially at the recruiter stage.

Keep these four in your back pocket. Every answer you give should quietly check at least one of these boxes.

Career-growth use cases: the best scenarios to practice by role

Generic interview questions get generic answers. What actually moves the needle is practicing the kind of scenario-based questions that map to the role you want. Here are the sharpest, most realistic use cases to rehearse for each track — treat these as your practice reps, not just reading material.

Use case 1: For the aspiring Salesforce Admin — "The invisible record" problem

The scenario: A user says they can't see specific Opportunities even though their role assignment looks correct.

What a strong answer sounds like: Walk through it layer by layer — start with Organization-Wide Defaults to confirm the baseline visibility, then check role hierarchy, sharing rules, manual shares, and Opportunity Teams. Mention using the "View All Data" permission alongside the Sharing button on the record to trace exactly why access is or isn't granted.

Why this works: It shows you troubleshoot systematically instead of guessing, which is exactly the instinct an admin needs when a VP is annoyed on a Friday afternoon.

Use case 2: For the Salesforce Developer — "The governor limit trap"

The scenario: You're asked to review Apex code that runs a SOQL query inside a for loop.

What a strong answer sounds like: Explain bulkification — querying once outside the loop, storing results in a collection, and processing records in bulk to avoid hitting governor limits when 200 records get updated at once. Bonus points if you mention tools like ApexGuru-style code review habits that catch this pattern automatically now.

Why this works: Governor limits are the classic "do you actually build for scale" filter. Anyone can write code that works for one record; developers who get hired write code that survives a data load.

Use case 3: For the Consultant or Business Analyst — "The messy data problem"

The scenario: A client complains about duplicate Leads and Contacts clogging their reports.

What a strong answer sounds like: Propose Matching Rules and Duplicate Rules to catch new duplicates at the point of entry, a dedup tool for the existing backlog, and a longer-term data hygiene process — standardized input formats plus a recurring report to monitor drift over time.

Why this works: It shows you don't just fix the fire, you prevent the next one. That's the difference between a task-doer and a trusted advisor.

Use case 4: For anyone — "Agentforce or Apex?"

The scenario: The interviewer asks when you'd reach for an Agentforce agent instead of building custom automation.

What a strong answer sounds like: Draw the line clearly. Agentforce fits conversational, multi-step, context-dependent work — like a support agent handling varied customer questions. Apex and Flow still own deterministic, high-volume, auditable processes where you need predictable, repeatable outcomes every time. Mention grounding, the Einstein Trust Layer, and record context if the conversation goes deeper — those signal you understand how Agentforce stays accurate and compliant, not just that it exists.

Why this works: This single question is becoming one of the clearest ways interviewers separate candidates who've kept up with the platform from candidates who are coasting on older knowledge.

Use case 5: For the aspiring Architect — "The automation redesign"

The scenario: You inherit an org still running on Process Builder and Workflow Rules.

What a strong answer sounds like: Recommend migrating to Record-Triggered Flow, since Process Builder is deprecated and Flow is now the platform's primary automation tool. Explain the choice between before-save and after-save Flows depending on whether you're updating the triggering record or related records, and how that choice affects performance and DML usage.

Why this works: It proves you're not just aware Flow exists — you understand why the architecture choice matters for performance at scale.

The SOAR method: your secret weapon for behavioral questions

Technical prep gets all the attention, but behavioral questions are where good candidates quietly lose the room. When you get "Tell me about a time you handled a difficult stakeholder," don't ramble — structure it:

• Situation — set the scene in one or two sentences.
• Obstacle — what made it genuinely hard, not just busy.
• Action — what you specifically did (not "we").
• Result — the measurable or observable outcome.

This isn't a gimmick. Interviewers are trained to listen for structure, and a rambling answer — even a technically correct one — reads as less credible than a tight, well-organized one.

Certifications matter, but they're not the whole story

Certifications still open doors, especially for getting past resume screens and recruiter filters. But relying on the certification alone to carry the interview is a common and costly mistake. What consistently impresses interviewers more is a candidate who can point to a real Trailhead project, a mock implementation, or a portfolio org and say, "here's what I built, here's what broke, and here's what I changed." That kind of story is memorable. A list of certification logos is not.

If you're early in your career, build something. Spin up a Developer Edition org, implement a small end-to-end process — lead capture through opportunity close — and be ready to walk through the decisions you made and why.

Common mistakes that quietly sink good candidates

• Answering with textbook definitions instead of your own experience. If you can only describe what a feature is, not what you did with it, that gap shows.
• Not knowing the latest release notes. Salesforce ships three major releases a year. Interviewers notice when a candidate is still thinking in terms of a platform from two years ago.
• Treating Agentforce as a buzzword instead of a design decision. Say something specific about when you'd use it and when you wouldn't.
• Skipping the "what went wrong" story. Interviewers often want to hear about a failure you owned and fixed, not just your wins. It reveals maturity and production instinct.

Your pre-interview checklist

• [ ] Review the last two release notes (Spring and Summer, or whichever are most recent) so you can speak to current features confidently
• [ ] Prepare three SOAR-structured stories: a conflict, a technical failure, and a proud win
• [ ] Rehearse the five use-case scenarios above out loud, not just in your head
• [ ] Have one real project or Trailhead build ready to walk through in detail
• [ ] Prepare two or three smart questions to ask the interviewer about their org's actual challenges

---

The bottom line

Cracking a Salesforce interview isn't about becoming a walking encyclopedia of the platform. It's about proving you can think clearly under pressure, reason through real scenarios, and speak with confidence about where the platform is headed — Agentforce and all. Prepare with intention, practice out loud, and walk in knowing that the interviewer isn't looking for perfection. They're looking for the person they'd trust to solve the next messy problem their org throws at them.

Go get that offer.

Agent Script Tutorial: Build Your First Agentforce Agent, Step by Step.

I get some version of the same message every time I post about Agent Script: "okay, I get what the blocks *are* — config, subagent, actions — but how do I actually go from a blank file to something that works?" Fair question. My last post on this broke down the anatomy of a script. This one is the thing I wish existed when I opened my first blank .agent file and just stared at it for ten minutes.

We're building a real agent here — an internal IT Helpdesk assistant that resets passwords and files tickets — starting dead simple and adding complexity one block at a time. By the end you'll have a working two-subagent script and, more importantly, you'll know exactly what to Google when yours breaks.

TL;DR: We build an IT Helpdesk agent from a blank file — one subagent that handles password resets with identity verification, a second that escalates to a human when things get messy. Along the way you'll see every core block in context (not just defined in a table), plus the beginner mistakes that eat the most time and how to actually validate a script before you publish it.

Before You Open VS Code

You don't need much, but you do need these three things or you'll be debugging the wrong problem:

• An Agentforce-enabled org (a Developer Edition org works fine for this)
• A Salesforce DX project with Agentforce DX installed in VS Code
• An authoring bundle generated for a new agent — retrieve or create one and you'll get a file at force-app/main/default/aiAuthoringBundles/<Agent_API_Name>/<Agent_API_Name>.agent

That .agent file is a blank canvas the moment it's created. Let's fill it in.

Step 1: The Skeleton Every Agent Needs

Before any logic, an agent needs to know who it is. That's the config and system blocks — and honestly, this part trips up more beginners than the actual logic does later, because it's tempting to skip straight to the "interesting" part.

config:
  developer_name: "IT_Helpdesk_Agent"
  agent_label: "IT Helpdesk Agent"
  agent_type: "AgentforceServiceAgent"
  default_agent_user: "helpdesk_agent_user@yourorg.com"
  description: "Helps employees reset passwords and file IT tickets, escalating anything sensitive to a 
  human technician."

system:
  welcome: "Hi, I'm the IT Helpdesk assistant. Are you here about a password reset or something else?"
  error: "Something went wrong on my end — let me get a technician to help you directly."

Two things worth internalizing here, because they'll save you later:

• default_agent_user is not decorative. It's the actual Salesforce user whose permissions the agent runs with. If that user can't see a field or object, neither can your agent — no matter what your Apex action says.
• error isn't a fallback you'll never see. You will see it. Write it like a real message a stressed-out employee would actually want to read, not "An error has occurred."

Step 2: Give It Memory — Variables

Right now the agent has a personality but no memory. It can't track anything across the conversation yet — like whether the employee has actually verified who they are. That's what variables is for.

variables:
  is_verified: boolean
  employee_id: string
  reset_attempts: number

Think of these as the agent's short-term memory for this one conversation. Anywhere else in the script, you reference them as @variables.is_verified. This matters more than it sounds like it should — it's the difference between an agent that "remembers" verification happened versus one that re-asks the same question because it forgot three messages ago.

Step 3: Your First Subagent — Password Reset

This is where the actual behavior lives. A subagent is a self-contained chunk of logic — its own description, its own reasoning, its own available actions.

subagent password_reset:
  description: "Verifies employee identity and resets their Salesforce password."

  reasoning:
    instructions:
      "Ask for the employee's work email if not already provided ->
       If @variables.is_verified is false | Send a verification code and ask the
       employee to read it back before doing anything else.
       If @variables.reset_attempts > 2 | Stop and hand off to a human technician,
       do not attempt another verification code.
       Otherwise | Reset the password using the reset action and confirm
       completion in plain language."
    actions:
      - verify_employee_identity
      - reset_password

  actions:
    verify_employee_identity:
      description: "Sends a verification code to the employee's registered email and checks it against their input."
      target: apex://VerifyEmployeeIdentityAction

    reset_password:
      description: "Resets the employee's Salesforce password once identity is verified."
      target: apex://ResetPasswordAction

Read the reasoning.instructions block slowly, because it's doing two different jobs at once and beginners usually only notice one of them:

• The part before the -> is natural language — the LLM interprets it, same as a prompt.
• The If @variables.x lines after it are hard conditionals, evaluated against real variable values. The model isn't "deciding" whether reset_attempts is greater than 2 — it's a fact, checked deterministically.

That distinction is the entire reason Agent Script exists instead of just writing a longer prompt. A prompt can be talked out of a rule. A conditional can't.

Step 4: The Entry Point — start_agent

Right now you've got a subagent that works, but nothing tells the conversation to start there. Every script needs exactly one entry point:

start_agent agent_router:
  label: "Helpdesk Router"
  description: "Determines whether the employee needs a password reset or general IT support."

  reasoning:
    instructions:
      "If the employee mentions a password, login, or being locked out ->
       hand off to Password_Reset_Agent.
       Otherwise | ask a clarifying question about what kind of IT issue they're having."

  actions:
    go_to_password_reset: @utils.transition to @subagent.password_reset

Forget this block and your agent will validate fine but do absolutely nothing useful when a real conversation hits it — there's no door for the conversation to walk through. This is, without exaggeration, the single most common "why isn't my agent doing anything" issue I see from people just starting out.

Step 5: Add a Second Subagent — Escalation

Now let's make it feel like a real production agent instead of a demo. Three failed verification attempts shouldn't just dead-end — it should hand off to a human, cleanly.

subagent escalation:
  description: "Hands the conversation to a human IT technician when automated verification fails or the issue is
  out of scope."

  reasoning:
    instructions:
      "Apologize once, briefly — don't over-explain the failure.
       Confirm the employee's issue in one sentence so the technician has context.
       Transition to a live agent immediately after that confirmation."
    actions:
      - transition_to_human

  actions:
    transition_to_human:
      description: "Hands off the conversation to a human technician queue."
      target: flow://EscalateToHumanTechnician

Notice this action points at flow:// instead of apex://. That's deliberate, not a typo — Agent Script doesn't care whether the actual work happens in Apex or Flow, it just needs a target it can invoke. Use whichever your team already has, or whichever is easier for someone else to maintain after you.

How a Message Actually Moves Through This

This is the mental model that made everything click for me — worth having open in a tab while you're still getting a feel for how these blocks talk to each other.

Beginner Mistakes That Waste the Most Time

I've made every one of these myself, and I've watched other people make them too. Save yourself the twenty minutes of confused staring:

What Goes Wrong	Why It Happens	Fix
Agent validates fine but never responds	No start_agent block, so there's no entry point for the conversation	Every script needs exactly one start_agent
Agent keeps re-asking a question it already got answered	Answer was never stored in a variable — the model has no memory of it	Capture it in variables and reference with @variables.name
"Never do X" instruction gets ignored occasionally	Rule was written as prose in reasoning.instructions instead of an explicit conditional	Move hard rules into If @variables.x conditionals, not just sentences
Validation fails with no obvious reason	Usually a missing colon, wrong indentation, or a typo in a block name	Run AFDX: Validate This Agent after every small change, not just before publishing
Action never fires	The action's target doesn't match the real Apex method's @InvocableMethod name, or it's not listed under the subagent's actions	Double-check the target path and that it's referenced in both places
Confusing "topic" vs "subagent" in docs or old code	Salesforce renamed topics to subagents — same concept, different word depending on version	Just know they mean the same thing; don't rewrite working scripts over naming alone

Practices Worth Building Now, Not Later

• Validate constantly, not just at the end. Run AFDX: Validate This Agent after every meaningful edit. Catching a typo in a 10-line script takes ten seconds; catching it in a 200-line script takes ten minutes.
• Put hard rules in conditionals, not prose. If something must never happen — skipping verification, exceeding a retry limit — express it as an explicit If @variables.x check. Anything left as a sentence is a suggestion, not a rule.
• Name variables like you'll forget what they mean in six months. Because you will. reset_attempts beats x every time.
• Keep each subagent doing one job. The moment a single subagent's reasoning block starts handling three unrelated situations, split it. It's the same instinct as keeping an Apex method focused — easier to read, easier to test, easier to hand to someone else.
• Preview before you publish. Test the actual conversation flow from the script file itself. Reading the logic and watching it run are two very different confidence levels.
• Commit it like real code, because it is real code. The whole point of Agent Script is that it lives in your DX project — treat it with the same code review standards as an Apex class, not as a config file nobody looks at twice.

Where to Go From Here

You've now got a two-subagent agent with memory, a real conditional rule, and a clean human escalation path — which honestly puts you past where a lot of "finished" demo agents stop. The natural next step is chaining in a connected_subagent to hand off to a completely separate Agentforce agent, or grounding a subagent's answers in real data with RAG instead of a single Apex lookup. Both are just more of the same building blocks, arranged with a bit more intention.

Building your own agent right now and stuck on something specific? Drop it in the comments — I read every one, and "my conditional isn't firing" is usually a five-minute fix once I can see the actual script.

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.

 

Agent Script for Developers: Coding Agentforce Agents Like Real Software

Building an agent by clicking through Agentforce Builder works fine until your logic gets specific — "offer free shipping only if the order total is over $100 AND the customer is a loyalty member AND it's not already on backorder." At that point, natural-language instructions to an LLM start to feel like duct tape. Agent Script is Salesforce's answer: a real, readable scripting language purpose-built for agents.

TL;DR: Agent Script is a declarative, human-readable language for defining Agentforce agents — their subagents (formerly called topics), instructions, variables, and actions — as code instead of only as clicks. It blends natural-language reasoning instructions with deterministic if/else logic, lives in a .agent file inside your Salesforce DX project, and is fully supported in VS Code with syntax highlighting and validation. If you've ever wished you could put an agent under version control, this is how.

Why Developers Should Care

Agentforce Builder's canvas view is genuinely good for admins — natural language in, working agent out. But every agent eventually needs the same things any serious codebase needs: predictable branching logic, reusable structure, code review, and a diff you can actually read. Agent Script gives you all of that because, under the hood, every agent you build in Agentforce — whether through chat, canvas, or script — is Agent Script. The Script view just lets you work with it directly instead of through a UI abstraction.

That matters for a very practical reason: it puts agent definitions in your Salesforce DX project, next to your Apex and LWC, where they can be versioned, code-reviewed, and deployed the same way as everything else you ship.

The Building Blocks of a Script File

An Agent Script file is organized into a small number of named blocks. Once you recognize them, most scripts read top to bottom without much translation:

Block	What it holds
config	Core agent settings — developer_name, agent_label, description, agent_type, and which Salesforce user the agent runs as.
system	Agent-wide instructions and required messages like welcome and error.
variables	Named state the agent tracks across a conversation, referenced anywhere as @variables.<name>.
subagent	A self-contained unit of behavior — its own description, instructions, and available actions. This is where most of the actual logic lives.
start_agent	The entry point every conversation begins at; decides which subagent should handle the user's request.
connected_subagent	A reference to a different Agentforce agent in your org, so one agent can delegate work to another.

If "subagent" sounds like a rename, it is — Salesforce renamed topics to subagents in April 2026 with no functional change, so don't be surprised if you see both terms depending on which doc or org version you're looking at.

A Worked Example: Order Status, in Script

Let's script a small piece of the same order-status scenario from our last post — but this time controlling when the agent should hand off to a human instead of just answering.

config:
  developer_name: "Order_Support_Agent"
  agent_label: "Order Support Agent"
  agent_type: "AgentforceServiceAgent"
  default_agent_user: "order_support_agent_user@yourorg.com"
  description: "Helps customers check order status and escalates delayed orders to a human agent."

system:
  welcome: "Hi! I can help you check on an order — what's your order number?"
  error: "Something went wrong on my end. Let me connect you with a teammate."

variables:
  order_status: string
  days_delayed: number

subagent order_lookup:
  description: "Looks up an order's status and delivery estimate when the customer provides an order number."

  reasoning:
    instructions:
      "Ask for the order number if it hasn't been provided ->
       If @variables.days_delayed > 3 | Apologize for the delay before sharing status details.
       Otherwise | Share the order status plainly and offer to help with anything else."
    actions:
      - get_order_status
      - transition_to_escalation

  actions:
    get_order_status:
      description: "Calls Apex to retrieve status, delivery estimate, and delay in days for an order number."
      target: apex://OrderStatusAction

subagent escalation:
  description: "Hands off to a human agent when a delay is significant or the customer asks for a person."
  reasoning:
    instructions:
      "If @variables.days_delayed > 7 | Explain that a specialist will follow up and transition immediately.
       Otherwise | Ask one clarifying question before deciding whether to escalate."

A few things worth noticing:

• The line with -> inside reasoning.instructions is where Agent Script earns its keep. Everything before it can be plain natural language; everything after can be a hard conditional evaluated against a real variable — not something the LLM has to infer from conversation history.
• get_order_status here points at apex://OrderStatusAction — the exact custom Apex action with @InvocableMethod we built in the previous post. Agent Script doesn't replace Apex actions; it's the orchestration layer that decides when and whether to call them.
• Variables like days_delayed give the agent reliable memory instead of leaning on the LLM to remember and recompute values mid-conversation.

Three Ways to Write It (All Produce the Same Thing)

Salesforce is intentionally flexible about how you author a script:

1. Chat with Agentforce and describe what you want ("if the order's more than a week late, hand it straight to a human") — Agentforce converts that into subagents, actions, and instructions for you.
2. Canvas view — a visual, block-based editor where / inserts logic patterns like if/else and @ inserts references to subagents, actions, or variables.
3. Script view — write and edit the raw .agent file directly, with the same syntax highlighting and autocomplete you'd expect from any language extension in VS Code.

All three are the same underlying artifact. You can start in canvas view and drop into script view the moment the logic gets too specific for clicking — and back again.

Working in VS Code with Agentforce DX

If you'd rather live in your editor than in Setup, Agentforce DX brings the whole workflow local:

1. Generate or retrieve an authoring bundle for your agent into your DX project — it lands at force-app/main/default/aiAuthoringBundles/<Agent_API_Name>/<Agent_API_Name>.agent.
2. Edit the .agent file directly, or open the Agentforce Vibes panel to describe changes in natural language and let it edit the script for you.
3. Validate the file before you publish — VS Code's AFDX: Validate This Agent command (or the equivalent CLI command) checks that the script compiles and flags syntax errors with their exact location.
4. Preview the agent from the script file itself to test behavior before publishing it back to your org.

One habit worth building early: validate often, not just before a deploy. Agent Script errors are usually small — a missing colon, a typo in a block name — and they're far easier to fix one at a time than after you've written fifty lines on top of a broken block.

Where This Fits with What You Already Know

If you've spent time in Flow, a lot of this will feel familiar wearing different clothes: subagents are a bit like Flow's screen-by-screen structure, reasoning instructions are your decision logic, and actions are the same invocable Apex, Flow, and prompt-template building blocks Agentforce already supports. The real shift is that it's all expressed as one readable, versionable file instead of a set of linked records you navigate by clicking.

The Bottom Line

Agent Script doesn't replace Agentforce Builder — it's what Agentforce Builder is writing on your behalf every time you build an agent through chat or canvas. Once your agent's logic outgrows what feels safe to leave entirely to LLM interpretation, dropping into Script view (or straight into VS Code with Agentforce DX) gives you the same rigor you already expect from Apex: version control, code review, and behavior you can actually predict.

Have you tried writing Agent Script directly, or are you still building through canvas view? Let me know how it's going in the comments below.

Agentforce for Developers: Building Your First Custom Action with Apex

Everyone's talking about Agentforce from the admin side — click-based agent setup, prompt templates, topics and instructions. But if you're an Apex developer, the real question is different: how do I plug my own logic into an agent so it can actually do something in my org, not just talk about it?

TL;DR: Agentforce agents don't just answer questions — they take action by calling "actions" under the hood. The fastest way to give an agent real capability is an Apex class with an @InvocableMethod. Write the method, add a couple of annotations Agentforce reads to understand what your code does, deploy it, wire it up in Agentforce Builder, and your agent can now query, update, or trigger anything Apex can reach.

Why This Matters for Developers Right Now

Admins can build a lot with Agentforce out of the box — Flow actions, prompt templates, standard actions for common objects. But the moment a business process needs custom validation, a call to an external system, or logic too complex for a Flow, the agent needs your code. That's the developer's entry point into Agentforce, and it's honestly one of the most in-demand skills in the ecosystem right now — most teams have admins who can configure an agent, but far fewer have developers who know how to extend one safely.

The good news: if you already know how to write an invocable Apex method for Flow, you're 80% of the way there. Agentforce reuses the same annotation.

How an Agent Actually Calls Your Code

It helps to think of an agent as a planner, not a black box. When a user asks it something, the agent:

1. Reads the instructions and topics it's been configured with.
2. Decides which action (or actions) can help complete the request.
3. Calls that action with whatever inputs it can infer from the conversation.
4. Reads the output and decides what to say or do next.

An "action" can be a Flow, a prompt template, a REST-exposed Apex method, or — what we're building today — an Apex class annotated with @InvocableMethod. The annotation is what makes your class show up as a selectable action inside Agentforce Builder.

What We're Building

A support agent for a fictional subscription business needs to answer: "What's the status of order 00012345?" Instead of guessing, it should call real Apex that queries the actual record. Here's the class:

public with sharing class OrderStatusAction {

    @InvocableMethod(
        label='Get Order Status'
        description='Returns the current status, expected delivery date, and total for a given order number.'
    )
    public static List<OrderStatusResult> getOrderStatus(List<OrderStatusRequest> requests) {
        List<OrderStatusResult> results = new List<OrderStatusResult>();

        for (OrderStatusRequest req : requests) {
            OrderStatusResult result = new OrderStatusResult();

            Order__c ord = [
                SELECT Status__c, Expected_Delivery__c, Total_Amount__c
                FROM Order__c
                WHERE Order_Number__c = :req.orderNumber
                WITH USER_MODE
                LIMIT 1
            ];

            result.status = ord.Status__c;
            result.expectedDelivery = ord.Expected_Delivery__c;
            result.totalAmount = ord.Total_Amount__c;
            results.add(result);
        }

        return results;
    }

    public class OrderStatusRequest {
        @InvocableVariable(label='Order Number' description='The order number the customer
 is asking about, e.g. 00012345.' required=true)
        public String orderNumber;
    }

    public class OrderStatusResult {
        @InvocableVariable(label='Status' description='Current fulfillment status of the order.')
        public String status;

        @InvocableVariable(label='Expected Delivery' description='The date the order is expected to arrive.')
        public Date expectedDelivery;

        @InvocableVariable(label='Total Amount' description='The total charged for this order.')
        public Decimal totalAmount;
    }
}

A few details that matter more here than in ordinary Apex:

• The description on @InvocableMethod and every @InvocableVariable isn't a comment — it's instructions the agent reads at run time to decide when to call this action and how to fill in its inputs. Vague descriptions produce agents that call the wrong action or leave inputs blank.
• WITH USER_MODE enforces the running user's field- and object-level security, which matters even more with an agent in the loop, since you don't want it surfacing data the requesting user couldn't normally see.
• Keep request/response wrapper classes flat and simple. Agents reason better over a handful of clearly-labeled fields than a deeply nested structure.

Wiring the Action into Agentforce Builder

Once the class is deployed:

1. From Setup, open Agentforce Studio (or Agent Studio, depending on your org's release) and open the agent you want to extend, then start a new version.
2. Under Actions, choose New Action, then set the reference type to Apex and the category to Invocable Method.
3. Select OrderStatusAction from the list — Agentforce Builder will pre-fill the action's name, description, inputs, and outputs directly from your annotations.
4. Check Show in conversation on any output field you want the agent to surface directly in its reply (for example, status), rather than just reasoning over silently.
5. Save, commit the version, and activate it.

Testing Before You Ship It

Don't skip this step. Agentforce Builder has a Preview / Live Test Mode pane where you can chat with the draft agent before it goes live. Ask it the exact question a real user would ask — "Where's my order 00012345?" — and confirm two things:

• It actually selects your action instead of hallucinating an answer.
• The output it reads back matches what your Apex actually returned.

If it doesn't call the action reliably, the fix is almost always a clearer description, not more code. Agents lean heavily on that text to route correctly.

Permission Set Gotcha

This trips up a lot of developers coming from a pure-Apex background: an agent runs with the permissions of whatever user or agent user is assigned, not with elevated access. If the Apex class, the custom object, or the specific fields in OrderStatusAction aren't granted through a permission set assigned to that user, the action will silently fail to appear as usable — even though it's deployed and wired up correctly in Builder. If your action isn't behaving, check permissions before you touch the code.

From One Action to a Real Agent Skill

A single action is a good first step, but the pattern scales:

• Chain actions together — one action to look up the order, another to check refund eligibility, another to actually issue the refund — and let the agent sequence them based on the conversation.
• Use External Objects with Prompt Builder to ground the agent's generated responses in live data from systems outside Salesforce, instead of custom Apex callouts for every case.
• Log agent actions back to Data Cloud so you can monitor which actions get called, how often they succeed, and where agents get stuck — treat it like observability for a new kind of user.

The Bottom Line

If you can write an invocable Apex method for a Flow, you already have the core skill Agentforce needs from a developer. The shift isn't really technical — it's about writing your method and field descriptions for an AI reader instead of a human one, and being deliberate about what the agent is and isn't allowed to touch. Start with one well-scoped action, test it in Live Test Mode until it behaves predictably, and expand from there.

Have you built a custom Agentforce action yet? Share what it does — or where it broke — in the comments below.