ES Technical meeting
Menu

You'll pay to access your own data

With agents that hold no seat and open no screens, per-user licenses stop making sense. Salesforce, SAP, and Microsoft are shifting to consumption pricing: charging for every operation an agent runs against the data. The problem is that you generated that data, and now operating on it costs.


In April 2026, Salesforce unveiled Headless 360. The line its co-founder Parker Harris used to sum it up leaves no room for interpretation: "Why should you ever have to log into Salesforce again?". The idea is to expose the entire platform —data, workflows, business logic— as APIs, MCP tools, and console commands, so that AI agents operate the system without any human ever opening a browser.

It isn't an isolated case. It's the first visible move in a shift that affects all enterprise software. And it's worth understanding where it points, because it has direct consequences for who controls your company's data and how much you'll pay to use it.

The business model that's breaking

For two decades, Salesforce, SAP, Microsoft, and the rest of the major vendors built their business on per-user pricing. That model works as long as there are people using screens: more employees, more licenses, more revenue.

AI agents break that equation. An agent has no seat, opens no screens, clicks nothing. As agents take on tasks people used to do, the number of human users falls — and with it, per-seat revenue. The vendors know this, and that's why they're rewriting their platforms for a world where the primary consumer of their systems is no longer a person, but an agent.

What's the answer? Stop charging per user and start charging for consumption: for every operation an agent runs against the data. Salesforce has already moved Agentforce and Data Cloud to consumption models, abandoning per-seat pricing. And it has done so with explicit logic: when the work is done by agents and not humans, charging per user stops making sense.

The problem: you generated that data

Here's the point that shouldn't be overlooked. If what sits on the other side of the API is an agent from your own company, paying the vendor to access your data is paying to be the customer of a proprietary database — one that holds information you generated yourself.

The mechanism is the consumption model, and its numbers are not small. In Salesforce Data Cloud —renamed Data 360 in late 2025— almost everything an agent does with the data costs credits: ingesting external data, unifying profiles, segmenting, and agent grounding. Profile unification, for instance, is the most expensive operation in the catalog. The rule of thumb circulating among implementers sums it up well: under this model, everything you do with the data carries a per-credit cost.

And there's a telling detail in how that cost is designed. Salesforce made data ingestion free from its own products. In other words: putting more data into its ecosystem costs nothing — what costs is operating on it. It's the classic walled-garden incentive: entry is free, staying is what you pay for.

It's not just Salesforce: it's the sector's pattern

The same model appears, under different names, across the entire data layer:

  • Snowflake charges for compute credits, for storage, and for egress — moving data out of its platform. Ingestion is free; taking the data to another region or another cloud carries a per-terabyte cost. As various industry analyses have noted, once you load large volumes of data, the egress fees and bandwidth limits make it hard to move elsewhere — which in practice creates lock-in.

  • Databricks measures consumption in DBUs (Databricks Units) and typically requires a minimum annual commitment that, according to industry analysts, starts in the six figures for full platform access.

  • Microsoft Fabric and Google BigQuery follow the same pay-per-use philosophy: for data processed, for reserved capacity, per operation.

The pattern is always the same: getting in is cheap or free; operating and, above all, leaving, is what you pay for. The more knowledge you build on top, the more expensive and the harder it becomes to walk away.

The second layer of the problem: jurisdiction

There's one more dimension, and it's the one most often overlooked. Most of these systems host the data on US hyperscaler infrastructure. And that means the data becomes, de facto, subject to United States law.

The CLOUD Act allows US authorities to compel a technology company headquartered in the US to hand over data, regardless of the country where it is physically stored. It isn't enough for the server to be in Frankfurt or Madrid: if the provider is American, the data falls within reach of a US demand.

This stopped being a theoretical debate. In June 2025, Microsoft's French subsidiary confirmed under oath before the French Senate that it could not guarantee the sovereignty of data against US authorities — not even for data hosted in France under an offering marketed as "sovereign." It's the industry itself acknowledging, on the record, that the problem exists.

The technical distinction matters: data residency (where the bits are) is one thing, and sovereignty (which laws they're subject to) is another entirely. Ticking the "data in the EU" box doesn't resolve the second. What's decisive isn't where the data is stored, but who can access it and under which jurisdiction.

What this means for a European company

Put the two pieces together and the picture is clear. The next generation of enterprise platforms offers to let you operate your AI agents on your data — but in exchange for two things: paying for every access and accepting that this data lives on someone else's infrastructure, subject to a jurisdiction that isn't yours.

Neither is an inevitable consequence of the agentic era. They are business-model decisions. And there's an alternative that starts from a different premise: the customer's data belongs to the customer. It should live on the customer's infrastructure, in an open format, and access to it should be neither intermediated nor monetized by the vendor that originated it.

That's the position from which we build opendome. Not because we reject enterprise software —it will remain where much of the data is generated— but because we believe the system that safeguards an organization's knowledge should be distinct from the one that produces it. Open, sovereign, and under the customer's control.

The question worth asking today isn't which platform has the best agent. It's simpler, and more uncomfortable: three years from now, whose data will it be, and how much will it cost you to use it?

Want to go deeper?

Book a 30-minute technical meeting for your team.

We will show you how the Cell Model fits your stack, using your current data lake with no migration required.

Book a technical meeting