Per-conversation AI pricing and the budget you can't forecast

Consumption-priced AI agents are hard to budget because the meter sits between you and the work: you are billed per conversation, or per action, or per credit, but you cannot predict how many of those a single request will burn. Salesforce learned this on its own product. Its original $2-per-conversation Agentforce price was scrapped as unpredictable and replaced with a per-action credit wallet. The abstraction got finer; the forecasting problem stayed exactly where it was.

What did Salesforce change, and why?

Agentforce launched in late 2024 priced at $2 per conversation — a flat charge every time a customer or employee opened a dialogue with an agent. The analysts who watched it run in production were blunt about how that held up:

fell apart in production

The trouble is that a conversation is not a unit of cost. One conversation might be a single account lookup; the next might be a thirty-step reasoning loop that calls six tools, re-plans twice and writes back to three systems. Charging both the same $2 is, in the words of the same analysis:

unpredictable and disconnected from real cost

It overcharges the trivial exchanges and undercharges the expensive ones, which is a bad place for buyer and vendor alike to sit. Salesforce's own response is the strongest evidence the diagnosis is real. The replacement, Flex Credits, meters usage in credits rather than conversations: it prices actions at roughly $0.10 each and sells the underlying credits in blocks — 100,000 credits for $500 as of March 2026 — with a given action drawing a variable number of credits depending on what it actually does. The meter moved closer to the work. That is a genuine improvement, and it does not solve the buyer's problem.

Why doesn't a per-action credit fix the forecast?

Because you have traded one abstraction for a finer one, not for a predictable one. A credit is a synthetic unit — the same normalising trick behind every consumption meter — and the number of credits a request consumes depends on how the agent chooses to solve it, which is decided at runtime by a non-deterministic model. Reviewers flag the obvious failure mode: the wallet

can drain faster than anticipated

— if an agent loops. And agents loop. Re-planning, retrying a failed tool call, re-reading context it already had, spawning a sub-agent to check its own work: each of those is billable, and none of them is visible to the person who simply asked a question. The same request run twice can cost different amounts, because the model took a different path the second time. You cannot forecast a bill whose driver is the agent's own reasoning trace.

Where does the overrun actually come from?

Not from the headline rate; it accumulates below the line, in behaviour the pricing page cannot show you. The usual accumulators on an agent platform:

• Reasoning loops: an agent that re-plans or second-guesses itself pays for every extra step, and the harder the task the more steps it takes.
• Tool fan-out: one user request can trigger a dozen tool calls — a search, three record reads, a write-back, a validation — each one an action.
• Retries: transient failures and timeouts re-run actions that produced no output but still drew credits.
• Context re-reads: agents that reload the same records or knowledge on each turn pay again for information they already had.
• Adoption itself: the more useful the agent, the more people use it, and every interaction draws from the same wallet. Success and spend become the same event.

That last one is the trap. A meter that quietly rewards you for low adoption is aligned against the entire reason you bought the platform.

Why is this a governance problem, not a pricing problem?

Consumption pricing is not wrong in principle; plenty of infrastructure bills that way and forecasts fine. It fails here because the cost driver sits below the person who triggers it and behaves non-deterministically once triggered. A rep asks the agent to sort out a delivery query; the credit burn happens invisibly, in orchestration the rep never sees, along a path the model decided on its own. There is no backpressure between the act that spends money and the budget that pays for it — the same structural gap we have written about when a platform quietly bills you for orders your own systems generated, or when B2B commerce logic hits an invisible ceiling you were never shown.

It is worse than a deterministic consumption meter. A data-integration credit at least maps to jobs you scheduled and volumes you can count, so you can baseline it. An agent's credit draw maps to a reasoning trace that changes run to run, so even a careful baseline drifts as the model, the prompts and the tool set evolve on the vendor's cadence rather than yours. Finance is handed a monthly wallet-drain figure it cannot decompose into controllable levers — and, as tends to happen at scale, it can break in ways you only notice after the fact.

What actually keeps the number predictable?

The direction out is not a better credit rate; it is attaching AI cost to something you can budget in advance. The flat-cost tooling our own engineers run lands around €1,500 per engineer per month — a fixed line, known before the month starts, that does not move when the software gets busier or an agent decides to think harder. When AI cost attaches to the small number of people building the platform rather than to every end-user interaction across a route-to-market estate, the number becomes a headcount question instead of a forecast, which is precisely the property a per-action wallet removes. That is the trade behind how we run the platform suite on tooling we cost ourselves.

The pricing model will keep churning — Salesforce reworked it inside a year, and the next revision will land on a different unit again. The question for anyone signing an agent platform in 2026 is not which unit is cheapest this quarter; it is whether your AI budget should be indexed to the agent's own runtime behaviour at all. The estates that stay solvent will be the ones that decided, before the meter started running, how much of their route-to-market intelligence they were willing to rent by the action.