Agentforce Is Not Ready for Scale — And That’s the Real Problem
Everyone talks about Salesforce Agentforce as if scale were a solved problem — as if a pilot that deflects cases in a demo will behave the same way when it is handling ten thousand conversations a day. This episode takes the opposite position. Running Agentforce at scale is not the easy part that comes after the hard part; it is the hard part. The demo hides the physics. This is not an anti-Agentforce episode — the platform is architecturally serious — it is an anti-illusion episode about what actually breaks when you move from a scripted proof of concept to production load.
In this episode:
- Why scale is an engineering problem with its own failure modes, not a natural consequence of a successful pilot.
- How the Atlas Reasoning Engine’s multi-call planning loop turns latency into a compounding cost at volume.
- The cost physics of consumption pricing — why actions-per-conversation, not conversation count, is the number that blows up your budget.
- The hidden Data Cloud dependency underneath every serious Agentforce deployment.
- Why non-determinism makes agent behavior drift under load in ways traditional QA never catches.
- What enterprises should actually measure before they commit to scaling.
Running Agentforce at scale is the hard part
The episode’s central move is to reject a framing that dominates every keynote: that scale is what happens automatically once the agent works. In classic software, scale is largely a resource problem — add capacity, shard the database, cache the hot path. Agentic systems break that assumption because the unit of work is not a deterministic function call. It is a reasoning step whose latency, cost, and output all vary with context.
That is why Agentforce at scale behaves differently from a pilot in kind, not just in degree. A pilot runs on curated inputs, a narrow action set, and low concurrency. Production runs on the long tail of real customer phrasing, a wide action surface, and bursty load. The behaviors that emerge — timeout cascades, runaway action counts, plans that loop — are precisely the ones a demo is structured to never trigger. The gap between the two is where enterprises lose the budget they thought they had secured.
For the independent, vendor-by-vendor picture of where each platform actually stands, see our AI CRM & CX vendor analysis and the best AI CRM comparison for 2026.
The Atlas Reasoning Engine and the latency tax
At the center of the scaling problem is the Atlas Reasoning Engine — the component that decides which actions an Agentforce agent takes to resolve a request, and in what order. Every one of those planning decisions is an LLM call, and the call count per conversation is the variable that governs both responsiveness and spend.
This is not a hypothetical. Salesforce itself hit a latency wall serious enough to trigger an internal “code red” when some agent responses took roughly twenty seconds — an eternity in a live customer interaction. The published fixes are revealing: they consolidated the number of LLM calls in a knowledge lookup from four to two before streaming output, and shipped dozens of enhancements that cut latency by roughly 70%. The lesson underneath the announcement is the one the episode emphasizes — at scale, the enemy is the sequential reasoning loop, and shaving calls is how you fight it.
The implication for buyers is uncomfortable. Latency is not a fixed property of the platform; it is a function of how complex your agent’s action graph is. A richly configured agent that touches many systems per turn is, by construction, slower and more expensive than a demo agent that touches two. You do not inherit Salesforce’s benchmark numbers — you inherit your own action topology.
The cost physics of consumption pricing
The second failure mode is financial, and it is the one that reaches the CFO. Under the Flex Credits consumption model you pay per action, not per conversation — and this is exactly where estimates fall apart. Teams price the model on conversation volume and forget that a single conversation is a bundle of actions.
The arithmetic is brutal in its simplicity. A support interaction that looks up an account, checks order history, retrieves a knowledge article, and opens a case can consume five to eight actions. One reported deployment budgeted $4,000 a month and was billed $14,200 in month one — because conversations averaged 6.3 actions, not the two the team had assumed. That is not a rounding error; it is a 3.5x overrun driven entirely by a mis-estimated multiplier. At a few hundred conversations a day, five agents can run on the order of $900 daily, which is why mid-tier organizations stall.
This is the cost physics the episode insists on: spend scales with actions, actions scale super-linearly with agent capability, and capability is exactly what you add when you move from pilot to production. The more useful you make the agent, the faster the meter runs — and the budget you approved on pilot economics is the wrong budget.
The Data Cloud dependency nobody prices in
Underneath the visible per-action cost sits a structural one: a serious Agentforce deployment is a Salesforce Data Cloud deployment. The reasoning engine is only as good as the grounded context it can retrieve, and that grounding lives in Data Cloud. The episode’s point is that this dependency is systematically underpriced in business cases.
The order of magnitude matters. Data Cloud’s entry SKU frequently starts near $60,000/year and grows into six figures as data volume and unification scope expand. For a mid-market deployment, a realistic Year-1 all-in figure lands somewhere between $50,000 and $250,000 once you add the platform, the credits, and the data layer — and large enterprises go well past that. A pilot that ran on a slice of data inside an existing org never surfaced this line item, which is exactly why it ambushes the production business case.
Non-determinism breaks traditional QA
The final scaling problem is qualitative. Traditional CRM automation is deterministic: the same input produces the same output, so a test suite that passes today passes tomorrow. Agentic reasoning is non-deterministic — the same customer request can yield a different plan depending on phrasing, context, and model state. That property does not scale gracefully.
At low volume, non-determinism is a curiosity you can eyeball. At production volume it becomes a governance problem, because the space of possible agent behaviors is too large to enumerate and the failures are behavioral rather than exceptional — the agent does not crash, it decides badly. Salesforce’s own move toward native support for multiple LLMs, including Anthropic Claude, plus heavier investment in observability and guardrails, is a response to exactly this: you cannot unit-test your way to confidence in a reasoning system, so you instrument, monitor, and constrain it instead. Enterprises that carry a pass/fail QA mindset into an agentic rollout discover that green tests and correct behavior are no longer the same thing.
For the closely related analysis of why impressive pilots collapse in production — and how pilot metrics actively hide the gap — see the Agentforce pilots that are lying to you.
Get independent AI & CRM intelligence with no vendor affiliations and no sponsored takes — subscribe to the CRMPosition newsletter.
Key concepts and vendors mentioned
- Agentforce at scale — the problem of running Salesforce’s agentic platform at production volume, where latency, cost, and non-deterministic behavior become the dominant constraints rather than agent capability itself.
- Atlas Reasoning Engine — the planning core of Agentforce that selects and sequences agent actions; each planning step is an LLM call, making call count the primary driver of latency and spend.
- Flex Credits / consumption pricing — Agentforce’s per-action billing model, where cost scales with actions-per-conversation, a multiplier teams routinely underestimate.
- Salesforce Data Cloud — the data-unification and grounding layer a serious Agentforce deployment depends on; a frequently underpriced six-figure line item in production business cases.
- Non-determinism — the property that identical inputs can produce different agent plans, which breaks pass/fail QA and forces a shift toward observability and guardrails.
- Anthropic Claude — one of the natively supported LLMs Agentforce can host, referenced in the context of Salesforce’s multi-model, observability-first response to scaling reasoning systems.
- Salesforce Agentforce — Salesforce’s platform for building autonomous, decision-making AI agents, and the subject of the episode’s engineering-first scaling critique.
Frequently Asked Questions
Why does Agentforce struggle to scale in production?
The episode's argument is that scale is treated as a given when it is actually the hardest part. Three forces work against it: latency compounds when a single agent turn requires multiple sequential LLM calls, cost becomes non-linear because each conversation consumes far more actions than teams estimate, and the reasoning layer is non-deterministic, so behavior that is fine in a demo drifts under real-world load. None of these show up in a scripted proof of concept.
What is the Atlas Reasoning Engine and why does it matter for scale?
The Atlas Reasoning Engine is the planning core of Salesforce Agentforce — it decides which actions an agent takes, in what order, to resolve a request. It matters for scale because every planning decision is an LLM call, and the number of calls per conversation is the variable that drives both latency and cost. Salesforce has publicly worked to consolidate those calls (reducing them from four to two before streaming output) precisely because the call count is the scaling bottleneck.
How does Agentforce pricing become unpredictable at scale?
Under the consumption model, you pay per action, not per conversation, and teams routinely underestimate how many actions a single conversation involves. A support interaction that looks up an account, checks order history, retrieves a knowledge article, and creates a case can consume five to eight actions. One reported deployment projected $4,000 a month and received a $14,200 bill in month one because conversations averaged 6.3 actions, not the 2 assumed. That gap is the scaling risk finance teams miss.
How much does Agentforce cost to run at scale?
There is no flat seat price at scale — Agentforce bills through Flex Credits on a per-action basis, and a single conversation bundles several actions, so cost scales with actions-per-conversation rather than conversation count. The example in this episode is instructive: a deployment that budgeted $4,000 a month was billed $14,200 in month one because conversations averaged 6.3 actions, not the 2 assumed, and at a few hundred conversations a day five agents can run on the order of $900 daily. On top of per-action spend sits the Salesforce Data Cloud dependency, whose entry SKU frequently starts near $60,000/year. A realistic Year-1 all-in figure for a mid-market deployment lands between $50,000 and $250,000 once platform, credits, and the data layer are combined, and large enterprises go well past that. Budget on measured actions-per-conversation from real traffic, not demo volume.
Is this an anti-Agentforce episode?
No — the episode explicitly frames itself as anti-illusion, not anti-Agentforce. The platform is architecturally serious and Salesforce has shipped real latency and reliability improvements. The critique is aimed at the assumption that a successful pilot implies a successful production rollout. Scale is an engineering problem with its own failure modes, and treating it as automatic is where enterprises lose money and time.
What should enterprises do before scaling Agentforce?
Model the cost physics first: measure real actions-per-conversation on a representative traffic sample, not a demo, and multiply by projected volume. Budget for the Data Cloud dependency, which frequently starts near $60,000/year and grows. Instrument latency and action counts as first-class metrics, and define which agent actions require human approval before they can fire autonomously. Scale is a capacity-planning exercise, not a feature toggle.