Salesforce has spent much of this year making the case that AI agents should interact with its platform in a structured, secure, and governable way. AIforce, MCP, and the Headless Toolkit all point in broadly the same direction. Rather than letting tools like Claude and ChatGPT work around Salesforce, they’ll have controlled access to the data and workflows sitting inside it.
But, as we covered recently, Salesforce is also preparing to charge Flex Credits when third-party AI agents successfully call into the platform through MCP or direct APIs. So, what happens when the architecture Salesforce considers safest and easiest to govern also becomes the route customers have a strong financial incentive to minimize?
Structured machine access is supposed to make AI integrations cleaner and more predictable. But charging specifically for that access risks nudging customers in the opposite direction, and that could have consequences beyond the Flex Credit bill.
Why the Pushback Is About More Than Paying for MCP
Since the initial announcement, there’s been a lot of pushback from customers who believe some of the guidance around this change has not been clearly detailed. My colleague Peter Chittum discussed this, which sparked some interesting conversations around MCP charges and the problems that could come with it.
The pushback we’re seeing is not simply that Salesforce has decided to charge for MCP. This is a larger question also about what customers are actually paying for and whether the new payment model lines up with the way Salesforce has said they want agents to work.
Salesforce has been clear that registered agents will unlock more than just basic connectivity. Agentic Identity brings separation of credentials and permissions, while the Headless Toolkit adds traceability and governance.
Salesforce is also building discovery features that are intended to help agents find the right tools without having to reason across a huge catalog.
Speaking to Salesforce Technology Engagement Manager and Architect Beech Horn about this topic, he told SF Ben: “Why would I pay flex credits? I could just call the normal APIs and get this result without additional costs?” His main concern was that some of these calls already exist today without an extra usage charge. The fact that an AI agent is making the call does not automatically make the underlying operation more valuable.
That said, Beech also sees where Salesforce is adding value. He pointed to its growing collection of MCP tools and the discovery layer that is designed to surface the most relevant options for a task. At that scale, there is a real management problem that Salesforce can solve for customers.
This is why the argument goes beyond whether MCP should be free. Salesforce is effectively charging for a managed route into the platform. The issue is whether customers will see enough value in that route to accept the extra cost.
Assessing the Downsides
In basic terms, the approach that Salesforce is pushing with the leveraging of Flex Credits isn’t great – here are a few reasons why.
Double Billing
One of the most immediate problems is that customers could effectively be paying twice for the same agentic workflow.
Using Claude or ChatGPT already comes with its own consumption costs. Connecting that agent to Salesforce then introduces another charge each time it successfully interacts with the platform.
Beech’s view is that this becomes much harder to justify when the agent is carrying out the deterministic work that Salesforce customers can already perform through existing APIs. He argued that Salesforce needs a way for those kinds of calls to happen without an additional charge while still fitting within Agentic Identity.
It is a little like paying for the car, then the insurance, then the registration, and the tolls – only to be charged again every time you enter or leave the highway. Customers may accept extra costs where Salesforce is providing genuinely new agentic functionality. Basic access to data and existing platform functions is a much tougher sell.
Agents Call Constantly
The next big problem to consider is volume. Salesforce is encouraging customers to put agents across more of their workflows while introducing a model that charges those agents every time they successfully interact with the platform.
That matters because agents tend to make far more calls than human users.
A person may already know which object or record they need, while an agent may need to search for the right record, inspect supporting data, and potentially call several tools before it can complete the task.
A person may already know which object or record they need, while an agent may first need to discover the schema, then search for the right record, then read supporting data before it can complete the task. Each of those steps can become another interaction.
MCP can reduce some of the discovery overhead compared with direct API access, because the server can describe the tools and resources available to the agent. But more capable agents are also likely to spawn more sub-tasks and checks, meaning the overall number of interactions can still grow quickly.
This creates a bit of a strange problem. The more autonomous and capable Salesforce wants these agents to become, the more platform activity they’re likely to incur. Charging at the interaction level could therefore make successful adoption more expensive precisely as customers start getting more value from it.
Perverse Incentives
This point arguably inspired the driving point of this article – could the new pricing model encourage customers to make bad decisions?
Agents often need to verify information before taking action. If every check against Salesforce carries a cost, then teams (understandably) may start looking for ways to avoid those calls.
That could mean creating secondary (or slave) copies of Salesforce data for agents to reference or pushing more logic into external tools. In both cases, the agent works around Salesforce rather than through it, which creates some obvious risks.
Beech said Salesforce appears comfortable with customers taking that route if they want to manage it themselves. He says: “Speaking directly to the product managers at Dreamforce, they don’t see this as a risk. Their view is essentially: if you don’t want to use this approach, that’s fine,” Beech explained.
“There are other paths. But Salesforce wants to take a trust and security-first approach, and that is going to come at a cost. They’re not stopping customers from self-managing or doing things outside Salesforce. That’s just not how Salesforce wants to play the game.”
It’s certainly interesting, and creates an odd incentive for customers. If the more governed Salesforce route costs more, then some customers may deliberately architect around it – or potentially already do. It wouldn’t be the first time Salesforce customers have found architectural solutions to reduce their CRM spend.
But Beech also questioned how well that scales in practice. He noted that shared agent skills might end up sitting in places like GitHub and asked whether ordinary business users are really going to manage them there.
The risk is that pricing pushes agents away from Salesforce until the last possible step – that may save credits, but it could also create larger issues with duplication and governance in the long term.
The Better Solution
The reality is that while we’re seeing benefit from the agentic world, everyone involved is struggling to keep up with the costs. AI vendors like Anthropic and OpenAI are hemorrhaging cash as we’ve never seen before.
Software vendors like Salesforce are realizing the costs of having agentic workforces pinging their endpoints constantly (hence the new pricing model for agentic usage). And, of course, customers are spending more than they ever have on their fancy new agentic workforces as a result.
The question many have asked in recent history is whether or not AI is actually turning a profit for those involved, and it’s a good question. A better question, perhaps, would be to ask whether the current pricing models are the best way to go about it.
The new pricing model for agentic usage will help Salesforce to cover some of its infrastructure costs. That said, it’s not a pleasant experience for customers who are already struggling to figure out how to get a return on their AI investment.
It also addresses fears that some professionals have had about the agentic world: is my job safe if AI can be employed to do many parts for a fraction of the cost? Some of those concerns are valid, but it goes to show that just because a new technology is available and cheaper today doesn’t necessarily mean it’s going to be cheaper tomorrow.
This isn’t the first time Salesforce has changed how it prices its AI products. One of the most notable recent changes was the introduction of Pay-Per-Resolution (PPR) pricing. Simply put, this means that customers are not charged for the number of tokens spent, but rather the number of outcomes that the AI tools achieve. While this is a much easier pill to swallow, it’s still not optimal for every party in the chain.
Final Thoughts: What Salesforce Teams Can Do Now
Salesforce has changed its policies, and you must follow the rules of the platform. This means registering your agents according to the new Agent Identity model, and paying for what those agents use. It’s not ideal, and we expect changes to this model in the near future, but it’s required for now. We will never condone breaking your EULA with Salesforce.
Next, the best proactive thing you can do is to model worst-case scenarios in terms of usage volumes. Given that you’ll be paying based on how much agentic activity occurs through MCP or API, understanding exactly what that looks like is critical.
From here, you may be able to negotiate with your Salesforce Account Executive to get a discount. It’s definitely not a guarantee, but knowing your numbers is the first step in any negotiation.
Finally, model your worst-case scenarios, and adjust your agents if possible to optimize for API/MCP usage. To be clear, this doesn’t mean that you should avoid using MCP or API if you really need to, nor are we suggesting that you clone data or functionality outside of Salesforce just to save on usage costs. Continue to follow best practices, but be aware of the associated costs.
In summary, do not go against Salesforce’s policies or rules. Do not build in a way that puts your architecture at risk. Salesforce charges what they do because they have a competitive offering. Security is a big part of that offering, and skirting around the system to save a buck isn’t worth it.
