Salesforce Is Trying to Price Something SaaS Has Never Had to Price Before

Salesforce is rebuilding its platform for AI agents. Its evolving Headless 360 rate card offers a rare glimpse at what could replace seat-based SaaS pricing.

Open Salesforce's current Flex Credits rate card and most of it is unremarkable. Agentforce actions, prompts, voice, speech transcription, data processing — every row has a number next to it. That number is the multiplier: how many credits one unit of that work consumes.

Then there's a section called Customer 360 Platform. One row: Headless Platform Interaction. Where the multiplier should be, it says TBA.

I've spent more time than I'd like to admit looking at that blank.

Because I think Salesforce may be trying to solve one of the more important economic problems facing enterprise software: if AI agents become significant users of software, what exactly should we charge them for?

A year ago, I wrote about whether AI agents might create an extinction-level event for SaaS (I was skeptical). A few weeks ago, after digging through CoStar's updated licensing agreement, I argued that agents were more likely to create a different problem. They may not kill SaaS. They may kill the seat.

Now Salesforce is giving us a glimpse of what might come next.

First, what exactly is Headless 360?

Salesforce announced Headless 360 on April 15, built around a question co-founder Parker Harris had asked publicly a few weeks earlier:

"Why should you ever log into Salesforce again?"

Salesforce said he wasn't asking it as a provocation. He was offering it as direction. (salesforce.com)

That's easier to understand if you stop thinking of Salesforce as a website.

The familiar Salesforce application is really an interface sitting on top of a much larger corpus: customer records, permissions, workflows, validation rules, approval processes, business logic, metadata and years of institutional context that companies have encoded into the platform.

Historically, a human accessed those capabilities by logging into Salesforce and clicking through screens. Headless 360 changes the access pattern. An authorized AI agent can discover Salesforce capabilities, retrieve records, invoke workflows and take permitted actions directly rather than navigating the browser interface the way a person would.

Salesforce still authenticates the user. It still controls permissions, holds the system of record and executes the workflows and business logic.

What changes is the surface.

Or, as Salesforce puts it, the surface changes while the platform doesn't.

Salesforce isn't eliminating Salesforce. It's separating the Salesforce corpus from the Salesforce interface.

Applications → Capabilities

In August, Salesforce made the architectural claim explicit. The platform is no longer positioned as a set of enterprise applications. It's positioned as a set of reusable capabilities that any authorized agent can discover and invoke, inheriting the identity, permissions, metadata, workflows, governance and business logic the customer has already established. (salesforce.com)

The company was specific about who those agents belong to. Its announcement names agents running in Agentforce alongside Claude, ChatGPT and Cursor.

It also drew a line I found clarifying: most MCP servers expose APIs, but "The Headless 360 MCP Server exposes trusted business capabilities." (salesforce.com)

And it shipped more than a hundred reusable Skills that package business logic into governed capabilities — which is a more interesting detail than it first appears, and one I'll come back to.

The distinction matters:

Applications → Capabilities.

For most of the SaaS era, we've treated the application as the product. In the agent era, the application may increasingly become one way of accessing the product.

Why I'm more interested in the rate card than the announcement

The architecture is important, and plenty of people have written about it. I'm more interested in the accounting.

A company's press release tells you what it wants you to believe. Its rate card tells you what it intends to charge for. Those are different documents, written for different audiences, and only one of them eventually has to survive procurement.

So the question I brought to Headless 360 was narrower: If agents are going to consume enterprise software, what unit does Salesforce propose to count?

That's where things get interesting.

Salesforce appears to be inventing the meter in public

The timeline is tighter than I expected.

April 21. The Flex Credits rate card has no Customer 360 Platform section at all. The category doesn't exist.

August 18. Salesforce adds it, with two new usage types. Salesforce Record Operation, covering the creation, reading, updating or deletion of Salesforce records. And Salesforce Process Invocation, covering the triggering of Flows or Apex. Both listed as TBA.

August 19. One day later, the capabilities announcement goes out. The architectural vision and the first attempt at pricing it arrive in the same news cycle.

August 31. Twelve days after that, the card changes again. The two rows disappear, replaced by a single category: Headless Platform Interaction. Still TBA.

Meanwhile, Salesforce's help documentation continued describing the original two usage types even after the price list consolidated them into one.

There's a perfectly boring explanation for this. A placeholder may simply be easier to manage as one line item. Salesforce hasn't announced the price, so perhaps it also doesn't want to commit to the taxonomy yet. That's entirely plausible.

Nobody appears to be hiding anything. The documents are public, and Salesforce says these new usage types aren't currently metered and that customers will receive notice before numerical multipliers are introduced.

But the first two units Salesforce chose are worth sitting with.

CRUD + business logic

In 2025, I wrote a piece called "Surviving the SaaS Extinction-Level Event." The catalyst was Satya Nadella's observation that many business applications are essentially CRUD databases with a bunch of business logic sitting on top.

The implication was unsettling. If an AI agent can interact directly with the database and reproduce much of the logic, how much of the traditional SaaS application is really necessary?

I took that thesis seriously because many of our customers are PropTech and FinTech SaaS companies. If the thesis was right, it wasn't an abstract debate for us. It was exposure.

My conclusion was that CRUD itself wasn't the death knell. The more important variable was who controls the logic. If a product's intelligence is hardcoded by its developers, AI can increasingly replicate it. Software becomes harder to replace when customers can define and evolve their own logic through workflows, tools, automations and domain-specific processes.

I described that as inviting users into the logic layer. (realestateapi.com)

Now look at the two things Salesforce originally chose to meter for Headless 360: Record Operations — CRUD. Process Invocations — Flows and Apex, or business logic.

The two halves of Nadella's sentence, itemized as potential billable units.

And look again at those hundred-plus Skills, which Salesforce describes as packaging business logic into governed, reusable capabilities. That's the logic layer being productized as a unit — not hidden inside an application, but exposed as something an agent can find and call.

I don't think Salesforce read my post or was trying to answer Nadella. Structural convergence is more interesting than influence anyway. Different people looking at the same system independently arrived at the same decomposition — one while asking what AI might hollow out, the other while figuring out how AI consumption might eventually be charged.

A visual I owe an update

Not long after writing that original piece, I gave a presentation about how software needed to evolve in the AI era.

One slide showed a dropdown menu sitting inside a museum case. The placard read:

Dropdown Menu — Circa 1984–2023

The joke was deliberately overstated. Dropdowns obviously weren't disappearing. The copy underneath said:

"Static filters and pick lists help us sort — but not reason."

My point was that conventional software largely asks users to operate inside logic its developers have already defined. Choose this field. Select that filter. Run this report. Look at this dashboard.

The next generation of software, I argued, needed to let users collaborate with the data and enter the logic layer themselves. I also said something in that presentation that looks considerably more important now:

"We designed for a future where LLMs consume the data."

Looking back, the honest update isn't that I was more right than I realized. It's that I may have put the wrong thing behind the glass.

The artifact isn't the dropdown. It isn't even necessarily the interface.

It's the assumption that the interface is where software consumption gets measured.

For years, the software industry built an entire pricing discipline around a simple idea: the number of humans looking at screens was a decent proxy for how much software was being used.

Agents break that relationship.

The seat was always a proxy

That was the argument behind my CoStar piece a few weeks ago.

Seat pricing works because human labor historically placed a natural ceiling on software consumption. A salesperson can only research so many accounts. An analyst can only inspect so many records. An employee can only run so many workflows.

If you wanted materially more work done, you generally needed more people. More people meant more logins. More logins meant more seats.

So the seat became a useful proxy for consumption.

AI agents change the denominator. One employee with capable agents might research ten times as many properties, monitor ten times as many accounts, run vastly more analysis and execute far more workflows without the company hiring another person.

Software consumption can rise dramatically while human seat count stays flat — or falls.

That creates a strange paradox:

Software can become more valuable at precisely the moment the seat becomes less useful as a measure of that value.

CoStar's updated agreement gave me one example of how an incumbent might respond. When outside agent activity is detected, its contractual response can include treating that activity as additional users for licensing purposes.

An external agent, economically, starts looking like an unpaid seat. (realestateapi.com)

Salesforce appears to be approaching the same problem from another direction.

The seat isn't dead

This is where it's easy to overstate what's happening.

Salesforce has not abandoned licensing, and Headless 360 doesn't create some permissionless doorway into Salesforce. Authorized agents still inherit the identity, permissions, sharing rules, business logic and governance already established inside the customer's Salesforce environment. Salesforce is explicit that customers can extend the platform beyond traditional applications while keeping the same identity, security, governance and business logic they've already built. (salesforce.com)

So the emerging model isn't:

Seats disappear → usage pricing replaces them.

It's closer to:

Licensed identity + machine consumption.

A licensed front door, with an emerging meter for what happens once you're inside.

That's a far more interesting transition because both systems can coexist for a long time. The question isn't necessarily which meter survives. It's how their relative importance changes as more work moves from humans clicking through software to agents invoking capabilities directly.

Same question. Two answers.

Put CoStar and Salesforce next to one another and the contrast becomes revealing.

Both are sophisticated data platforms. Both are aggressively incorporating AI into their own products. Both recognize that an outside AI agent acting on behalf of a customer creates an economic question. And both still care very much about who is authorized to access the underlying platform.

It's also worth noting that neither company meters its own agents this way. CoStar's restrictions are aimed at AI outside the CoStar product. Salesforce's new usage types are scoped specifically to work performed by third-party agents. Both have concluded that whose agent is calling is the question that matters.

So this isn't a story about one company being "pro-AI" and another being "anti-AI."

The difference is the unit.

CoStar's agreement, at least as I read it, continues to frame the problem largely in terms of users. Salesforce is beginning to frame the problem in terms of work.

One asks:

How many?

The other is beginning to ask:

How much?

That distinction could end up mattering enormously.

Why the unit decides the shape of the industry

Here's the part I keep coming back to, because it isn't really about Salesforce or CoStar. It's about where value accumulates in the software stack.

For years, there has been enormous economic pressure for technology suppliers to move upward toward the end user. If you're a data provider, infrastructure provider or API company, the company above you often captures more of the economic upside. They turn your raw capability into an application, own the interface, own the user relationship and, crucially, sell the seats.

If your growth is ultimately tied to owning more human logins, the gravitational pull is obvious: build the application, own the interface, move up the stack, and eventually compete with some of the customers who originally built on top of you.

A meter based on work changes that equation.

If machine consumption itself becomes economically valuable — if a supplier can participate economically every time its data, domain logic or workflow capability gets used — then it may be able to capture more of the growth without owning the final interface.

That potentially creates a very different software ecosystem. Suppliers can remain suppliers while participating more directly in the value created downstream. Application companies can continue to own their users and workflows without every underlying provider feeling compelled to climb the stack and compete with them.

Agents make that possibility more interesting because they also change where software gets assembled.

The assembly point is moving

A huge ecosystem of developers, consultancies and ISVs has spent decades assembling capabilities from platforms like Salesforce into specific applications and workflows.

Headless 360 makes those underlying capabilities increasingly discoverable and composable by agents themselves.

Today, a developer may decide which API to call, which record to retrieve and which workflow to invoke. Tomorrow, an agent may reason through the problem, discover the appropriate capability and compose the sequence dynamically.

That doesn't eliminate the application layer.

But it changes where the application gets assembled.

And when the assembly point moves, the economics tend to move with it.

Built inside-out

If there's a broader product-design lesson here, I think it's that the next generation of software may increasingly be built inside-out.

Not merely API-first.

API-first is an old idea. Plenty of products were designed around a traditional application and later exposed their functionality through endpoints.

Inside-out is different.

The capability is the product.

The data, permissions, domain logic, workflows and actions form the durable core. The interface is simply one rendering of those capabilities: a browser for the human who wants one, an MCP tool for the agent, an API for another application, a CLI for the developer.

Salesforce's own framing is remarkably close to that idea — a platform whose trusted capabilities can be reused wherever people and AI agents work, with the same governance underneath no matter which surface asks. (salesforce.com)

The tell that a company has really made that transition may not be its architecture diagram.

It may be its rate card.

If you meter the surface, the surface is still the product. If you meter the capability, the capability is the product.

So what's the number?

Salesforce hasn't told us. The Headless Platform Interaction multiplier remains TBA.

When it does arrive, the figure worth watching isn't the multiplier by itself. It's how it compares to a standard Agentforce action, which currently draws 20 Flex Credits. One of those is what it costs to use Salesforce's agent. The other is what it costs to bring your own. The distance between them is the price Salesforce puts on that choice.

I don't know which way it goes. A premium would be defensible: Salesforce has charged for API access at the edition level for twenty years, and agents it doesn't control are harder to support and harder to forecast. A discount would be defensible too, and it's the one I'd lean toward, because the whole point of the architecture is to be reachable from wherever the work happens. Charging a toll on the door you just built is a strange way to encourage people through it.

The other thing I'd watch is whether one line item survives. Reading a record and invoking a Flow are different kinds of work at different costs, which is presumably why the first attempt separated them. A single flat rate has to be wrong for one of them. My guess is the distinction comes back.

What strikes me most is that Salesforce itself appears to still be working through what the appropriate unit should be. It started with two, then consolidated them into one, and left the price open in both versions.

I wouldn't read that as confusion. I'd read it as a reminder that the architecture has arrived before the pricing model.

We've spent two decades getting very good at pricing humans using software. We have barely begun figuring out how to price machines using software on their behalf.

A year ago, the question was whether agents might destroy SaaS applications. A few weeks ago, I argued that the more immediate casualty might be the seat.

Salesforce is now giving us a glimpse of the next question.

If the seat stops being the best proxy for software consumption:

What is a unit of software work worth?

The seat counted people.

The next meter may count work.

What nobody has established yet is exactly what a unit of work is.

And right now, the most interesting number in enterprise software is the one that hasn't been written yet.