What is Agentforce? A plain-English explainer from implementers
Every Salesforce roadmap now has Agentforce scribbled on it somewhere, usually without a shared definition. Here is what the platform actually is — agents, topics, actions, grounding — and what it takes to run one responsibly.
Ask five people in a Salesforce org what Agentforce is and you will get five answers. A chatbot. Einstein with a new name. “The AI thing from Dreamforce.” Something to do with Data Cloud. A line item in the renewal quote that nobody remembers agreeing to.
The confusion is understandable. Salesforce has renamed its AI products repeatedly, the marketing moves faster than the documentation, and the wider industry is busy relabelling everything as an “agent” — a habit widespread enough that Gartner predicts over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. Underneath the noise, though, sits a genuinely specific piece of technology with a genuinely specific architecture. It is worth understanding precisely, because the difference between an agent that works and one that embarrasses you is mostly decided before you build anything.
This post is the definitional groundwork: what Agentforce actually is, how topics, actions, and the Atlas reasoning engine fit together, what ships out of the box, what running one responsibly involves, and who should — and shouldn’t — start now.
Agentforce, defined: autonomous agents on the Salesforce platform
Salesforce’s own definition is a reasonable starting point. Agentforce is a proactive, conversational AI solution made up of autonomous agents that sits on the Salesforce platform. An agent, in this context, is software that can understand a request in natural language, decide what needs to happen, and then take action — with or without a human in the loop.
The word doing the work in that definition is action. An Agentforce agent doesn’t just answer questions. It can look up an order, update a case, book a meeting, or trigger a Flow, using the same data model, permissions, and automation your org already runs on. That platform-native quality is the honest differentiator: the agent operates inside your existing security model rather than bolted on beside it.
Some quick lineage, because the naming history causes real confusion. Agentforce was announced at Dreamforce in September 2024 and absorbed the earlier Einstein Copilot assistant. Through 2025 it went through several fast releases, and at Dreamforce in October 2025 Salesforce rebranded the whole stack Agentforce 360, with Data Cloud simultaneously renamed Data 360. Same underlying platform, sixth-ish name. If someone in your org says Einstein Copilot, Data Cloud, or Agentforce 360, they are pointing at parts of the same thing.
Two other names you’ll meet. Agentforce Builder (previously Agent Builder) is the workspace where admins and developers define agents, largely in natural language. Atlas is the reasoning engine underneath — more on it shortly.
What Agentforce is not: a chatbot with a new badge
The fastest way to sharpen the definition is by contrast, because Salesforce has shipped conversational products for years and they are not the same thing.
Classic chatbots — Einstein Bots, in Salesforce terms — are decision trees. Every path is pre-programmed: the designer anticipates the question, scripts the answer, and anything off-script gets “Sorry, I didn’t understand that.” They are cheap, predictable, and rigid. Assistants of the Einstein Copilot era went a step further: they could understand free-form language and fetch answers from CRM context, but they fundamentally waited for a human to drive, one prompt at a time.
An Agentforce agent differs on both axes. It interprets intent rather than matching keywords, and it plans and executes multi-step work — retrieve the record, check the policy, perform the update, confirm the result — inside boundaries you define. Here is the comparison we draw on whiteboards:
| Rule-based chatbot (Einstein Bots) | AI assistant (Copilot era) | Agentforce agent | |
|---|---|---|---|
| How it decides | Pre-built decision tree | LLM interprets each prompt | LLM reasons over topics, then plans |
| What it can do | Scripted replies, simple lookups | Answer questions, draft content | Multi-step tasks and record changes |
| Who drives | The script | The human, turn by turn | The agent, within guardrails |
| Typical failure | ”I didn’t understand that” | Plausible answer, no action | Wrong action — which is why guardrails matter |
That last row is the important one. Autonomy raises the ceiling and the stakes at the same time. A chatbot that fails wastes a customer’s time; an agent that fails can change data. This is also why the industry’s habit of relabelling old products deserves suspicion — Gartner calls it “agent washing” and estimates only about 130 of the thousands of self-described agentic AI vendors are real. Agentforce, to be fair, is not a rebadged chatbot. It is a different architecture. Whether that architecture helps you is a separate question, and it depends on the parts that follow.
Topics, actions, and Atlas: the anatomy of an agent
Strip away the branding and an Agentforce agent is a small number of composable parts. Salesforce’s engineering team describes agents in terms of five attributes: role, data, actions, guardrails, and channel. In practice, you spend most of your build time on two of them.
Topics are the jobs-to-be-done. A topic groups a category of work — “order status enquiries”, “password resets”, “refund requests under policy” — and carries three things: a classification description that helps the agent recognise when a request belongs here, a scope that says what’s in and out of bounds, and natural-language instructions for how to handle it. Topics are the primary scoping mechanism. A well-run agent has narrow, well-described topics; a flailing one has a single mega-topic called something like “help customers.”
Actions are what the agent can actually do. Salesforce defines them as the building blocks that enable agents to perform tasks and interact with data — and each action maps to something deterministic underneath: a Flow, an Apex invocable method, a prompt template, or an API call, including MuleSoft-fronted external systems. This is the detail that experienced Salesforce people find reassuring. The AI decides which action to invoke and with what inputs; the action itself is ordinary platform automation that runs the same way every time, under the running user’s permissions.
The Atlas reasoning engine is the loop that ties it together. When a request arrives, Atlas classifies it into a topic, loads that topic’s instructions and available actions, then plans: what information do I need, which actions get it, what comes next? It retrieves data, executes the plan step by step, and evaluates the result before responding. Salesforce describes this as deliberate, “System 2” reasoning designed to reduce hallucinations compared with single-shot prompting. At Dreamforce ‘25, Salesforce also announced Agent Script, a way to express agent behaviour with explicit conditional logic for teams who want more deterministic control over that loop.
The mental model we give clients: the topic is the job description, the actions are the tools on the belt, the instructions are the standard operating procedure, and Atlas is the employee deciding — within all of that — what to do next.
Grounding through Data 360: why the data matters more than the model
An agent that reasons well but knows nothing about your business is a liability with good manners. Grounding is what connects the reasoning to reality, and in Agentforce that job belongs to Data 360 (the platform formerly known as Data Cloud).
The mechanism is retrieval augmented generation. Your knowledge articles, policies, files, and records get chunked and indexed; at runtime, retrievers search that index and feed the relevant passages into the agent’s context so answers come from your actual content rather than the model’s general training. The quick path is an Agentforce Data Library pointed at knowledge and files; the fuller path is a proper Data 360 implementation with harmonised, zero-copy access to data that lives outside Salesforce.
Around all of this sits the Einstein Trust Layer — zero data retention with the model providers, PII masking, toxicity detection, and an audit trail of prompts and responses. Useful, and genuinely ahead of what you get wiring an LLM up yourself. But don’t mistake guardrails for grounding. The Trust Layer stops data leaking; it does not make thin, stale, or contradictory content trustworthy.
In our experience this is where implementations are won or lost. If your knowledge base is outdated, your duplicate rate is high, or the policy the agent needs lives in someone’s inbox, the agent will faithfully reflect that mess back at your customers. The data work is the project; the agent is the interface to it.
The out-of-the-box agents, from Service Agent to Sales Coach
Salesforce ships a growing lineup of pre-built agents so you’re not starting from a blank canvas. The headline ones, as of early 2026:
- Agentforce Service Agent — the flagship. Handles customer service conversations across chat, messaging, and portal channels, grounded in your knowledge and case data, escalating to humans with context when it hits its limits.
- Agentforce SDR — engages inbound prospects, answers product questions, handles basic objections, and books meetings for human sellers.
- Agentforce Sales Coach — runs role-play and pitch practice for sales reps, grounded in the actual deal data on the opportunity.
- Agentforce Campaign Optimizer — drafts, personalises, and iterates marketing campaigns against a stated goal.
- Commerce agents — Merchandiser for site setup and promotions, Personal Shopper for guided B2C buying, and a Buyer agent for B2B reordering.
- Employee-facing agents — an Employee Agent (surfaced heavily through Slack) for internal questions and HR/IT-style requests, plus a widening set of industry agents in areas like financial services and health.
Two honest caveats from the field. First, “out of the box” describes the starting topics and actions, not the finish line — every one of these still needs your grounding data, your guardrails, your testing, and usually custom actions before it is production-worthy. Second, the lineup and packaging change quickly; treat any list, including this one, as a snapshot.
It is at least a snapshot with real usage behind it. Salesforce has said its own help-site agent passed one million customer conversations, autonomously resolving around 85% of queries — a vendor talking about its own product, yes, but also the largest public Agentforce deployment anyone can inspect.
What it takes to run an agent responsibly
Buying Agentforce and running it well are different undertakings. The responsible-operation checklist is short to state and long to do:
- Data readiness first. Current, deduplicated, findable content for the agent to ground on; clear ownership of who keeps it that way. If the answer isn’t written down anywhere, the agent cannot give it.
- Guardrails proportional to blast radius. Read-only lookups are cheap to trust. Actions that move money, change contracts, or touch regulated data belong behind human approval or outside the agent’s scope entirely.
- Adversarial testing before launch. Salesforce provides a Testing Center and a Testing API for batch-testing agents against utterance sets. Use them the way an annoyed customer would, not the way a demo script does.
- Monitoring from day one. Deflection rate, escalation quality, transcript review. An agent is a system you operate, not a feature you ship.
We’ve written a full post on the five decisions that separate production agents from demos, so we won’t re-cover that ground here.
One operational note that surprises budget owners: pricing is usage-based. As of this writing, Salesforce’s published model is Flex Credits at $500 per 100,000 credits, with a standard action consuming 20 credits — about $0.10 per action — alongside a $2-per-conversation option and per-user editions for employee-facing use. The practical consequence: a poorly scoped agent that takes six actions to do a two-action job costs three times what it should. Efficiency of topic and action design shows up directly on the invoice.
Where Agentforce fits — and a sober way to decide if you’re ready
Zoom out and Agentforce is best understood as a new interaction layer over disciplines Salesforce teams already know: clean data, well-factored automation, deliberate security, honest measurement. The reasoning engine is genuinely new. Everything that makes it safe to use is not.
That framing answers the “should we start now?” question better than any feature list. Start now if you have a high-volume, well-documented, bounded use case — password resets, order status, tier-one service — plus knowledge content someone actually maintains, and the appetite to treat launch as the beginning of a tuning loop. Wait if your knowledge base is fiction, your org is drowning in technical debt, or the motivating force is a board slide rather than a queue of tickets. An agent pointed at a broken process automates the breakage. And if you’re unsure whether your problem even wants an agent — as opposed to a Flow or some Apex — our decision guide on Flow vs. Apex vs. Agentforce walks through that choice, and our Agentforce readiness assessment gives you a blunt scorecard in a few minutes.
What you should take from this post is a working vocabulary. When a vendor says “agent,” you can now ask: what are its topics? What actions can it take, and what deterministic automation sits underneath them? What is it grounded on, and how fresh is that data? What can it never do? Those four questions cut through more or less all of the noise — Salesforce’s and everyone else’s.
Understanding the basics
What is Salesforce Agentforce?
Agentforce is Salesforce’s platform for building and running autonomous AI agents on top of your CRM data and automation. Agents understand natural-language requests, reason about what needs to happen using the Atlas reasoning engine, and take actions — looking up records, updating cases, invoking Flows — within guardrails you define. It was announced in September 2024 and rebranded Agentforce 360 in late 2025.
How is Agentforce different from a chatbot?
Chatbots follow pre-built decision trees: every path is scripted, and off-script questions fail. Agentforce agents interpret intent with a large language model, plan multi-step work, and execute real platform actions like editing records or triggering Flows. The trade-off is stakes: a chatbot that fails wastes time, while an agent that fails can change data — which is why scoping and guardrails matter far more.
What are topics and actions in Agentforce?
Topics are the jobs an agent can handle — each with a classification description, a scope, and instructions that tell the agent how to behave. Actions are the concrete tools available within a topic: Flows, Apex invocable methods, prompt templates, or API calls. The AI decides which action to use; the action itself is deterministic platform automation that runs the same way every time.
Trying to work out whether Agentforce belongs on your roadmap — and what it would take to run it well? Talk to us — grounded, governed agents are what we do.
