Salesforce Certified Agentforce Specialist — Complete Study Guide

The Agentforce Specialist credential sits at the center of Salesforce's AI strategy: Agentforce agents that plan and act autonomously, Prompt Builder templates that generate grounded content, and Data Cloud retrieval that feeds both with enterprise knowledge.

This is a practitioner exam, not a trivia exam. Most questions describe a business scenario — a service team drowning in password-reset cases, a sales leader who wants outreach emails grounded in opportunity data, an agent that keeps picking the wrong topic — and ask you to choose the right building block: the right agent type, the right action type, the right grounding technique, the right retriever, the right test approach. Salesforce recommends hands-on experience with Agentforce and Prompt Builder, and the exam rewards people who have actually watched an agent's reasoning plan unfold in Agent Builder rather than only read about it.

The exam outline was refreshed for the current cycle (current as of July 2026): it now leads with a heavyweight AI Agents domain (35%), gives equal 20% weight to Prompt Engineering, Data Cloud for Agentforce, and Development Lifecycle, and adds a new 5% domain on Multi-Agent Interoperability covering MCP and the Agent API. If you studied from older materials organized around "Prompt Engineering 30% / Agentforce Concepts 30%," recalibrate — this guide follows the current outline exactly.

With 60 scored questions in 105 minutes you have about 1 minute 45 seconds per question — comfortable, as Salesforce exams go, but the multiple-select items ("choose 2" / "choose 3") punish shallow knowledge because every option must be judged independently.

How to Use This Guide

The guide is organized into five Parts that map one-to-one onto the five official exam domains, in official order and weight. Every topic cluster in the current exam outline gets its own teaching section — nothing is skipped. Study Part 1 hardest: at 35% it contributes roughly 21 scored questions, more than double any other domain.

Four callout types flag material worth extra attention:

Suggested plan: Read Parts 1–5 in order. In a Trailhead playground or Developer Edition org with Agentforce enabled, build one agent with a custom topic and a Flow action, one Flex prompt template grounded with a retriever, and run one Testing Center batch. In your final 48 hours, re-read only the callouts, the tables, and the Exam-Day Checklist.

Part 1 · AI Agents (35%)

This domain covers what agents are, when to use them, how the Atlas Reasoning Engine plans, how topics and actions define agent behavior, and how the Einstein Trust Layer, security model, channels, and escalation paths keep agents safe and useful. It is the exam's core.

From Chatbots and Copilots to Agents: Identifying the Use Case

The exam expects you to distinguish three generations of conversational AI and pick the right one for a scenario:

• Rule-based chatbots (classic Einstein Bots) follow predefined dialog trees. Deterministic, cheap, brittle — every path must be authored in advance.
• Copilots / assistants respond to a user's request one turn at a time, with a human driving every step.
• Agents pursue a goal autonomously: they interpret an utterance, plan a sequence of steps, call actions (Flows, Apex, prompt templates, APIs), evaluate results, and iterate — within guardrails — until the job is done or they escalate.

A scenario is a good agent use case when it involves natural-language input, variable multi-step resolution paths, access to business data, and actions that can be safely automated (order status, appointment scheduling, case deflection, lead qualification). It is a poor use case when the task demands guaranteed deterministic behavior, judgment calls with legal or high-stakes consequences, or pure emotional-intelligence work — those belong to humans or rigid automation.

Agent Types: Employee, Service, Sales SDR, Sales Coach

Salesforce ships standard (out-of-the-box) agent types, each with pre-built topics and actions for a job-to-be-done. Know them cold:

Two distinctions the exam loves:

1. 1Employee vs. customer-facing. The Employee Agent runs in the context of an authenticated internal user and respects that user's permissions. Service Agent and SDR face external parties and run as a dedicated Agent User with its own permission set (covered below).
2. 2Service Agent vs. SDR vs. Sales Coach. Service Agent resolves support issues; SDR nurtures leads and books meetings; Sales Coach never talks to customers at all — it role-plays with your own reps.

The Atlas Reasoning Engine: Plan, Act, Evaluate

The Atlas Reasoning Engine is the "brain" of every Agentforce agent. Instead of matching keywords to a dialog tree, Atlas runs an agentic loop:

1. 1Understand the utterance. The user's message (plus conversation context and variables) is analyzed for intent.
2. 2Topic classification. Atlas selects the single most relevant topic by comparing the utterance against each topic's classification description. Topics narrow the problem space so the agent isn't choosing from hundreds of actions at once.
3. 3Planning. Within the chosen topic, Atlas builds a plan: which actions to run, in what order, with what inputs — guided by the topic's scope and instructions.
4. 4Action execution. Atlas invokes actions (Flow, Apex, prompt template, API), collects their outputs.
5. 5Evaluation and iteration. Atlas checks whether the result satisfies the request; if not, it refines the plan, asks a clarifying question, or escalates.
6. 6Response. The final answer passes back through the Einstein Trust Layer before reaching the user.

This loop is why authoring quality matters so much: Atlas can only classify into topics whose descriptions are distinctive, and can only build good plans from actions whose descriptions and input/output labels clearly say what they do.

Topics: Standard vs. Custom, and the Anatomy That Steers Atlas

A topic is a category of work the agent can perform — "Order Management," "Reservation Changes," "General FAQ." Every topic has:

• Classification descriptiontells Atlas when to choose this topic. Written for the planner, not the user. Must be distinctive relative to sibling topics; overlapping descriptions cause misclassification.
• Scopedeclares what the topic does and does not handle, bounding the agent's job within the topic.
• Instructionsnatural-language business rules that guide the plan: "Always verify the customer's identity before sharing order details." "Never promise a refund; create a case instead." Instructions are the primary topic-level guardrail mechanism.
• Actionsthe tools available inside this topic.

Standard topics ship with standard agent types (e.g., Service Agent's FAQ topic) and give you working behavior out of the box. Custom topics are ones you author for your own use cases; you can also create topics from existing actions or modify copies of standard topics. When an utterance matches nothing, agents fall back to off-topic handling and either ask for clarification or decline.

Agent Actions: Flow, Apex, Prompt Template, and API

Actions are how agents actually do things. Every action has a description, input parameters, and outputs — all with natural-language labels that Atlas reads when planning. Four custom action types dominate the exam:

Standard actions (like "Answer Questions with Knowledge" on a Service Agent, or record summarization on the Employee Agent) come pre-built; you assign them to topics rather than build them.

One point that trips up newcomers: action descriptions and parameter instructions are functional, not documentation. Atlas literally uses them to decide when to call the action and how to fill its inputs. A vague description like "Runs the flow" degrades planning quality just as surely as a bug in the Flow itself.

Behavior Management: Filters, Context, and Custom Variables

Agents carry variables through a session, and you use them to manage behavior:

• Context variables are populated automatically from the session — for example the routable ID, messaging session, or end-user identity on a messaging channel. They let actions know who they're talking to and where.
• Custom variables are ones you define to store state — a verified account ID, a loyalty tier, a language preference. Actions can read and write them; instructions can reference them ("If VerifiedCustomer is false, run the Verify Identity action before anything else").
• Filters constrain behavior and data — for example, restricting a topic's availability or filtering which records an action may retrieve so the agent only operates on the relevant customer's data.

This is how you build multi-turn logic without a dialog tree: verify once, store the result in a variable, and let instructions gate later actions on it.

Agent Security: The Agent User, Permission Sets, and Data Access

Autonomous, customer-facing agents do not run as the customer — they run as a dedicated Agent User (a special user record provisioned with the agent). Everything the agent can see and do flows from that user's access:

• •
  The Agent User is assigned a permission set (e.g., the Agentforce Service Agent permission set plus your own) granting object, field, and Flow/Apex access.
• •
  Standard Salesforce sharing, object permissions, and field-level security apply to every action the agent executes. If the Agent User can't read the Order object, no amount of prompting will surface order data.
• •
  Least privilege is the rule: grant the Agent User exactly what its topics and actions need, nothing more. Over-permissioning an internet-facing agent is a data-leak waiting to happen.
• •
  The Employee Agent, by contrast, runs in the session of the invoking employee and respects that user's permissions — two users asking the same question can get different answers because they see different data.

The Einstein Trust Layer

Every LLM interaction in Agentforce and Prompt Builder passes through the Einstein Trust Layer, a set of guardrails between Salesforce and the model providers:

• Secure gateway and zero data retentionrequests to external LLM providers (e.g., OpenAI, Anthropic via Salesforce's gateway) are covered by zero-retention agreements: prompts and responses are not stored by the provider and are not used to train their models.
• Data maskingsensitive data (PII patterns such as names, emails, phone numbers, and configurable entities) is detected and replaced with placeholder tokens before the prompt leaves Salesforce, then de-masked in the response so the user sees real values. Admins configure which entities are masked in Einstein Trust Layer setup.
• Prompt defensesystem-level instructions wrap your prompt to resist jailbreaks and instruct the model to stay on task and decline unsafe requests.
• Toxicity detectiongenerated responses are scored for toxic content categories, and scores are stored so violations can be reviewed.
• Audit trail and feedbackprompts, responses, masked-entity metadata, toxicity scores, and user feedback (thumbs up/down) are logged. With Data Cloud, this audit data is stored in DMOs you can report on — essential for compliance and for improving the agent.

Channels: Meeting Users Where They Are

Agents are deployed to channels, and the exam tests which channel fits which scenario:

• Messaging for In-App and Web (MIAW)the primary channel for Service Agents: an embedded messaging window on your website or mobile app, configured via an embedded service deployment and connected to Omni-Channel for escalation.
• Experience Cloud sitesexpose the agent to authenticated or guest users on a portal or community.
• Slackthe natural home for Employee Agents; employees converse with the agent in Slack DMs or channels.
• Emailagents (notably the SDR) can converse over email, reading replies and responding.
• In-org (Salesforce UI)the Employee Agent panel inside Lightning Experience.
• Voiceservice scenarios over the phone channel, where available.

One agent, many channels: the same topics and actions serve every deployment, but session context variables differ by channel.

Escalation to Human Reps

No customer-facing agent design is complete without a hand-off path. The standard pattern for a Service Agent:

1. 1.
   An Escalation topic (standard) detects frustration, explicit requests for a human, or situations outside the agent's scope/instructions.
2. 2.
   The escalation action transfers the messaging session through Omni-Channel routing (flow-based routing to a queue or skill), preserving the conversation transcript so the human rep has full context.
3. 3.
   Availability handling: if no rep is available, the agent can set expectations, create a case, or capture contact details.

Design guidance the exam rewards: escalate early and gracefully rather than letting the agent flounder; write topic instructions that define escalation triggers explicitly; and measure escalation rate as a key agent KPI. Deflection is the goal, escalation is the safety net — an agent with no escalation path is an exam wrong-answer for any customer-facing scenario.

Grounding Service Agents with Knowledge

Out of the box, a Service Agent answers questions using Salesforce Knowledge: the standard "Answer Questions with Knowledge" action retrieves relevant published articles and the LLM composes a grounded reply, instead of answering from the model's training data. Requirements to remember: Knowledge must be enabled with published articles, the Agent User needs access to them (data category visibility and object permissions apply), and for semantic retrieval at scale the articles are indexed into Data Cloud via a Data Library (Part 3 covers the machinery). Grounded answers cite what they used, dramatically reducing hallucination — the exam's answer for "the agent invents policy details" is ground it in Knowledge, not switch the model.

Guardrails: Layered Defense for Agent Behavior

"Guardrails" on this exam is an umbrella for every layer that constrains an agent:

1. 1Topic scope and classificationthe agent only works within defined topics.
2. 2Instructionsnatural-language rules per topic ("never discuss competitors," "always confirm before updating a record").
3. 3Action inventorythe agent literally cannot do what it has no action for. Omitting a "delete record" action is a stronger guarantee than instructing "don't delete records."
4. 4Agent User permissionsplatform-enforced data access limits.
5. 5Einstein Trust Layermasking, prompt defense, toxicity detection on every LLM round-trip.
6. 6Escalationhumans as the fallback for anything ambiguous or sensitive.

Part 2 · Prompt Engineering (20%)

This domain covers Prompt Builder: when to reach for it, the four template types, how templates are grounded, secured, tested, and invoked, and how the Trust Layer and model selection shape results.

When to Use Prompt Builder

Prompt Builder is the low-code tool for creating reusable, grounded, versioned prompt templates — parameterized prompts that merge CRM data at runtime and send the result through the Trust Layer to an LLM. Use it when the job is generate text from business data in a repeatable way: draft a sales email, summarize a record, fill a field, answer from knowledge. Choose Prompt Builder over ad-hoc prompting because templates are reusable (write once, invoke from many surfaces), grounded (merge fields pull live, permission-checked data), governed (Trust Layer, versioning, activation), and embeddable (Flows, Apex, agent actions, Lightning pages). Choose an agent instead when the job needs multi-step planning and actions; a prompt template is a single generation step — and, tellingly, prompt templates are themselves one of the action types agents call.

The Four Template Types

• Sales Email templates take a recipient and optionally a related record (like an Opportunity) and produce a subject and body.
• Field Generation templates bind to a single field via the prompt template's association; users trigger them from the field in the record UI.
• Record Summary templates back the Employee Agent's "summarize this record" capability.
• Flex is the general-purpose type — you declare the inputs (records, free text), so it fits custom use cases and is the usual type behind custom prompt template agent actions.

Roles and Access for Templates

Building and running templates are separate privileges:

• •
  Prompt Template Manager permission set — create, edit, and manage templates in Prompt Builder.
• •
  Prompt Template User permission set — execute activated templates (e.g., a rep using a Sales Email template).
• •
  Runtime grounding respects the running user's object and field-level security — a template merges only data the executing user can see. Some invocation paths can be configured to run with elevated/system context, which is exactly why the exam expects you to know the default is user context.

Provisioning also matters: Einstein generative AI must be enabled in Setup, and Prompt Builder requires the Einstein for Sales/Service or Foundations licensing that carries generative AI credits. A scenario about "the button doesn't appear" is often a missing permission set, not a broken template.

Grounding Techniques: Merge Fields, Related Lists, Flow, Apex, Data Cloud

Grounding is how a template gets facts. From simplest to most powerful:

1. 1Record merge fields{!$Input:Contact.Name} style references pull fields from the template's input records.
2. 2Related listsmerge a record's related list data (e.g., an Account's open Cases) into the prompt.
3. 3Flowa template-triggered prompt flow runs at generation time, queries or computes anything Flow can, and adds its output to the prompt. The declarative way to ground on data that isn't a simple field or related list.
4. 4Apexan invocable Apex class serves as a data provider for complex retrieval, callouts, or aggregation.
5. 5Data Cloudground on unified DMO data or, most importantly, on retrievers that run semantic search over indexed content (the RAG pattern — Part 3).

The Template Lifecycle: Create → Preview → Activate → Execute

1. 1Createpick the template type, name it, choose the model, write the prompt with merge fields and grounding resources.
2. 2Preview (Resolution)select sample records and preview both the resolved prompt (exactly what will be sent, with merge fields filled and masking applied) and the response. This is your primary debugging view: if the resolution shows blank merge fields, your grounding or the sample data is wrong.
3. 3Activateonly activated templates can be invoked outside Prompt Builder. Editing typically means saving changes and re-activating; versions let you iterate safely.
4. 4Executeend users or automation invoke the active template through its surface.

Invoking Templates: Flow, Apex, Agent Actions, Lightning Pages

An activated template can be executed from:

• Flowthe Prompt Template action element in Flow Builder passes inputs and captures the generated text (e.g., generate a summary inside a case-handling flow).
• Apexvia the ConnectApi.EinsteinLLM methods, for programmatic generation inside triggers-adjacent logic or services.
• Agent actionswrap the template as a prompt template action so Atlas can call it during a plan.
• Lightning pages / record UIField Generation templates surface on their bound field; Sales Email templates surface in the email composer; Flex templates can back custom Lightning components.
• REST APIinvoke templates headlessly from external systems.

Prompt Best Practices and Iterative Refinement

The exam tests prompt craft at a practical level:

• •
  Give the model a role and task ("You are a service assistant. Summarize the case for a technician…").
• •
  State format and constraints explicitly (length, tone, structure, "use only the provided data").
• •
  Ground rather than assume: tell the model to answer only from supplied grounding and to say when information is missing — the main anti-hallucination lever.
• •
  Iterate empirically: change one thing at a time, re-preview against multiple representative records (not just the happy path), and judge outputs for faithfulness to grounding, completeness, tone, and format.
• •
  Response quality is a loop, not a step: preview → inspect resolution → adjust instructions or grounding → re-preview.

When output quality is poor, check in this order: (1) is the right data actually in the resolved prompt? (2) are the instructions specific about format and scope? (3) is the model the right choice for the task? Grounding problems masquerade as "bad model" problems constantly.

Model Selection and the Model Playground

Prompt Builder lets each template choose its LLM from the models available through the Einstein Trust Layer gateway — Salesforce-managed standard models (OpenAI GPT family, Anthropic Claude, Google Gemini) and, via Bring Your Own LLM (BYOLLM) through Einstein Studio, models you connect from your own provider accounts. The Model Playground (in Einstein Studio) is where you compare models side by side and tune generation parameters — temperature (randomness/creativity), frequency and presence penalties — against sample prompts before committing a template to a model. Practical guidance the exam mirrors: use lighter/faster models for simple structured tasks, stronger models for nuanced generation; lower temperature for factual, grounded outputs; and validate any model switch by re-previewing your templates, because prompt behavior is model-specific.

Trust Layer Effects on Prompts

Everything from Part 1's Trust Layer section applies to Prompt Builder, with template-specific consequences you can see:

• •
  The resolved prompt in Preview shows masked values where PII masking applies; the model receives placeholders, and the response is de-masked before display.
• •
  Dynamic grounding respects the running user's permissions — the same template produces different resolutions for users with different FLS.
• •
  Zero retention and the audit trail apply to every template execution; feedback captured on generations feeds quality review.
• •
  Prompt defense wraps your template — which is why templates sometimes decline requests that conflict with safety instructions even though your text didn't forbid them.

Part 3 · Data Cloud for Agentforce (20%)

This domain is the retrieval layer: how unstructured knowledge gets into Data Cloud, chunked, indexed, and searched, and how retrievers feed grounded, cited answers into prompt templates and agents — the platform's RAG (Retrieval-Augmented Generation) architecture.

Agentforce Data Library: Setup and Source Types

The Agentforce Data Library is the managed, low-setup path to RAG. Creating a Data Library automatically provisions the Data Cloud plumbing — data streams, a search index, and a default retriever — so an admin can go from content to grounded answers without hand-building pipelines. Supported source types:

• Salesforce Knowledgepublished, agent-accessible Knowledge articles; the library keeps the index in sync as articles are published/updated.
• Filesuploaded documents (PDFs and similar) whose text is extracted and indexed.
• Websitescrawled web content ingested as unstructured data.

Once created, the library is attached to an agent (grounding the "Answer Questions with Knowledge"-style actions) or referenced from prompt templates. For sources or pipelines beyond what libraries support, you can build custom Data Cloud ingestion (data streams → DLO/DMO → search index) manually — the library is a convenience wrapper over the same machinery.

Chunking and Indexing Unstructured Data

LLMs can't search a 40-page PDF directly, so ingestion breaks content down:

1. 1Extractiontext is pulled from the source (article body, file text, page content) into an unstructured data model object.
2. 2Chunkingthe text is split into passages ("chunks") sized for retrieval. Good chunks are semantically coherent — a section, a paragraph cluster — because the chunk, not the document, is what gets retrieved and stuffed into the prompt's context window.
3. 3Indexingeach chunk is stored in a search index. For vector search, an embedding model converts each chunk into a numeric vector embedding capturing its meaning; for keyword search, terms are indexed traditionally.
4. 4Refreshas sources change, re-ingestion keeps the index current; stale indexes are a classic cause of "the agent gives outdated answers."

Search Types: Keyword vs. Vector vs. Hybrid

Retrievers: Default, Ensemble, and Custom

A retriever is the query-time component that takes the user's question, searches an index, and returns the top-matching chunks for grounding:

• Default retrievercreated automatically with each Data Library / search index; sensible configuration out of the box, one index per retriever.
• Ensemble retrieverqueries multiple sources/indexes and merges the results, letting one grounded answer draw on, say, Knowledge articles and product PDFs at once.
• Custom retrieverone you configure yourself: choose the index and search type, add filters (e.g., only chunks whose source metadata matches the user's product line or language), set the number of results returned, and shape ranking. Build one when the default's behavior — its scope, filtering, or result count — doesn't fit.

RAG Grounding in Prompt Templates

The end-to-end RAG pattern on the platform:

1. 1.
   User asks a question (directly to a template, or via an agent action).
2. 2.
   The prompt template's grounding includes a retriever resource (Einstein Studio retriever added to the template).
3. 3.
   At resolution time, the retriever runs semantic/hybrid search and injects the top chunks into the prompt.
4. 4.
   The LLM answers using only the retrieved passages, and the response can cite sources.

This is the canonical fix for hallucination on knowledge questions: the model stops answering from its training data and starts answering from your indexed, current, permission-governed content. In Prompt Builder, previewing the template shows the retrieved chunks in the resolved prompt, so you can verify retrieval quality separately from generation quality.

Grounding with Data Cloud DMOs and Retrievers

Not all Data Cloud grounding is unstructured RAG. Templates and agents can also ground on structured Data Cloud data — harmonized Data Model Objects (DMOs), including unified profiles and calculated insights — merging, say, a customer's engagement history or lifetime value into a prompt. So you have two Data Cloud grounding lanes: DMO merge grounding for structured, harmonized facts, and retriever grounding for semantic search over unstructured content. Many rich templates use both: retriever chunks for policy knowledge plus DMO fields for customer specifics.

Retrieval Tuning: Filters and Ranking

When retrieval quality disappoints, tune the retriever rather than the prompt:

• •
  Filters narrow the searchable set using chunk/source metadata — product, region, language, article type — so a question about Product A never gets grounded with Product B's docs. Filters can be static or driven by runtime input.
• •
  Result count balances context richness against noise and token cost; too many chunks buries the relevant one, too few misses it.
• •
  Ranking / search type choice — switching keyword↔vector↔hybrid, or improving chunk quality at ingestion, moves relevance more than prompt wording ever will.
• •
  Testing retrieval with representative queries is part of the development lifecycle, not an afterthought.

Data Cloud Permissions

Access control follows the platform pattern: Data Cloud has its own permission sets (admin vs. user-level access to Data Cloud features, libraries, and indexes), and the identities that run retrieval — the Agent User for customer-facing agents, the running user for templates — need rights to the Data Cloud assets involved. Knowledge grounding additionally respects article publication status and data-category visibility. The recurring exam pattern: grounded answers work for the admin but fail for end users → a permissions gap on the Agent User or the running user, not a retrieval bug.

Part 4 · Development Lifecycle (20%)

This domain covers how you test agents before launch, trace and debug their reasoning, move them from sandbox to production, and monitor them after go-live.

Agentforce Testing Center: Test Cases and Batch Utterance Testing

The Agentforce Testing Center is the purpose-built tool for evaluating non-deterministic agents at scale:

• •
  You define test cases: an utterance plus expected results — the expected topic, expected action(s), and expectations about the response.
• •
  Tests run in batches: upload or generate a CSV of utterances/expectations, run hundreds of evaluations in parallel, and review pass/fail per case. Batch testing is how you catch classification regressions that single-conversation spot checks miss.
• •
  Testing Center can AI-generate test utterances from your topic and action descriptions, seeding coverage you then curate.
• •
  Because agents are probabilistic, testing is statistical: you're measuring how often the agent picks the right topic and actions across many phrasings, not asserting one deterministic path.
• •
  Re-run the batch after every meaningful change (new topic, edited classification description, changed instructions) — that's the regression-testing loop.

Agent Builder Conversation Preview and Plan Tracing

Inside Agent Builder, the conversation preview panel lets you chat with the (even inactive) agent and — critically — inspect its plan trace for each turn: which topic Atlas classified the utterance into, which actions it selected, the inputs it passed, the outputs actions returned, and how the final response was assembled. This is your step-through debugger:

• •
  Wrong topic chosen → fix classification descriptions.
• •
  Right topic, wrong/no action → fix instructions or action descriptions.
• •
  Right action, wrong result → debug the underlying Flow/Apex/template (the plan shows the actual inputs it received).
• •
  Right everything, bad wording → adjust instructions or the template's prompt.

Evaluating Responses and Diagnosing Topic/Action Failures

A systematic triage the exam expects you to reproduce:

1. 1Classification failureutterance landed in the wrong topic (or no topic). Fix: sharpen and de-overlap classification descriptions; add topics for uncovered intents.
2. 2Planning failureright topic, but Atlas skipped or mis-ordered actions. Fix: clearer topic instructions; better action descriptions and input/output labels.
3. 3Execution failureaction errored or returned bad data. Fix: the Flow/Apex/API itself, or the Agent User's permissions.
4. 4Generation failureeverything retrieved correctly but the reply is off-tone, too long, or unfaithful. Fix: prompt template instructions, model choice, or grounding scope.

Evaluate responses against grounding faithfulness, completeness, safety, and tone — and use real transcripts (see analytics below) to source failure cases for new tests.

Sandbox → Production Deployment

Agents, prompt templates, and their dependencies are metadata, and they move through the standard Salesforce ALM toolchain:

Vehicles: change sets (declarative, org-to-org), Metadata API / SFDX (source-driven), and DevOps Center for pipeline-managed promotion with source control. Best practice is source-driven: build and test in a sandbox, retrieve agent + template metadata into version control, deploy through stages, then perform post-deploy steps — activate the agent, assign permission sets, connect channels, rebuild/point Data Libraries, and re-run a Testing Center batch in production-like conditions.

Activation, Versioning, and Environments

• •
  An agent must be activated to serve real traffic; deactivate to take it offline. You edit a draft/inactive version while a live version serves users, then promote — enabling safe iteration.
• •
  Prompt templates likewise carry versions with one active at a time, giving you rollback.
• •
  Environment strategy mirrors the rest of the platform: build in a Developer/Developer Pro sandbox, UAT with realistic data in a partial or full sandbox (agent behavior is data-dependent — an empty sandbox tests nothing), then production. Einstein generative AI features and Data Cloud must be provisioned in each environment.

Monitoring, Adoption, and Performance Analytics

Post-launch, Agentforce ships analytics to close the loop:

• Agentforce analytics dashboards track volume (sessions, engaged conversations), outcomes (resolution/deflection rate, escalation rate, abandonment), and quality trends over time.
• Adoption metricsis the agent actually being used, on which channels, for which topics? Topic distribution reveals both demand and misclassification hot spots.
• Cost/consumptionAgentforce conversations and generative requests consume metered credits; monitoring usage is part of operating the product.

Session and Utterance Analysis, and Feedback Loops

Aggregates tell you that something is off; session and utterance analysis tells you where:

• •
  Review individual session transcripts to see full conversations, including where users rephrased, gave up, or escalated.
• •
  Utterance analysis surfaces unhandled or misclassified utterances — the raw material for new topics, better classification descriptions, and new Testing Center cases.
• •
  User feedback (thumbs up/down and comments on responses) plus Trust Layer audit data (stored in Data Cloud DMOs) feed quality review and compliance reporting.
• •
  The virtuous cycle the exam wants you to articulate: monitor → mine transcripts/utterances for failures → convert failures into test cases → fix topics/actions/prompts → batch-test → redeploy → monitor.

The lifecycle is a loop, not a line: Build (Agent Builder) → Debug (preview + plan trace) → Test (Testing Center batches) → Deploy (metadata, inactive) → Activate → Monitor (analytics, transcripts, feedback) → back to Build.

Part 5 · Multi-Agent Interoperability (5%)

The smallest domain — roughly three scored questions — covering how agents talk to other systems and other agents: MCP, agent-to-agent patterns, and the Agent API.

Model Context Protocol (MCP): Purpose and When to Use It

The Model Context Protocol is an open standard that gives AI agents a uniform way to discover and call external tools, resources, and prompts exposed by MCP servers — think "USB-C for agent integrations." Instead of hand-building a bespoke connector (custom Apex callout + External Service schema) for every system, an agent acting as an MCP client can connect to any compliant MCP server and use its published tools, with the protocol handling discovery and invocation semantics. In the Salesforce context, MCP support lets Agentforce agents consume tools from third-party and internal MCP servers — governed, with admin control over which servers and tools are allowed — and lets Salesforce capabilities be exposed to external MCP-speaking agents.

When to use MCP: the capability lives outside Salesforce, is (or can be) exposed via an MCP server, and you want standards-based, reusable, discoverable integration rather than one-off API wiring — especially when multiple agents or vendors are involved. When not to: the logic lives inside Salesforce (use Flow/Apex actions) or it's a single simple REST endpoint you control (an External Services action is fine).

Agent-to-Agent Collaboration Patterns

As organizations deploy multiple specialized agents, the exam expects recognition of the core patterns:

• Orchestrator/supervisora primary agent decomposes a request and delegates sub-tasks to specialist agents (billing agent, scheduling agent), then assembles the result. Keeps each agent's topic space small and accurate.
• Handoffone agent transfers the conversation (with context) to another better-suited agent, analogous to human escalation.
• Agent-as-a-toolone agent invokes another as if it were an action, treating the peer's capability as a callable service (via Agent API or MCP-style exposure).
• Cross-platform interoperabilityemerging open standards (MCP for tools; agent-to-agent protocols for peer communication) aim to let agents built on different vendors' stacks cooperate rather than live in silos.

Design rationale to remember: multiple narrow agents beat one mega-agent because topic classification accuracy degrades as one agent's topic count and overlap grow.

Agent API Scenarios

The Agent API is a REST API for conversing with an Agentforce agent programmatically — start a session, send messages (synchronously or streaming), receive the agent's responses, end the session — authenticated via a Connected App (OAuth client credentials). Reach for it when:

• •
  You need the agent in a custom surface — a native mobile app, a custom web front end, a kiosk — where the standard channels (MIAW widget, Slack, Experience Cloud) don't fit.
• •
  An external system or another agent must invoke your agent headlessly (system-to-agent or agent-to-agent integration).
• •
  You're building automation around conversations — e.g., a middleware layer that brokers between an external assistant and your Service Agent.

Standard channels handle the mainstream cases with zero code; the Agent API is the programmatic escape hatch.

Interoperability with External Agents and Systems

Pulling the domain together, you have four integration directions to keep straight: (1) Agent → external system, bespoke: External Services/API and Apex actions. (2) Agent → external tools, standards-based: MCP client connecting to MCP servers. (3) Outside world → your agent: Agent API (custom UIs, headless callers, external agents). (4) Agent ↔ agent: orchestration and handoff patterns built on those same rails. Governance applies across all four — admin-controlled allowlists for MCP servers/tools, OAuth scopes for the Agent API, and the same Trust Layer and Agent User permission boundaries no matter who or what is on the other end of the conversation.

Exam-Day Checklist

Run through this in your final 48 hours — every line is a tested fact or pattern.

Logistics

• •
  60 scored + 5 unscored questions, 105 minutes, 73% to pass, $200 ($100 retake). Multiple choice and multiple select. Flag-and-return is available — use it; unscored items are indistinguishable, so never burn five minutes on one question.

AI Agents (35%)

• •
  Agent types: Employee (internal, runs as logged-in user), Service (external support + escalation), Sales SDR (nurtures leads, books meetings), Sales Coach (internal role-play, never customer-facing).
• •
  Atlas loop: utterance → topic classification (via classification descriptions) → plan actions (via instructions + action descriptions) → execute → evaluate → respond.
• •
  Wrong topic chosen → fix classification descriptions. Wrong action chosen → fix instructions/action descriptions.
• •
  Action types: Flow (declarative), Apex @InvocableMethod (complex/callouts), prompt template (generate grounded text), API/External Services (outside systems).
• •
  Customer-facing agents run as the Agent User with least-privilege permission sets; platform sharing/FLS always applies.
• •
  Trust Layer: data masking (masked out, de-masked back), zero retention with providers, prompt defense, toxicity scoring, audit trail — it does not override permissions or make output deterministic.
• •
  Channels: MIAW (web/in-app messaging), Experience Cloud, Slack (Employee), email, voice. Escalation = Escalation topic → Omni-Channel routing with transcript.
• •
  Strongest guardrails are deterministic: omit the action, restrict the permission. Instructions are guidance, not guarantees.

Prompt Engineering (20%)

• •
  Template types: Sales Email (outreach), Field Generation (one field, triggered from record UI), Record Summary (agent summarization), Flex (custom inputs, invoked anywhere).
• •
  Access: Prompt Template Manager (build) vs. Prompt Template User (run); grounding resolves with the running user's FLS.
• •
  Grounding ladder: merge fields → related lists → Flow → Apex → Data Cloud/retrievers.
• •
  Lifecycle: create → preview (inspect resolved prompt!) → activate → execute. Invoke from Flow, Apex (ConnectApi.EinsteinLLM), agent actions, Lightning pages, REST.
• •
  Model Playground (Einstein Studio): compare models, tune temperature; lower temperature for grounded/factual work; BYOLLM connects your own models.

Data Cloud for Agentforce (20%)

• •
  Data Library auto-provisions ingestion + index + default retriever; sources = Knowledge, files, websites.
• •
  Pipeline: extract → chunk → embed/index → retrieve. Stale index = outdated answers.
• •
  Keyword = exact terms/codes; vector = semantic similarity; hybrid = default recommendation.
• •
  Retrievers: default (auto, one index), ensemble (multiple sources merged), custom (your filters, result count, search type).
• •
  RAG fixes hallucination; debug retrieval (what chunks came back?) separately from generation (what did the model do with them?).
• •
  Structured grounding = DMO merge fields; unstructured = retrievers. Grounding failures for end users are usually permission gaps.

Development Lifecycle (20%)

• •
  Testing Center = batch utterance tests (CSV, AI-generated cases) asserting expected topic/actions — statistical, repeatable regression testing.
• •
  Agent Builder preview + plan tracing = single-conversation debugger showing topic chosen, actions run, inputs/outputs.
• •
  Deployment: agents/templates are metadata (GenAiPromptTemplate, planner/plugin/function types) via change sets, SFDX, or DevOps Center; agents arrive inactive; Data Cloud assets and channel deployments are per-org post-deploy configuration.
• •
  Versioning: edit drafts while a live version serves; activate to promote; same for template versions.
• •
  Monitor: session/deflection/escalation metrics, topic distribution, utterance analysis for misclassifications, user feedback + Trust Layer audit in Data Cloud → convert findings into new test cases.

Multi-Agent Interoperability (5%)

• •
  MCP = open standard, agent-to-tool; Agent API = REST, outside-world-to-your agent; patterns = orchestrator, handoff, agent-as-tool.
• •
  Prefer multiple narrow agents over one mega-agent — topic classification accuracy is the reason.

Official Resources

• Official credential page:Salesforce Certified Agentforce Specialist — current exam outline, policies, and scheduling.
• Official exam guide: linked from the credential page — always reconcile this study guide against the live outline before you book, as Salesforce revises domains between releases.
• Prepare trailmix:Prepare for Your Agentforce Specialist Credential — the official Trailhead study path, including hands-on Agentforce and Prompt Builder modules and the practice test.
• Hands-on practice: a Trailhead playground or Developer Edition org with Agentforce and Data Cloud enabled — build an agent, trace its plans, batch-test it. The exam's scenarios reward having done it once for real.

Good luck — study the callouts, build the agent, trust the plan trace.