What Is Agentforce? Salesforce's AI Agent Platform, Explained

Agentforce is Salesforce's platform for building AI agents that take actions in CRM data: answering customer questions from a knowledge base, updating records, booking appointments, and handing off to a human when a request goes past what the agent is allowed to do. Three concepts define an agent. Topics scope what it handles, actions are the Flows, Apex methods, prompt templates, and API calls it can execute, and guardrails are the plain-language instructions that constrain it. A reasoning engine Salesforce calls Atlas connects them, interpreting each request and planning which actions to run. Pricing is consumption based, roughly $0.10 per standard action or $2 per conversation as of August 2026. The hard parts of a deployment are data readiness and governance, and both are covered below.

How an Agentforce agent is put together

An agent is configuration on top of automation you already own. You define it in Agent Builder, and the platform supplies the reasoning.

A topic is a job the agent is permitted to handle: order status, appointment scheduling, password resets, warranty questions. Each topic carries its own instructions and its own set of actions, which is how you keep an agent from freelancing. A service agent with four topics can answer four kinds of questions, and nothing else.

An action is a thing the agent can execute, and it is the most consequential design decision in the platform. Actions are built from Salesforce automation that already exists: a Flow that looks up an order, an Apex invocable method that files a return, a prompt template that drafts a reply, an API call through MuleSoft. If your order lookup already runs as a Flow, the agent can call it without new integration work. If the logic lives in a spreadsheet and one veteran employee's memory, you build that first.

Guardrails operate at two levels. You write topic-level instructions in plain language, for example that the agent must never quote a delivery date the order system does not show. Beneath that sits the Einstein Trust Layer, which masks personally identifiable data before prompts leave the platform, screens outputs, and logs generations for audit.

The Atlas reasoning engine runs the loop that connects these parts: classify the incoming request to a topic, check the instructions, select and execute actions, evaluate whether the result answers the question, then respond, ask a clarifying question, or escalate. There is no intent model to train and no dialog tree to draw. You scope topics, wire actions, and test.

Grounding comes from your data. Agents retrieve from knowledge articles and, in most production deployments, from Data Cloud, which unifies records across systems so the agent reasons over one view of the customer.

How Agentforce differs from Einstein and older chatbots

Salesforce has shipped AI under the Einstein brand since 2016, so the names blur together. The distinctions matter when you are deciding what to buy.

Einstein is the umbrella for predictive and generative features embedded in Salesforce clouds: lead scoring, opportunity insights, forecast predictions, drafted email replies. Those features make suggestions inside a screen a human is driving, and the human stays in the loop on every step.

Einstein Bots, the older chatbot product, followed dialog trees. You enumerated intents, supplied training utterances for each, and the bot walked a scripted path. Requests outside the script hit a dead end, and every new capability meant drawing more tree.

Agentforce, launched in late 2024, differs on two axes. It reasons over open-ended requests instead of matching them to trained intents, so coverage comes from topic scope rather than utterance volume. And it acts, executing reads and writes against CRM data rather than only answering questions. Einstein Copilot, the employee-facing assistant Salesforce introduced earlier that year, has since been folded into Agentforce as the employee side of the same platform.

The practical consequence for a project team is that the work moves from conversation design to action design, permissioning, and data quality. Teams that budget as if this were a chatbot rebuild consistently underestimate that second half.

What Agentforce costs

As of August 2026, Salesforce's published Agentforce pricing offers consumption models and per-user models, and the right one depends on whether the agent faces customers or employees.

The primary consumption model is Flex Credits at $500 per 100,000 credits. A standard action, one discrete thing the agent does such as retrieving order details or updating a record, meters at 20 credits, which works out to about $0.10. Voice actions meter at 30 credits, about $0.15. The alternative is Conversations at $2 per conversation for customer-facing agents, and Salesforce does not support both models in the same org. The arithmetic gives a breakeven: at $0.10 per action, the two models cross at 20 actions per conversation, so typical shorter interactions cost less on Flex Credits.

For employee-facing use, Salesforce sells add-ons for Sales, Service, and Field Service at $125 per user per month with unmetered employee agent usage, industry add-ons at $150, Agentforce 1 Editions from $550 per user per month bundling 2.5 million Flex Credits per org per year, and a $5 per user per month license that meters against Flex Credits. Salesforce Foundations includes the agent-building tools at no cost, so teams can prototype before buying credits.

Credits come with three buying models: pay as you go, a pre-commit baseline billed monthly, and pre-purchase up front at the deepest discount. Exceeding an entitlement bills at your contracted rate in arrears rather than at a penalty rate, and unused credits do not roll over.

What actually drives the bill is actions per interaction. Salesforce's own worked examples make the shape clear: a two-action order-status flow handling 20 requests a day runs about $120 a month, while a three-action case-management assist used by 100 service reps runs about $1,800 a month. Multiply your expected volume by the actions each request needs, and distrust any estimate that skips that step. Budget separately for the prerequisites: underlying Salesforce licenses, Data Cloud consumption for grounding, and the implementation itself. Verify current figures against Salesforce's published rate card before committing, because the model has already changed more than once since launch.

What deployment actually involves

Salesforce supplies the model. Most of the project is data, design, and testing work.

Data readiness comes first, because knowledge quality is the ceiling on answer quality. If your public answers live in agents' heads or in stale help articles, the first project phase is content, and skipping it produces an agent that confidently serves last year's policy. The same applies to records: an agent scheduling field visits needs territory and availability data that someone actually maintains.

Design comes next. Pick one or two narrow topics with measurable volume, wire actions from existing Flows where possible, and write instructions the way you would write a runbook for a new hire, with the refusals spelled out as clearly as the tasks.

Then comes testing, which is where agent projects differ most from chatbot projects. Agentforce ships a Testing Center that runs batches of synthetic utterances against the agent, so you can measure topic classification and action selection before a customer sees it. Test adversarially as well: off-topic requests, requests that try to talk the agent out of its instructions, and requests that mix a permitted job with an unpermitted one.

The last mile is wiring: the channel, whether web chat, in-app messaging, voice, or Slack, then escalation to a human queue with conversation context attached, then monitoring. Expect a tightly scoped first agent on clean data to take four to eight weeks, while integration work, content cleanup, or voice can push the timeline past a quarter. The sequencing follows the same discipline as our broader AI implementation services work: prove one workflow, instrument it, then widen.

When Agentforce fits, and when it does not

Agentforce fits when three things line up. The interaction volume is high enough to matter: at 20 credits per action, 5,000 monthly conversations that each need two actions cost about $1,000 a month, which is easy to justify against even one support hire and hard to justify for 40 conversations. The resolution paths are documented, or at least documentable. And the data the agent needs already lives in Salesforce or reaches it through Data Cloud.

It fits poorly when the knowledge base is thin, when the process depends on judgment calls nobody has written down, or when core systems sit outside Salesforce and the integration work would dwarf the agent work. In those cases the right sequence is to fix the data and the process first. It also fits poorly when nobody owns monitoring, because an unwatched agent in front of customers is a liability, and when a wrong action carries regulatory consequences that outweigh the labor it saves.

The governance questions to answer before an agent touches customers

An agent is a new principal in your Salesforce org, with credentials, permissions, and the ability to write. Treat the launch like a production access review rather than a feature flag, and answer these before go-live:

• What can the agent read and write? It runs under its own user and permission set, so scope both to the minimum each topic requires, at the object, field, and record level.
• Which actions are irreversible or externally visible? Refunds, record deletions, and outbound messages deserve human approval steps or hard caps until the audit trail has earned trust.
• How does it fail? Define the escalation path, the context that travels with it, and who can shut the agent off in minutes rather than in a change window.
• What reaches the model, and what is retained? Confirm how personally identifiable data is masked, what Salesforce and its model providers keep, and how long session logs live.
• Who reviews behavior, and how often? Someone must own transcript review, escalation rates, and injection testing as a recurring responsibility with a named owner.

The injection question deserves emphasis because traditional CRM security does not cover it. An agent that reads customer-supplied text and retrieved content can be steered by that content: a request phrased to look like an instruction, or a poisoned record a retriever hands to the model. Tight action scoping limits the damage, and testing for it belongs in every release cycle. That attack surface, and the controls that shrink it, are the subject of our agentic AI security practice.

Where BD Emerson fits

BD Emerson is an independent consultancy that implements Agentforce for clients. We are not Salesforce, we claim no partner tier, and we resell no licenses, so our sizing and buy-versus-wait advice carries no license margin. Our Agentforce consulting practice covers scoping, topic and action design, governance, and the deployment itself. If you are weighing whether the volume math and the data readiness are there yet, that assessment is a two-week exercise, and it is the right first step.