The three places Agentforce costs you money, and only two are on the invoice
Agentforce is the agent layer Salesforce built into its own platform, and since the October 2025 rebrand the whole stack is sold as Agentforce 360: the Agentforce Platform itself, Data 360, the Customer 360 applications and Slack, held together by Salesforce metadata, MuleSoft and Data Cloud. For a US enterprise that already runs Sales Cloud or Service Cloud, this is the path of least resistance into production agents, which is exactly why the finance question arrives late.
Money leaves through three doors and they behave very differently. The first is seats, the familiar per-user line that a procurement team already knows how to model. The second is consumption, the Flex Credit meter that runs every time an agent takes an action, and that one is genuinely new: it is not bounded by headcount, it is bounded by agent activity, and agent activity is the thing you are trying to increase. The third door is the one nobody puts in the business case. An Agentforce agent that calls out through a Flow, an Apex callout or a MuleSoft connector can cause a purchase: renew a subscription, top up a balance, release a payment, place an order. That money never appears on a Salesforce invoice at all, because Salesforce is not the one charging you for it.
The first two doors have meters. The third has nothing, and the first two have meters rather than valves. That distinction is the whole subject of this page.
What Agentforce pricing actually looks like in 2026
Salesforce publishes its Agentforce rates openly, which makes this part easy to get right. The figures in the table below were read from the Salesforce Agentforce pricing page on 16 September 2026 and are US list prices. Two models run side by side. The older one charges 2 dollars per conversation, which is simple but punishes a chatty agent that resolves nothing. The newer one charges Flex Credits at 500 dollars per 100,000 credits, which works out to half a cent per credit, and then prices work in credits: a standard Agentforce action is 20 credits, so 10 cents, and an Agentforce Voice action is 30 credits, so 15 cents.
Ten cents an action sounds harmless, and at pilot scale it is. The arithmetic only gets interesting when you multiply by the volume an agent program is supposed to produce. A single agent handling 2,000 interactions a day, at a modest four actions each, is 8,000 actions, which is 160,000 credits a day and 800 dollars a day at list. Run it across a month and you are past 24,000 dollars on one agent. None of that is a criticism of the pricing, which is fair and arguably fairer than per seat. It is an observation about shape: a per-action meter turns a fixed cost into a variable one, and variable costs need ceilings rather than forecasts.
How we measured what Salesforce can express about agent spending
Opinion is cheap here and vendor marketing is worse, so we did what we do on every vendor page: we went to the published schema. Salesforce documents every standard object in the Object Reference, and that document is available as machine-readable JSON in one request. The version we pulled on 16 September 2026 is Winter 27, API version 68.0, document version 264.0, and its table of contents enumerates 1,757 documented standard objects.
The object model is the right place to look, and it is worth saying why. In Salesforce, policy is data. A permission, a limit, a threshold, an approval step, an entitlement: every one of those is a record on an object somewhere, because that is how the platform is built. If no object exists to hold a value, no admin screen, roadmap slide or consultant can make the platform store it. So the question becomes narrow and answerable: does Salesforce document any standard object where the agent vocabulary and the money vocabulary meet.
We ran two vocabulary passes over the full list of 1,757 object names. The agent pass matched GenAi, Agent, Bot, Einstein, Copilot and Robot. The money pass matched Payment, Invoice, CreditMemo, Amount, Currency, Price, Cost, Budget, Spend, Billing, Order, Quote, Refund, Revenue, Fee, Discount, Ledger, Payout, Purchase, Expense, Transaction, Cart, Checkout, Wallet, Card and Tax.
Then, because a regex that finds nothing is usually a broken regex, we ran a control. The control matched neutral Salesforce platform vocabulary, the suffixes and siblings that every mature object family in the platform carries: Definition, Share, History, Feed, Event, Log, Setting and Config. If the agent family were a thin, half-finished corner of the schema, the control would come back nearly empty there and the real finding would be uninteresting.
The result: 178 money objects, 41 agent objects, zero overlap
The money pass matched 178 of the 1,757 objects. Salesforce models money in enormous detail, as you would expect from a company that sells Revenue Cloud: AlternativePaymentMethod, CardPaymentMethod, CreditMemo and CreditMemoLine, Invoice and InvoiceLine, CartItemPriceAdjustment, CartTax, BillingSchedule, BillingPolicy, BillingTreatment, Expense and ExpenseReportEntry, and 160-odd more.
The agent pass matched 41 objects: the GenAi family that actually is Agentforce (GenAiPlannerDefinition, GenAiPluginDefinition, GenAiFunctionDefinition, GenAiPlannerFunctionDef, GenAIConversationSummary), the older BotDefinition and BotVersion, the AgentWork routing family, the ProspectingAgent research family, the RpaRobot family and a handful of others.
The intersection is zero. Not small, not one or two edge cases: no documented standard object name carries both vocabularies. And the control behaved exactly as a working control should. Neutral platform vocabulary matched 11 of the 41 agent objects and 16 of the 178 money objects, so both families are ordinary, fully modelled Salesforce object families with the usual Definition, Share, History and Log siblings. The agent family is not a stub that Salesforce has yet to flesh out. It is a mature family that has no money object in it, which is a design decision rather than an oversight.
Read plainly, that is the finding: Salesforce has 178 ways to describe money and 41 ways to describe an agent, and no way to describe an agent budget.
Digital Wallet tells you. It does not stop you.
The obvious objection is Digital Wallet, and it deserves a straight answer because Salesforce genuinely did build a consumption tool and it is a good one. Digital Wallet shows credit balances and burn rate across consumption products, projects when capacity runs out, and sends threshold alerts by email, commonly configured at 50, 75 and 90 percent, with additional alerting possible through Flow.
Every one of those verbs is a reporting verb. Digital Wallet observes consumption and tells a human about it. It does not hold an action pending, refuse one, or switch an agent off, and Salesforce practitioners have made the same point publicly: there is no kill switch that freezes agents or agent actions when a threshold is hit. So the honest description is a smoke alarm, not a sprinkler. It is genuinely useful, it will save somebody a nasty quarter, and it is not a limit, because a limit is a thing that refuses. An alert that fires at 90 percent on a Friday evening while an agent is looping is a record of the overspend, not a prevention of it.
This is the same pattern we found at every other vendor. The payment MCP servers expose write access to live payment APIs and none enforces a ceiling. The accounting and ERP MCP servers govern which tools a model may call against your books, never the amount. Microsoft Agent 365 governs agent identity and access and expresses no monetary amount anywhere in Graph. Google went furthest of all and shipped a cap that genuinely refuses work, and even there the Gemini Enterprise spend limit is a Cloud Billing budget scoped to a project, with no dimension that can identify which agent spent the money. AWS went furthest and shipped an actual number, and even there AgentCore gives you one optional per-session amount with no daily or monthly total behind it.
What Agentforce permissions genuinely do control
It would be unfair and inaccurate to suggest Agentforce is ungoverned. It is one of the better-governed agent platforms on the market, and the controls are real, so it is worth being precise about what they cover.
An Agentforce agent is scoped by a running user, and that user carries a profile, permission sets and sharing rules, so the agent inherits an object and field level security model that Salesforce has spent twenty years hardening. Topics bound what subjects an agent will engage with. Actions are an explicit allow list: an agent can only invoke the Flows, prompt templates, Apex methods and standard actions you have attached to it. Agent Script constrains behaviour deterministically rather than leaving it to the model. There is built-in observability, and the Einstein Trust Layer handles data masking and grounding.
Every one of those answers the question what may this agent do. None of them answers how much may this agent commit. You can grant an agent an action that releases a payment, and the permission model will faithfully check that the running user is allowed to release payments. It has no opinion about whether this is the fortieth payment in an hour, whether the counterparty is new, or whether the total has passed a number that should require a human. Those are finance questions, and the object model shows there is nowhere in the platform to put the answer.
The second money gap: what the agent buys
The Flex Credit meter is the gap people notice, because it lands on a Salesforce invoice and somebody has to sign it. The larger exposure is usually the one that does not.
Agentforce agents are wired into the rest of the business on purpose. That is the pitch and it is a good one. An agent with a Flow, an Apex callout or a MuleSoft connector can reach a supplier portal, a payables system, an ads platform, a SaaS billing API, a Commerce Cloud order or a metered vendor API. Every one of those is a way to move real dollars, and none of them is measured in credits. If an agent renews an annual contract, tops up an ad account or releases a batch of supplier payments, the Salesforce bill is a few cents of actions and the actual cost is somewhere else entirely.
So the two exposures scale differently and want different controls. Consumption is many tiny charges that add up, and it wants a hard ceiling and a rate limit. Purchasing is a small number of large charges, and it wants a per-transaction cap, a counterparty allow list and a human above a threshold. Digital Wallet is aimed at the first and, being an alerting tool, only partly reaches it. Nothing in Salesforce is aimed at the second, because there is no object for it.
Where a spend policy layer fits on top of Agentforce
None of this argues against Agentforce, and there is no overlap to argue about. Salesforce owns the agent runtime, the data grounding, the permission model and the enterprise context, and no startup is going to do that better. The layer the object model shows is empty is the one in front of the money: the decision about whether a particular payment, at this amount, to this counterparty, at this point in the month, is allowed to proceed.
That is what agent spend controls are for. You keep Agentforce as the platform, keep the permission sets and topics doing what they already do well, and put a policy between your agents and your bank: a budget that actually aggregates across a day, a week and a month rather than resetting per session, a merchant-locked virtual card so an agent authorised to renew one vendor cannot pay a different one, an approval threshold that holds a payment for a named human above an amount you choose, a velocity rule for the looping-agent case, and an audit trail that reconciles to your books in dollars. Because the policy layer is rail neutral it does not care whether the agent pays by card, through an ACP checkout, under an AP2 mandate or over x402.
The practical test for whether you need one is short. If your Agentforce agents only read records, draft replies and update fields, you do not: the credit meter plus Digital Wallet alerting is proportionate and you should stop here. If any agent can cause money to move outside Salesforce, you are relying on a permission check that was designed to answer a different question.
How Agentforce compares with the other agent control planes
Four vendors, four schemas, one pattern. We have now measured the published models of the biggest agent control planes shipped in 2026, using the same method each time, and they converge on the same boundary. Microsoft Agent 365 is agent-aware down to the conditional access vocabulary and expresses no monetary amount at all. AWS AgentCore shipped a real ceiling, one optional per-session USD amount on a session capped at eight hours, with no cumulative total anywhere in the model. Salesforce models money in 178 objects and agents in 41 and keeps them apart. The payment MCP servers hand a model write access to live payment APIs with no ceiling of any kind.
That consistency is the useful part. Four independent engineering organisations, with different architectures and different commercial incentives, drew the same line: the platform governs identity, access and capability, and declines to govern the amount. It is a defensible line, because a finance policy sits badly inside an identity system and even worse inside a CRM permission set. It is also a line, which means something has to sit on the other side of it. For the wider category, AI agent governance covers the control frameworks in general and AI agent payment platforms compares the vendors who do this specific job.