There is a number buried in Salesforce's latest agent launch that most coverage glossed over. Not the $550 per-seat ceiling. Not the $100 million in quoted pipeline. The number is 275 — the conversation count at which a client on the $2/conversation track starts paying more than a client on the $550/user/month tier. Below it, metered billing wins. Above it, the seat wins. Salesforce did not print that crossover point in the deck. It emerged from the arithmetic, which is exactly where these things always live.
I have spent a career staring at metered resources — gas, blob space, proof verification — and I have watched the SaaS industry insist for a decade that its pricing was somehow exempt from the physics of consumption. It was not. It was just hiding the meter behind a seat. This launch is the moment the meter came out into the open. And the interesting question is not whether the meter works. It is who owns it, and whether it settles on a shared protocol or inside a private ledger with a logo on it.
The context you need before the numbers mean anything
The product cluster circulates under several names — Agentforce, an umbrella brand, integrations with Anthropic's Claude, a Slack surface, and a 'headless toolkit' that exposes CRM objects through APIs and the Model Context Protocol. A note on sourcing: the branding is inconsistent across the coverage I reviewed, and some of the naming does not map cleanly to the products Salesforce actually shipped. Treat the scaffolding with caution. Treat the underlying pricing and protocol facts with attention — they cross-check against public information almost point for point.
Here is what is structurally real. Salesforce does not train a foundation model. Claude comes from Anthropic. The company's contribution is orchestration — 37 pre-built sales skills for meeting prep, deal health review, and pipeline updates — plus a governance layer that claims to carry existing permissions across systems without the customer learning a new model. Agent activation hit 100,000 users in 35 days by the vendor's own count.
And the pricing. Four tracks running in parallel: a $5/user/month starter tier, a $550/user/month full tier, a $2/conversation consumption track, and a Flex Credits bundle at $500 per 100,000 credits. A 30-seat team, by one authored estimate, lands between $200,000 and $450,000 in year-one total cost of ownership, implementation included.
Four tracks is not indecision. Four tracks is price discrimination with a hedge built in.
Core: MCP is an ABI, and the credits are a gas abstraction
The Model Context Protocol is the technical spine here, and it deserves a precise read. MCP, introduced by Anthropic in late 2024, is a standardized way to inject tools and context into a model's runtime. Strip the marketing and it is a schema for function calls and data retrieval — an interface contract between a model front-end and an external system's capabilities. If you have written Solidity, you already understand the shape of it: it is an ABI. A defined way for one execution environment to call into another and get a predictable return.
That framing matters because it tells you where the value sits. Salesforce is not selling a model. It is selling the context that the model reads — the CRM records, the permission graph, the workflow state — exposed through a stable interface so that any compliant front-end (Claude, Slack, Lightning) can act on it.
Now look at the credits. Flex Credits are not just a billing convenience. They are a monetization abstraction layer. By selling internal credits rather than exposing raw token counts or conversation units, Salesforce retains the freedom to reprice, rebundle, or retire the meter later without renegotiating with customers. It is the same move a rollup makes when it quotes fees in its own token rather than in L1 gas. Hiding the meter behind a synthetic unit is how a vendor keeps optionality while the customer loses visibility.
I ran into this dynamic firsthand in 2021, when I spent two weeks simulating EIP-1559 on a local Geth testnet during a congestion spike. The finding that stuck with me: a mechanism that smooths a resource's price under load also hides the variance from the people paying for it. The base fee adjusts exponentially, the network stays stable, and the end user sees a single number that absorbs all the chaos underneath. Flex Credits are the SaaS version of that single number.
Here is where the analogy sharpens into a warning. On-chain, no execution can run unbounded. Every call carries a gas limit, and when it is exhausted, the transaction reverts cleanly with state intact. That constraint is not a limitation of the EVM. It is a safety property. Gas isn't priced per call out of greed; it is priced per call because unbounded execution is a denial-of-service vector.
An LLM agent orchestrating a multi-step enterprise workflow has no gas limit. There is no canonical revert. A deal-health review that loops through records, calls a sub-agent, drafts a customer email, then re-triggers itself on a re-read has no natural stopping condition enforced by the runtime. The vendor's answer to this is 'the agent completes the task.' The engineer's answer is: at what cost, and who eats the bill when it does not stop?
I have audited enough contracts to know that the failure mode is rarely the happy path. In late 2017 I traced a Diamond Cut inheritance pattern in a DeFi contract where reentrancy only fired under specific gas conditions — invisible in normal testing, fatal in production. The bug was not in the logic the authors wrote. It was in the state they assumed was stable between calls. A multi-step agent inherits the same class of risk in a far larger search space, because the 'state' it reads between steps includes a hallucinating model.
I understand why this holds up in demos: the prompt is narrow, the data is clean, and a human is watching. Production removes all three.
The 275-conversation crossover deserves one more look, because it is where the commercial and technical risks collide. Below 275, metered billing tracks value. Above it, the seat becomes cheaper — which means the most automation-heavy customers, exactly the ones an agent vendor wants to keep, are the ones economically pushed toward the flat tier. That is a rational design if the flat tier is loss-leading. It is a liability if heavy usage is genuinely more expensive to serve, because then the vendor is paying to keep its best customers. Without per-conversation inference cost disclosure, that question stays open.
Contrarian: the blind spot is not hallucination — it is the billing oracle
Everyone is worried about the agent saying something wrong. That is the wrong thing to worry about.
The real risk in this architecture is the meter itself. When a vendor sells internal credits and does not expose the underlying resource consumption, the billing layer becomes an oracle you cannot verify. Oracle dependencies are exactly where blockchain systems have been repeatedly broken — not because the oracle malfunctioned loudly, but because the trust assumption was hidden in the design. A consumption meter with no ceiling and no audit path is that same trust assumption, wearing enterprise branding.
The advertised Zero Data Retention promise — data neither stored nor used to train external models — is the strongest compliance claim in the deck. It is also unverifiable from outside the system. In-flight caching, logging, and retry buffers are all places where 'retention' gets fuzzy in practice. I have no reason to believe Salesforce is lying. I have every reason to treat an unaudited claim about data handling the same way I treat an unaudited claim about a contract's state invariants — as an assumption to be tested, not a fact to be trusted.
Governance auto-inheritance has the same shape. The claim is that existing permission models carry across systems seamlessly. Cross-object permission enforcement is genuinely hard, and it is the exact surface where an agent acting on a user's behalf can read something that user should not see. The vendor asserts it works. There is no third-party audit referenced. That is a strong claim resting on weak evidence.
And then the strategic twist. By embracing MCP — an open protocol — Salesforce arguably invites its own displacement. If Claude or Slack becomes the interface users actually think in, Salesforce becomes the context supplier behind someone else's brand. The naming — attaching partner names to its own products — reads like a company insisting it is still the platform, not the plumbing. The protocol that makes you interoperable also makes you replaceable. Blockchain teams learned this when they standardized on bridged liquidity: the standard is shared, but the value accrues to whoever owns the settlement.
Takeaway: where does the meter ultimately settle?
I am quietly building toward this in 2026 — prototyping an interface that lets an agent submit a proof of computation on-chain without revealing its model weights, because the unresolved problem is not capability but verifiability. Salesforce is solving the same problem inside a closed system: how do you let an autonomous actor touch your data and trust that it did only what it claimed? Their answer is a contract and a promise. My answer, and the answer the on-chain agent economy will eventually force, is a proof.
The next twelve to twenty-four months will decide which one propagates. If consuming agents through private credits and uneaudited retention claims becomes the enterprise norm, the walled garden wins a generation. If open metering and verifiable agent identity mature first — account abstraction for agents, paymasters with hard budgets, proof-of-computation interfaces — the meter migrates to a shared rail. The $2 conversation is a preview of the unit that the entire agent economy will be priced in. The only open question is who holds the ledger that counts it.
Gas isn't the only metered resource anymore. And the smart place to stand is on whichever side of the meter you can actually verify.
