Agentforce Cost: Licenses, Usage and Implementation Pricing Explained

Ask two Salesforce customers what Agentforce costs and you can get two answers that are both correct and share no units.

One is billed per action against Flex Credits. One is billed per conversation against a rate card Salesforce last updated in December 2024, while separately consuming Einstein Requests and Data Services credits it was never told to track. Their Data 360 usage bills on entirely different models depending on which license sits in the org. If either bought Agentforce Voice Minutes, the per-action voice pricing on the public rate card stopped applying to them entirely.

None of it is hidden. It is scattered across separate rate card PDFs and a string of help articles, and which version applies to you depends largely on when you signed.

This page maps the currencies, the meters that feed them, the controls that exist, and what building an agent costs before any of it starts running. Where Agentforce sits inside a wider project budget is covered in the full implementation cost breakdown.

Four currencies bill Agentforce work and the contract date decides which

Salesforce has not replaced its billing units so much as accumulated them.

Flex Credits are the current unit. Actions, prompts, speech, personalization and Data 360 processing all draw from one balance at different multiplier rates.

Conversations are the older unit, and the model persists for customers who bought it. Its rate card is dated December 2024, covers a narrow named set of products, and states that use of certain Agentforce features also consumes Einstein Requests and Data Services credits. So a conversation-priced org is running three meters, and only one of them appears on the card it was sold.

Einstein Requests preceded Flex Credits. The current rate card scopes its prompt multipliers to products that no longer use Einstein Requests, which implies the unit remains live somewhere in the estate. If your order form mentions it, it is still metering you.

Data Services credits meter Data 360, and here the date is explicit. Salesforce states that orgs which purchased credits before 24 February 2026 consume Data Services credits for Data 360 services, while orgs purchasing or renewing after that date can have either Data Services or Flex Credits.

Two constraints follow. Flex Credits and Conversations are not supported in the same org, so migration means swapping every Agentforce Conversation SKU at once, with no gradual path. And because the currencies carry different entitlements, comparing quotes across them is not arithmetic, it is translation. Which unit you are on also changes what measuring agent return can even compare against.

Salesforce Foundations sits underneath all of this at no cost, carrying Agentforce Builder, Prompt Builder, Agent Script, Agentforce Coworker and Agentforce Vibes. That is the tier where an evaluation should start, because it establishes real action counts before anything is committed.

One buying-model caveat belongs in any plan built around commitment discounts. Salesforce lists three models, Pre-Purchase, Pre-Commit and PayGo, but describes Pre-Commit as becoming widely available later in the year, and it carries a true-up at term end if usage falls below the commitment. Pre-Purchase and PayGo are the models available to most buyers today.

The practical first step on any Agentforce cost question is therefore unglamorous: open Digital Wallet, look at which consumption cards are active, and establish which units the org actually spends before modeling anything.

Voice bills per action or per minute and the two cannot both apply

This is the mechanic most likely to produce a wrong forecast, because the public rate card shows only half of it.

The main rate card prices voice actions at 30 credits in production and 24 in sandbox. Salesforce publishes a second, supplemental rate card for Agentforce Voice Minutes, which prices voice at 60 credits per minute in production and 48 in sandbox. That card carries an override in its own footnote: the Agentforce Voice Actions usage types on the Flex Credits rate card do not apply to customers who have purchased Agentforce Voice Minutes, and the per-minute usage type applies instead.

The two models are mutually exclusive, and they invert under load.

The crossover sits at two actions per minute. A dense interaction that resolves quickly is cheaper on minutes. A slow conversation with long pauses, hold music or a caller thinking is cheaper on actions, because silence bills on one model and not the other.

That makes containment strategy a pricing decision. Under per-minute billing, every second spent waiting for a customer to find their account number is billable. Under per-action billing it is free. Few contact centers know which card their org is on before they design the flow, and the supplemental card is not linked from the main pricing page.

Salesforce’s own budgeting scenario burns 35 percent of a year in thirty days

The most useful consumption figure Salesforce publishes sits inside a training module rather than a pricing page.

In its Agentforce Vibes licensing and monetization module, Salesforce sets a budgeting scenario: a company migrates 50 developers from the free tier to a paid credit-based plan, velocity rises, and at the end of week four the admin opens Digital Wallet to find the team has burned 35 percent of the annual Flex Credit budget in the first 30 days. Salesforce’s own text notes that at that rate the credits run out before month four, blocking development mid-sprint.

Two qualifications matter. This is Salesforce’s teaching scenario, not reported customer telemetry, and it describes Agentforce Vibes, the developer coding agent, rather than customer-facing service agents. Coding agents are token-hungry in ways a case-deflection agent is not.

The instructive part is not the number but what Salesforce prescribes against it. Its own optimization list reads: limit regenerations and avoid excessive retries, share only the files that matter instead of entire repositories, start fresh threads so context stays contained, use lighter models for daily work and reserve premium models for complex tasks, and set threshold alerts.

Every item on that list is a context-size control. Salesforce is telling you, in its own training material, that the dominant cost driver is how much context each interaction carries. That reframes the unit price entirely. Twenty credits is what an action costs; how much you send with it is what decides the bill.

Agent building is unmetered while previewing and testing are not

Salesforce divides billing by lifecycle phase, and the boundary falls in an unexpected place.

Salesforce states that during design and development, Agentforce Builder features for creating and building agents are not metered and consume no credits. The exception arrives immediately: Salesforce meters usage when you preview an agent in chat or voice.

Testing and validation is metered outright. Salesforce states that testing through Agentforce Builder, Agentforce Grid, Testing Center and sandbox is metered to account for required compute resources, covering both preview options and batch test runs. Agentforce Grid is metered regardless of which phase it is used in.

Set that against how agent development actually goes. You write a topic, preview it, change an instruction, preview again, and iterate dozens of times before behavior stabilizes. Every preview bills. A batch test across a few hundred utterances bills once per action, multiplied by the actions each utterance triggers.

The amounts are individually small, which is exactly why they go unbudgeted. They accrue during the phase everyone assumes is free, spread across weeks, against the same balance production will later draw down. A pilot scoped with a fixed allocation and no test line discovers this when the allocation runs dry before go-live. Planning that volume belongs in testing agents before production rather than in a later finance conversation.

Pre-production rates discount actions and leave prompts at full price

The rate card prices sandboxes separately, and the discount is not applied evenly.

Salesforce defines the pre-production rate broadly, covering scratch orgs as well as sandboxes.

Actions and voice take a twenty percent pre-production discount. Prompts take none, so prompt-heavy development work in a sandbox pays production rates.

The prompt scale itself is steep. An advanced prompt costs eight times a basic one and eighty percent of a full standard action. Prompt template design in Prompt Builder is therefore a budget decision as much as a quality one, and few teams treat it that way, because the tier a template falls into is not surfaced where the template is authored.

Help Agent Resolutions sit at 400, the highest multiplier of any per-interaction agent usage type, and the only one priced at zero in sandbox. Speech is metered in its own units entirely, by the hour for transcription and by the million characters for synthesis and translation, with no pre-production discount on any of them.

Data 360 bills three different ways depending on the license in the org

The second meter is usually larger than the agent meter, and which version of it applies is a licensing question rather than a usage question.

An org running Data 360 under a Customer Data Platform license is billed against contracted entitlements for Unified Profiles, Segment Publishes and Engagement Events, with overages billed monthly at contracted rates. The billable profile count is computed from records in data lake objects mapped to profile-type data model objects, plus known unified profiles across every active identity resolution ruleset. Salesforce’s own worked example totals 25,000 billable profiles from two rulesets at 10,000 and 8,000 plus two unmapped profile objects at 2,000 and 5,000.

An org running under a Data Cloud license with an active Data Services consumption card is billed against the Data Services usage types.

An org running under a Data Cloud license without that card is billed by rate card multipliers, per million rows or per megabyte, with volume tiers that fall as usage rises and reset on the first day of each calendar month. Sandbox Data 360 skips tiering entirely and sits at the tier two rate across every usage type.

A Data 360 Profiles license layered on top stops some features consuming credits at all.

Three consequences for anyone budgeting. Two orgs with identical agent designs can receive structurally different Data 360 bills. Volume discounts do not accumulate across a quarter, so spiky processing is penalized against steady processing. And the entitlement model has no per-unit rate to model against at all, which means a forecast built from the rate card is simply the wrong instrument for a CDP-licensed org.

Joins, re-queries and cross-region reads multiply billable rows

Underneath the usage types sit counting rules that turn architecture choices into cost differences, and these are where real money moves.

Joins multiply. For streaming data transforms, Salesforce calculates rows read by multiplying the records from the streaming input object by the number of joined objects. A transform joining three objects bills three times the row count of a transform joining one.

Region and cloud boundaries bill. For data federation and data shares, Salesforce states there is no credit consumption when a query originates from the same region and the same cloud. Cross-cloud and cross-region queries consume. The same query costs nothing or something depending on where the target sits.

Ingesting Salesforce data is free. As of 7 August 2025, internal data pipeline usage covering structured data brought in through the CRM, Marketing Cloud, Commerce Cloud and Marketing Cloud Personalization connectors no longer consumes credits. Cost articles written before that date still bill for it.

A configuration flag changes the meter. Streaming ingestion bills as a streaming pipeline, but the same ingestion API used in bulk mode bills as a batch pipeline instead, at a different rate.

Repeat processing is discounted, once. Batch data transforms bill on changed rows only after the first run. Batch profile unification counts only new or modified source profiles after a ruleset’s first execution, where modified includes deleted profiles and those suppressed through Consent API preferences. Data share rows count only on the initial full batch, not on subsequent increments.

Chunking and vectorizing the same document counts once. A 100 MB PDF chunked and embedded bills as 100 MB, not 200. But indexing text fields from a data model object bills the sum of all bytes in those fields, which is how a search index over a large object becomes expensive quietly.

Read together, these rules say something that no price table conveys: the largest single lever on an Agentforce bill is the data architecture behind the agent, not the agent. Grounding design belongs in the cost conversation, which is also why readiness checks belong before spend rather than after.

Digital Wallet reports on a sync delay and enforces nothing

The control surface is real, and it is worth knowing precisely what it does and does not do.

Digital Wallet is reached from the App Launcher, with consumption cards per product. The Flex Credits card carries a Consumption Overview tab for drivers and forecasting and a Consumption Explorer tab for breakdowns by agent, action or data source. Four fields carry the signal: credits consumed since activation or reset, credits remaining, the usage type breakdown, and a last-processed timestamp.

That last field deserves attention. It records the most recent data sync, which means the figures lag behind live. An agent misbehaving now shows up in the console after a delay, so the console is a monitoring instrument rather than a circuit breaker.

Alerts are not a setting. Salesforce’s documented path is to build them: open Setup, find Flows, create a new flow from the Consumption Threshold Alerts template, then save and activate. Percentage triggers can be set org-wide or per card, and alerts can route to admin email, system notifications or a Slack channel. Custom tags let consumption be attributed to teams or individuals, which is the only practical way to answer the question of which team burned the quarter.

What none of this does is stop spending. Salesforce’s position is that there is no overage penalty, that exceeding entitlement bills at the contracted rate monthly in arrears, and that overages are prevented using alerts. Alerts notify. Nothing caps. A misconfigured agent on a Friday evening keeps billing through the weekend, and the available control is a notification that somebody has to read and act on. That makes consumption an operational responsibility with a named owner, which is part of who owns the agents after go-live.

One provisioning detail catches teams at setup. If the required permission set license is missing under Setup, the org lacks the relevant SKU: a Foundation Entitlement SKU for metered access, or the Agentforce 360 Platform Developer and Admin Tools SKU for unmetered. Salesforce notes the entitlement chain is cumulative, so unmetered access requires a working metered foundation underneath it. Unmetered is not a substitute for metered, it is a layer on top.

Implementation cost divides into scoping, build and the credits the build consumes

The licensing and consumption meters are published. The third cost is not, and it is usually the largest in year one.

Implementing an agent is a delivery project with a familiar shape and one unfamiliar line. The familiar parts are discovery to establish which use cases justify an agent, design of topics, actions and guardrails, integration work where actions call systems that are not Salesforce, knowledge preparation so retrieval returns answers worth giving, testing, and change management for the humans whose work the agent alters.

The unfamiliar line is that the build consumes the same credits production will. Preview iterations, batch test runs, sandbox actions at 16 credits and sandbox prompts at full production rate all draw on the balance before a single customer interacts with anything. Any implementation quote that separates services fees from consumption without estimating the consumption its own testing will cause has left a real number off the page.

Three questions surface whether a proposal has done that work. Ask how many actions each proposed use case takes end to end, because that number comes from design and should already exist. Ask what test volume the build assumes and what it will consume. Ask which Data 360 usage types the grounding design triggers, since that is where the larger meter runs.

A proposal that answers all three has modeled the thing. A proposal that quotes a day rate and points at Salesforce’s pricing page has not, and the difference is the same one that separates a defensible project estimate from a rate card. Sequencing a contained first build, not a broad one, is the point of a timeboxed pilot.

Salesforce prices five use cases publicly, and one of them miscalculates

The most useful published artifact for forecasting is not the rate card. It is the worked examples on Salesforce’s pricing page, because they show action counts per interaction, which is the number you cannot get anywhere else.

Check the dates before you reuse these. Salesforce revised this page on 28 August 2026, and the field service example changed in that revision: an earlier version listed six actions at 120 credits for $360 a month, where the current one lists five actions at 100 credits for $300. The example was restructured, not merely repriced. Anyone quoting a figure from a cached copy is quoting a number Salesforce has already moved.

Two things in the table repay attention.

The field service example still lists a repeated call, retrieving appointment time slots a second time within one interaction. Repeats bill every time. An agent that loops because its instructions are ambiguous is not simply slower, it is proportionally more expensive, and the cost of a poorly scoped topic lands on the invoice instead of in a quality report.

The voice row contains an arithmetic error on Salesforce’s own page. Four voice actions at 30 credits each gives the 120 credits stated. At the conversion used in the other four examples, 120 credits is sixty cents, not the fifteen cents printed. The monthly total of $180 across 300 calls is consistent with sixty cents per call, so the per-interaction cell is the error rather than the total. Model voice from that cell and you underprice it fourfold.

Salesforce attaches its own caveat to every example, confirming that Data 360 and other consumption services sit outside these figures entirely.

Where GetGenerative.ai changes the number

Consumption is decided upstream of the build, which is where the agents on this platform operate.

The decisions that set an Agentforce bill are made during discovery and design: how many actions a topic requires, whether it re-queries data it already holds, how much context each call carries, whether grounding runs against a prepared dataset or resolves identity continuously, and how many iterations the build takes to stabilize. Salesforce’s own optimization guidance is a list of context-size controls, which means the specification determines the invoice.

The Discovery agent turns workshops into structured requirements instead of transcripts. The Design agent produces the topic and action definitions an action count can actually be read from, which is what converts a forecast from estimate to model. The Metadata agent supplies existing org context, so grounding is scoped against what is there instead of what is assumed. The Test agent produces the case library, which is how metered test volume becomes a planned line rather than a surprise.

Fixed-scope alternatives exist for teams that would rather not discover their consumption empirically, and agents live in about two weeks sets out what those cover.

The short version

Agentforce has no single price because it has no single meter. Your contract date determines your currency, your license determines how Data 360 bills, your voice SKU determines whether minutes or actions apply, and your data architecture determines the size of the largest meter running.

The published per-action rate is the least variable number in the model and the one every article leads with. The variable numbers are context size, test volume, join depth and region topology, and all four are set by design decisions made before procurement.

Model those, then buy. Buying first and measuring afterwards is how a 30-day burn reaches a third of an annual allocation, which is the scenario Salesforce chose to teach with.

Questions buyers ask about Agentforce cost

How much does an Agentforce action cost?

A standard or custom action consumes 20 Flex Credits in production and 16 in a sandbox or scratch org. Voice actions consume 30 and 24. Prompts are metered separately on a scale running from 2 credits for starter and basic prompts to 16 for advanced prompts, with no sandbox discount at any tier.

Is Agentforce Voice billed per action or per minute?

Both models exist and only one applies to a given customer. Customers who have purchased Agentforce Voice Minutes are billed at 60 credits per minute in production and 48 in sandbox, and Salesforce states that the per-action voice usage types stop applying to them. The crossover is two actions per minute, so dense short interactions favor per-minute billing and slow interactions favor per-action.

Does building and testing an agent consume credits?

Building does not. Previewing does. Salesforce states that Agentforce Builder features for creating agents are unmetered, that previewing an agent in chat or voice is metered even during development, and that testing through Builder, Agentforce Grid, Testing Center and sandbox is metered.

How much does an Agentforce Service Agent license cost?

There is no per-seat SKU by that name on the current pricing page. Customer-facing service agents are billed through consumption, using either Flex Credits or Conversations depending on which model your org is on. The per-user add-on at 125 dollars covers unmetered usage for employee-facing agents, which is a different thing. If a quote names a Service Agent license, ask which of the two consumption meters sits behind it.

Why is Data 360 billed differently for different orgs?

Because the billing model follows the license. A Customer Data Platform license bills against entitlements for Unified Profiles, Segment Publishes and Engagement Events. A Data Cloud license bills either against Data Services usage types or against rate card multipliers with monthly-resetting volume tiers, depending on whether a Data Services consumption card is active. Purchase or renewal date matters too, with 24 February 2026 as the dividing line Salesforce names.

Can Digital Wallet stop an agent from overspending?

No. It reports consumption on a sync delay and can raise threshold alerts routed to email, notifications or Slack, built from a Consumption Threshold Alerts flow template. Salesforce applies no overage penalty and bills excess at the contracted rate in arrears, so nothing enforces a ceiling automatically.

What drives an Agentforce bill more than the per-action rate?

Context size and data architecture. Salesforce’s own cost optimization guidance is a list of context controls, and its Data 360 counting rules mean joins multiply billable rows, cross-region queries consume where same-region queries do not, and search indexes over large objects bill the full byte count of the fields indexed.