Salesforce Flex Credits for MCP Calls: Build, Don't Loop

Salesforce will start charging Flex Credits for MCP and API calls made by AI agents, and that one change quietly settles an argument the industry has been having all year. When every agent call into your org has a meter on it, the AI that does the work over and over becomes a running cost. The AI that builds the automation once, and then gets out of the way, does not. My position: this is the moment to stop treating AI as a CRM operator and start treating it as a CRM developer.

Here is what was announced, what is still unknown, and what I would do about it this quarter.

What Salesforce actually announced

Salesforce Ben reported on September 24 that successful MCP and direct API calls made by registered AI agents will consume Flex Credits, under a new consumption unit called a Headless Platform Interaction. The facts that matter:

The meter is per successful call. The cost per interaction is uniform; what varies is how many calls your agents make.
The multiplier is not published yet. Salesforce has not said how many Flex Credits one interaction costs, so nobody can calculate a bill today.
Thirty days’ notice. Salesforce says it will give 30 days’ notice before billing begins.
Production only. Metering applies to active production orgs, which excludes sandboxes, scratch orgs, and Developer Edition orgs.
Existing integrations are untouched. “Existing API-based integrations will continue to use their current pricing and security arrangements.”

The other half of the change is identity. Registered agents get their own credentials and permissions rather than borrowing a human user’s login, which Salesforce Ben frames as giving admins “more control over what it can access and do.”

Why this was always coming

None of this is surprising if you watched Dreamforce. Two weeks ago Salesforce announced AIforce, built on Headless 360 — an architecture that exposes the platform through APIs and the Model Context Protocol so agents can work with Salesforce from wherever people already use AI. I wrote about what AIforce means for the Salesforce UI at the time.

If the product strategy is “the UI is optional, agents come in through the side door,” then the side door is where the revenue has to move. Per-seat licensing assumes a human in a chair. An agent is not in a chair. Metering the call is the obvious replacement, and Salesforce is simply the first CRM vendor big enough to say it out loud.

I don’t think that is a cynical move. It is a fair one. Agents that hammer an org with thousands of reads a day consume real platform resources. What it does is make the economics of how you use AI visible for the first time.

The difference between an operator and a developer

There are two ways to point an AI at Salesforce.

The operator pattern. The agent sits in the loop. Every time a lead comes in, the agent reads it over MCP, decides where it goes, and writes the assignment back. Every renewal, every duplicate check, every status update is another round trip. This is the pattern most “AI + CRM” demos show, because it looks magical on stage.

The developer pattern. The AI builds the thing once — a trigger, a Flow, a scheduled job, a custom object — tests it, and deploys it. From then on the org does the work itself, the way it always has. The AI comes back when the rules change.

Under a per-call meter, those two patterns have completely different cost curves. The operator’s bill scales with your business volume: more leads, more calls, more credits. The developer’s calls cluster around building and changing things, then drop to zero while the automation runs natively. Nothing in the announcement suggests that code running inside your org on its own triggers counts as an agent calling in — the meter, as described, is on agents reaching in from outside.

That is the whole argument of Salesforce automation without an Apex developer: the output of the AI should be durable automation, not a permanent AI employee clicking buttons.

Where the operator pattern still earns its keep

I’m not saying agents in the loop are wrong. Some work is genuinely judgment-shaped: summarizing a messy account history before a call, drafting a reply, triaging a case whose category is ambiguous. That work doesn’t compile into a rule, and paying per call for it can be worth every credit.

The test I would apply to every agent workflow you are running or planning:

Does the decision follow a rule you could write down? If yes, it should be code, not a call.
Does it run on every record, or on the exceptions? Agents on the exceptions are cheap. Agents on every record are a meter running at the speed of your pipeline.
Would you be comfortable explaining the monthly count to finance? If you can’t estimate it, you can’t budget it — which is exactly the planning Salesforce Ben says organizations will now need to do.

Most teams who run that test find the majority of their “agent” ideas are really automation ideas that got demoed as agents. Flow vs. Apex is a better question for those than which agent platform to buy.

The sandbox exemption is the quiet headline

The most useful line in the announcement for builders is the exemption: sandboxes, scratch orgs, and Developer Edition orgs are not metered.

Read that alongside the developer pattern and the incentive is clear. Salesforce is not taxing building with AI. It is metering running with AI in production. Development work — the AI writing Apex, deploying to a sandbox, running tests, iterating — happens where the meter isn’t.

That is also where it should have been happening all along. An AI that deploys straight to production is a risk regardless of what it costs. An AI that builds in a sandbox, passes tests, and promotes a reviewed change is just good release discipline that happens to be typed by a model. We’ve covered the mechanics of that in the safe way to connect Claude to Salesforce and how write access over MCP should work, so I won’t repeat them here.

What I would do this quarter

The multiplier isn’t public, and there are at least 30 days of runway after it is. That is time to get the architecture right rather than to panic.

Inventory your agent traffic. List every AI tool that touches production — Agentforce, a Claude or ChatGPT connection, anything a vendor wired in. You cannot estimate credits for agents you don’t know about. Our Sunday roundup on AI agent oversight covered how many organizations can’t currently answer that question.

Separate identities now. The registration model gives each agent its own credentials. If your agents still share a human’s login, fix that first; it is good hygiene regardless, and it is the prerequisite for seeing what each one costs. See AI agent identity and API keys.

Convert rule-shaped agents into automation. Anything that fires on every record and follows a rule is a candidate to become a trigger or a Flow — built by AI, deployed once, metered never.

Keep the agents for judgment. Put the per-call budget where a model is actually doing something a rule can’t.

Where Sentinel fits

This is the pattern Sentinel was built around. Your AI connects to your org through Sentinel and develops against it — writing Apex, building objects, querying data — with Salesforce deploys going sandbox-first with tests required. Every change is logged and a snapshot is taken before deploys, so what the AI built is visible and recoverable. The output is automation that lives in your org, not an agent you rent by the call. For examples of what that looks like in practice, see what Claude actually builds in Salesforce.

Pricing is flat per Sentinel and is covered on a short demo call.

The takeaway

Metered agent calls are not a reason to back away from AI in Salesforce. They are a reason to be deliberate about what the AI is for. Use agents for judgment, and use AI to build everything else — once, in a sandbox, with a record of what changed.

Book a Demo Call — bring your list of agent workflows, and we’ll sort which ones should be code.