Agentforce & Salesforce AI

Agentforce is Salesforce’s agent platform: autonomous AI agents that reason over your CRM data, take scoped actions in Salesforce, and hand off to a human when they cannot resolve something. It runs inside your org, under your security model — not a chatbot bolted onto the side of it.

An agent is built from four parts. Topics say what it is for — order status, returns, lead qualification — each with instructions written in plain language. Actions are what it may do: run a Flow, call Apex, fill a Prompt Builder template, query Data 360. The Atlas reasoning engine decides which action a request needs and in what order. Guardrails and the Einstein Trust Layer decide what it must not do and what it is never shown. Get those four right and the model underneath matters far less than people expect.

Agentforce vs Einstein Copilot

Einstein Copilot was the conversational assistant Salesforce shipped in 2024: it sat beside a user inside Sales or Service Cloud, answered questions and drafted content when asked. It has since been folded into Agentforce as the assistant employees use in the flow of work, so the name is mostly history. The difference it described still matters. An assistant works for the person typing and waits to be prompted. An agent works for the business: it can act on a trigger — a new lead, an inbound message, a case that has sat too long — with nobody in the loop, inside permission boundaries you set, and it escalates when it reaches the edge of them.

Most orgs end up with both: an assistant that makes each rep or service agent faster, and one or two autonomous agents on the highest-volume work, where nobody needs to be involved at all.

What Agentforce actually needs from your org

Most stalled Agentforce projects stall here, before anyone has written an instruction. Four things have to be in place first.

• Einstein generative AI, switched on. Under Einstein Setup, on an edition that carries it — Enterprise and above. If your org already uses Einstein for predictions you are part of the way there, but the generative features are a separate toggle with separate terms.
• Grounding in Data 360. An agent answers from what it can retrieve. Data 360 unifies records from Salesforce and your other systems into one profile, and indexes unstructured content — Knowledge articles, policy documents, product manuals — so the answer comes from your document rather than the model’s general knowledge. The step teams miss is the mapping: if Data 360 is not mapped to the Salesforce objects the agent reasons over, it retrieves the wrong context and answers confidently anyway.
• Permission sets and a dedicated agent user. The people who build and manage agents need the Agentforce permissions assigned. A customer-facing agent runs as its own agent user, and that user’s profile, permission sets and field-level security decide which objects and fields it can read and which it can write. Missing read access makes an agent fail quietly or answer from half a record; more write access than it needs makes it a liability. We grant read broadly enough to resolve and write only where the agent is meant to act.
• An Agentforce licence. Salesforce Foundations lets you build and test for free. Putting an agent in front of customers or employees needs one of the paid models below, and which one depends on who the agent serves — worth deciding before the build rather than at the first invoice.

Service gets most of the attention, but sales is where the arithmetic is easiest to prove, because the before and after sit in pipeline reports you already run. Three jobs account for nearly all of it.

Lead qualification and routing

Reps lose most of their inbound time to leads that were never going to buy. An agent can take first contact on every inbound lead — a web form, a chat, a reply to a campaign — ask the questions your team would ask (company size, timeline, the problem they are trying to solve), score the answers against your ideal customer profile, and route only the leads that pass to the right account executive with the conversation attached. Leads that are not ready go into a nurture sequence with timed follow-ups and a re-engagement trigger, instead of into a rep’s queue to be ignored.

The build is less about the agent than about writing down criteria that currently live in your best rep’s head. We start there, and the qualification rules become Flow logic the agent calls, so an admin can change them without touching the agent. For outbound prospecting Salesforce ships a prebuilt agent — our walkthrough of Agentforce SDR agents covers what it does out of the box and where it needs configuring.

Meeting scheduling and follow-up

Pipeline leaks between “let’s find a time” and the calendar invite. An agent can book the meeting inside the conversation: it checks the right rep’s availability, sends the invitation, confirms it, and reschedules when something moves. After a demo or discovery call it can send the recap, attach the relevant case study, log the activity and set the next touchpoint, so nothing depends on a rep remembering to update the record at six in the evening.

The handoff is the part to get right. When a prospect moves from the agent to a person, the rep should see the whole conversation — what the agent qualified, and what it promised — in their console before they say hello. A prospect who has to repeat themselves has been handed off badly, whatever the agent did before that.

What it replaces on a rep’s week

Salesforce’s own State of Sales research puts the time reps spend on work that is not selling at roughly 70% of the week: data entry, record updates, internal email, scheduling, preparing for meetings. That is the time an agent can give back. It will not replace the conversation that closes a deal, and it should not try; it replaces the admin around it — logging calls, moving opportunity stages on what was actually said, drafting follow-ups, chasing no-shows.

We measure it the plain way: lead-to-meeting conversion, speed to first response on inbound, and hours of CRM admin per rep per week, each benchmarked before launch. If those three do not move, the agent is not doing the job, whatever its resolution rate says.

There are two bills: what Salesforce charges to run agents, which recurs and grows with use, and what the implementation costs, which you pay once. The first is the one that surprises people, so it gets most of this section.

Salesforce licensing models

Salesforce sells Agentforce three ways. Consumption — Flex Credits, or a price per conversation — covers agents that talk to customers, and employees who use agents without a full Salesforce seat. Per-user add-ons cover employees who already hold Sales, Service or Field Service licences, with unmetered use inside those seats. Salesforce’s published list prices, in US dollars, as of September 2026:

The arithmetic worth doing before you choose: at $500 per 100,000 credits and 20 credits a standard action, each action costs $0.10 at list. A conversation-priced exchange costs $2 however many actions it takes, so Flex Credits stay cheaper until a conversation averages twenty actions — and most resolved service conversations run a handful. The free Salesforce Foundations tier includes Agentforce Builder and Prompt Builder, so building and testing can start before a paid model is chosen. Credits can be bought upfront or pay-as-you-go, with a pre-commit option rolling out. Prices change; confirm them on Salesforce’s Agentforce pricing page and with your account executive before you budget.

Implementation cost

The implementation is a one-off engagement, separate from the licence, and four things set its size: how many topics the first agent covers, how many actions have to be built rather than reused from Flows you already run, how clean the data it will be grounded in is, and how many channels it launches on. A first agent on one high-volume use case — inventory, grounding, build, testing against your real transcripts and a monitored launch — typically reaches its first release in six to eight weeks.

The price is fixed after the inventory, about two weeks in, and it holds; change requests are priced openly rather than absorbed and billed later. We would rather make you wait two weeks for a number than give you one on the first call that is designed to win the work.

What surprises people at renewal

Consumption. The licence you signed for was sized on the pilot, and a successful agent does not stay a pilot: it gets more topics, more channels and more traffic, and every one of those draws on the same pool. A pre-purchased balance runs out before the term does; a commitment ends in a true-up. Data 360 usage — ingestion, queries, retrieval — is metered as well, so grounding a busy agent in a large data set costs something even when the agent itself is cheap.

None of that is a reason not to build. It is a reason to model expected volume before the build — conversations a month, actions per conversation, the channels in scope — and to instrument actual usage from launch day, so the renewal conversation is about a number you already know.

How to measure whether it paid for itself

Deflection alone tells you little: an agent can deflect a customer straight into a second contact. These four measures, captured before launch and reviewed monthly, tell you whether the spend is returning anything:

• Cost per resolution, agent-handled against human-handled, with the Flex Credit cost of each agent conversation included.
• Time to first meaningful action — not the first reply, but the first step that moves the case or the lead forward.
• Customer effort score on agent-assisted interactions, because a resolution the customer had to fight for is not one.
• Revenue influenced by agent-initiated outreach and agent-qualified leads, for sales use cases.

Put those next to the deflection baseline and the question at renewal stops being whether the agent is worth it and becomes where to point it next.