Agentforce pricing explained: the real consumption math
The most-asked question about Agentforce has no single-number answer, and any vendor who gives you one is guessing. Agentforce is priced on consumption: you pay for the work the agent does, not for a seat. That makes the real question not "what does it cost" but "what does it cost at your volume", and the difference between those two questions is where most Agentforce budgets go wrong.
Here is the model, plainly, without a stale figure that will be out of date by the time you read it.
Two costs, kept separate
The first discipline is to stop treating Agentforce as one line item. There are two costs, and they behave completely differently.
Salesforce's own consumption pricing. The agent's usage is metered. Each action it takes draws down credits, on top of the platform licenses you already pay for. This scales with use: a busy agent costs more than a quiet one, every month, forever.
The build. The engineering that makes the agent actually useful, data grounding, custom actions, evals, and guardrails. This is a one-time cost, scoped to what your agent needs to do.
Conflating the two is the classic budgeting error. The build is a project you can size once. The consumption is an operating cost that grows with adoption, and it is the one that surprises people.
How the consumption side actually works
Agentforce meters the agent's work as credits. An action, the agent answering, looking something up, updating a record, calling out to another system, consumes some of that credit balance. Salesforce revises the exact mechanics and rates periodically, which is precisely why anchoring to a specific per-action figure is a trap.
What does not change is the shape: your monthly cost is roughly your action volume multiplied by the current per-action cost. So the only inputs that matter are how many conversations your agent handles and how many credit-consuming actions each one triggers. Estimate those two numbers and the bill stops being a mystery.
Where it stops being cheap
Consumption pricing has a seductive property at low volume: near-zero commitment, no big upfront build, pay only for what you use. That is genuinely the right answer for a first agent or a modest workload.
The trap is assuming those economics hold as you scale.
| Low volume | High volume | |
|---|---|---|
| Agentforce (consumption) | Cheap; you skip the build and pay per use | Cost rises with every conversation, indefinitely |
| Custom agent (build + run) | Expensive; you pay to build before you save | Amortised build plus cheaper per-action running cost |
| Which wins | Agentforce, clearly | It depends on where your crossover sits |
Cost on the consumption model climbs with usage. Cost on a custom build is mostly the upfront engineering, after which the per-action running cost is lower. Plot both and they cross. Below the crossover, Agentforce is cheaper and faster to stand up. Above it, a custom agent can cost less over a year. The crossover point is specific to your volumes, and finding it is a spreadsheet exercise, not a vendor opinion.
This is exactly why we build both Agentforce and custom AI agents. When the recommendation does not depend on which product we happen to sell, the volume math gets to decide honestly. We build custom agents too, so "you have outgrown consumption pricing" is advice we can actually give.
How to model it before you commit
You do not need Salesforce's current price sheet memorised to get a defensible estimate. You need four numbers:
- Conversations per month the agent will realistically handle.
- Credit-consuming actions per conversation, on average.
- The current per-action or per-conversation rate, taken from Salesforce at the time you scope.
- The platform licensing already in place underneath.
Multiply the first three, add the fourth, and you have a monthly consumption estimate that survives contact with reality. Do it again at 3x and 10x your launch volume, and you will see your crossover point before you have spent anything. That modelling is the first thing a readiness assessment produces, because a number you can defend to your CFO is worth more than a demo.
The honest summary: Agentforce pricing is not expensive or cheap in the abstract. It is cheap at low volume and potentially expensive at high volume, and the only way to know which side of the line you are on is to run your own numbers through the current rates. Anyone who tells you a flat figure has skipped that step. For the marketplace side of the Salesforce economy, the same discipline applies to what actually gets AppExchange apps rejected: the cost that hurts is the one you did not model for.
