What is Agentforce? A plain-English explainer from implementers

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 on the renewal quote nobody remembers agreeing to.

The confusion is fair. Salesforce has renamed its AI products repeatedly, the marketing moves faster than the documentation, and the wider industry is relabelling everything as an agent. That habit is widespread enough that Gartner predicts over 40% of agentic AI projects will be cancelled by the end of 2027, citing rising costs, unclear value and weak risk controls.

Under the noise sits a specific piece of technology with a specific architecture. Understanding it precisely matters, because the difference between an agent that works and one that embarrasses you is mostly decided before you build anything.

Agentforce, defined

Salesforce’s own definition is a reasonable start. Agentforce is a proactive, conversational AI solution made up of autonomous agents that sits on the Salesforce platform. An agent here is software that understands a request in natural language, decides what needs to happen, and then does it, with or without a human in the loop.

The word doing the work is action. An Agentforce agent does more than answer questions. It can look up an order, update a case, book a meeting, or trigger a Flow, using the data model, permissions and automation your org already runs on. The real differentiator is that the agent operates inside your existing security model rather than bolted on beside it.

Some lineage, because the names cause 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 renamed Data 360 at the same time. Same platform, roughly its sixth 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 will 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 it, and I will come back to it.

What Agentforce is not

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 understood free-form language and fetched answers from CRM context, but they 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, make the update, confirm the result) inside boundaries you define. The comparison I 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

The last row is the one to remember. 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.

Which 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 is not a rebadged chatbot. The architecture is different. Whether that architecture helps you is a separate question, and it depends on the parts that follow.

Topics, actions and Atlas

Strip away the branding and an Agentforce agent is a small number of composable parts. Salesforce’s engineering team describes agents through 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, such as order status enquiries, password resets, or refund requests under policy, and carries three things: a classification description that helps the agent recognise when a request belongs there, a scope that says what is in and out of bounds, and plain-language instructions for handling it.

Topics are the main 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 do. Salesforce defines them as the building blocks that enable agents to perform tasks and interact with data, and each one maps to something deterministic underneath: a Flow, an Apex invocable method, a prompt template, or an API call, including MuleSoft-fronted external systems.

Experienced Salesforce people find this detail 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, and plans the information it needs, the actions that get it, and what comes next. It retrieves data, executes the plan step by step, and checks 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 that want more deterministic control over that loop.

The mental model I 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

An agent that reasons well but knows nothing about your business is a liability with good manners. Grounding 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 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 ahead of what you get wiring up an LLM yourself. But do not mistake guardrails for grounding. The Trust Layer stops data leaking. Thin, stale or contradictory content stays untrustworthy.

In my experience this is where implementations are won or lost. If your knowledge base is out of date, 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.

What ships out of the box

Salesforce ships a growing lineup of pre-built agents so you are not starting from a blank canvas. The headline ones, as of early 2026:

Agentforce Service Agent, the flagship. It handles service conversations across chat, messaging and portal channels, grounded in your knowledge and case data, and escalates 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 reps, grounded in the 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 or IT requests, plus a widening set of industry agents in areas like financial services and health.

Two caveats from the field. “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. And the lineup changes quickly, so treat any list, including this one, as a snapshot.

At least the snapshot has real usage behind it. Salesforce has said its own help-site agent passed one million customer conversations, resolving around 85% of queries on its own. A vendor talking about its own product, yes, but also the largest public Agentforce deployment anyone can inspect.

What running one responsibly takes

Buying Agentforce and running it well are different jobs. The checklist is short to state and long to do.

Data readiness first. Current, deduplicated, findable content for the agent to ground on, and clear ownership of who keeps it that way. If the answer is not 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.

I have written a full post on the five decisions that separate production agents from demos, so I will not repeat it here.

One operational point 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. A poorly scoped agent that takes six actions to do a two-action job costs three times what it should. Topic and action design shows up directly on the invoice.

Should you start now

Zoom out and Agentforce is a new interaction layer over disciplines Salesforce teams already know: clean data, well-factored automation, deliberate security, measurement you can trust. The reasoning engine is new. Everything that makes it safe to use is not.

That framing answers the timing question better than any feature list. Start now if you have a high-volume, well-documented, bounded use case, such as password resets, order status or tier-one service, plus knowledge content someone maintains, and the appetite to treat launch as the start 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.

If you are unsure whether your problem even wants an agent, as opposed to a Flow or some Apex, the decision guide on Flow vs. Apex vs. Agentforce walks through that choice, and the 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, ask four things:

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 most 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.

If you are working out whether Agentforce belongs on your roadmap and what it would take to run well, talk to us. Grounded, governed agents are what we build.