Skip to main content

Agentforce agents: the platform-native path

The Salesforce-native path as one instrument in the kit — the right one when the work lives in the security model and needs governed, auditable actions on customer data (principle 7). How an Agentforce agent is assembled: Topics that scope the jobs, Instructions that steer behavior, the managed Atlas Reasoning Engine that plans over them, Actions that act, grounding through Data 360, and the Einstein Trust Layer doing the governance. What you own and what the platform owns — and where the work hands off to an external agent.

Reference·Last updated 2026-06-01·Drafted by Lira · Edited by German Medina

Reach for Agentforce when the work lives inside the Salesforce security model and the agent has to take governed, auditable actions on customer data — read a service case under the user's sharing rules, update a record, ground an answer on the unified profile (principle 7). That is the job this instrument is built for, and the reason to pick it is not loyalty to a platform but fit: when the action and the data both sit inside Salesforce, the platform already owns the grounding, the permissions, and the audit trail you would otherwise hand-build.

This page is how an Agentforce agent is assembled, part by part, and — just as important — what you own versus what the platform owns. You wire up the Topics, the Instructions, the Actions, and the grounding; the platform runs the planning loop and the governance. It is one composable instrument, not the whole kit: a real system often runs an Agentforce agent on-platform and an external agent off it, and they hand off. The vocabulary here — agent, tool, action, grounding, control loop — is the vocabulary from what is an agent; this page assumes it.

Topics: the jobs an agent handles

A Topic is a scope of work — a job the agent knows how to do. It groups the related Actions for that job with the instructions for when and how to use them. An agent has a set of Topics, and the planner picks the one that fits the request: a "manage order" Topic with its order-lookup and order-update Actions, a "schedule appointment" Topic with its calendar Actions, each holding only what that job needs.

The discipline is the same least-privilege discipline that governs tools (principle 5): a Topic should be the narrowest scope that still does the job. A Topic that bundles every Action the org has is a Topic the planner will misuse — it cannot reason cleanly about when to act when the boundary is blurry. Keep each Topic to one coherent job, with the Actions and instructions for that job and nothing more, and the planner has a clean choice to make instead of a guess.

Instructions: steering behavior in natural language

Instructions are the natural-language guidance that steers the agent inside a Topic — what it should do, where its boundaries are, when to act and when to hand off to a human. They are the platform-native expression of the system-prompt discipline from what is an agent: vague instructions are the most common cause of an agent that wanders, and Agentforce does not change that. "Help the customer with their order" gives the planner nothing to hold; "look up the order the customer names, confirm the item before any change, never cancel an order over a certain value without handing off to a human" gives it boundaries it can act inside.

Write Instructions the way you would write a tool description: say what to do, when to do it, and — most usefully — when not to. The boundaries you write here are guidance the planner reasons over, not a hard enforcement layer. The hard limits — what an Action is allowed to touch, who it runs as — live in the platform permission model and the Action definition, where the model cannot talk its way around them. Instructions steer; permissions enforce. You need both, and you should never mistake one for the other.

The Atlas Reasoning Engine: the managed planner

The planning loop is the part you do not own here. The Atlas Reasoning Engine is Agentforce's managed planner — introduced in orchestration patterns as the managed-reasoning option; this page goes one level deeper into what that means for how you build. Atlas plans over the Topics, Actions, and grounding you wire up: it reads the request, decides which Topic fits, decides which Actions to call and in what order, and grounds its reasoning on the data the platform retrieves — all inside the Salesforce security model.

The practical consequence is a clean division of labor. You own the tools, the instructions, and the grounding — the Topics, the Actions, what each one is allowed to do, and what data the agent answers over. The platform owns the control loop — the reason → act → observe cycle that an external build would have you write and bound yourself. That is the managed-or-custom trade-off from orchestration patterns, stated concretely: you give up control over the loop and get planning, grounding, and governance handled for you. When the job fits the security model, that is a good trade; when you need a control flow Atlas does not give you — a specific graph, a model Salesforce does not reach — that is the signal to compose an external agent instead.

Actions: how the agent acts

An agent acts through Actions — the Agentforce term for the tools in a Topic. The three execution types (Flow, Apex, Prompt Template) are detailed in tools and actions; in short, a Flow Action runs the work declaratively, an Apex Action runs it in code, and a Prompt Template Action calls a grounded prompt. This page does not re-teach them — read that page for how to build each type and for the safe-tool discipline (least privilege, argument validation, idempotency, a gate on anything consequential) that applies to an Action exactly as it does to any other tool.

What is worth restating here is what staying on-platform buys you. An Action executes as a user, under that user's permissions; sharing rules and field-level security still apply; and the platform records what ran. The blast-radius and audit discipline that an external build hand-builds is, on-platform, partly enforced by the security model you already operate. That is the core of why Agentforce is the right instrument when the work lives in the Salesforce security model — the governance is not bolted on, it is where the action runs.

Grounding through Data 360

An Agentforce agent answers over your data through grounding on the Data 360 (Data Cloud) profile. The mechanic is the same one from what is an agent: the agent does not answer from the model's training, it answers from facts retrieved this run. In the platform, those facts come through retrievers over the unified profile — the agent reads the same customer the rest of Salesforce sees, resolved and current, rather than guessing from parameters.

This is where principle 2 lands inside Agentforce: ground before you generate. An agent grounded on a fragmented or stale model is confidently wrong, and confidently wrong is worse than "I don't know" because someone acts on it. The model under the agent is upstream of almost every quality problem the agent will have, which is why the grounding side gets its own discipline — run the Data 360 agent-readiness check before the agent reads marketing or service data, not after the first wrong answer ships.

The Einstein Trust Layer: the governance the platform runs

The Einstein Trust Layer is the platform's governance and safety layer around the LLM the agent uses. It sits between Agentforce and the model, and it is a real reason the platform-native path is a strong fit for regulated and customer-data work. At the altitude that matters for a build decision, it covers a well-established set of controls:

  • Secure data retrieval — grounding data is pulled inside the security model, honoring the permissions of the running user rather than handed to a model with broad access.
  • Dynamic grounding — the relevant customer data is brought into the prompt at request time, so the agent reasons over current facts.
  • Data masking — sensitive fields can be masked before the prompt reaches the model provider, so PII is not exposed where it does not need to be.
  • Zero data retention — the model provider does not retain the prompts or responses, so your customer data is not used to train an external model or kept on its side.
  • Toxicity scoring — generated output is scored for toxicity, giving you a signal to act on before it reaches a person.
  • An audit trail — the interaction is logged, which is the precondition for owning what the agent did (principle 11).

The composition point: Agentforce here, an external agent there

Agentforce is one instrument, and the honest framing is composition, not choice (principle 7). The platform-native path is the right one when the work lives in the Salesforce security model and needs governed, auditable actions on customer data. An external LangGraph or Claude API agent is the right one when the work is off-platform, needs a control flow Atlas does not give you, or reaches a model and systems Salesforce does not — see external agents for that side. A real system frequently runs both: Agentforce owning the in-platform actions on governed data, an external agent owning a step it cannot, and a clean handoff between them where accountability gets a seam (principle 9).

The decision of which surface for which job inside Marketing Cloud — Agentforce versus an external model — is its own framework, and it is not repeated here; the Marketing Cloud AI Style Guide holds it in full. What this page settles is narrower and worth stating plainly: Agentforce is not the answer to "should we use an agent," it is the answer to "the work is governed, on-platform, and acting on customer data — what plans and runs it." When that is the job, the platform owning the loop and the governance is exactly the trade you want.

The throughline

An Agentforce agent is Topics that scope the jobs, Instructions that steer the behavior, the Atlas Reasoning Engine that plans over them, Actions that act inside the security model, grounding on the Data 360 profile, and the Einstein Trust Layer running the governance. You own the tools, the instructions, and the grounding; the platform owns the loop and the safety layer. That division is the whole appeal — and its whole limit. When the work fits the security model, it is the most governed path to a shipping agent; when it does not, that is the signal to compose an external agent and hand off. The skill is knowing which job you have, not defending the instrument. (See agent gotchas for the failure modes a platform-native build still inherits, and the Agent Style Guide for the bar an agent clears before it ships.)

Related

Reference: