Software without a screen: what changes if you run on an ERP

What “headless” means

A headless system, literally one without a head, keeps all its functions but gives up an interface of its own: the data and the operations stay, the screen you use them from is put somewhere else.

Until yesterday that was a technical choice made by a few products. It is becoming a strategy. In Salesforce’s case, Omdia describes AIforce as the layer where any application, tool or agent interacts with the platform directly through APIs. For an assistant that can use a screen the way a person would, hiding functions inside an interface no longer protects anything.

Whoever owns the window collects the value

A vendor like Notion is effectively forced to expose its own MCP server to stay competitive. The effort of building it is theirs. The result is that a person can use Notion without opening Notion, from someone else’s interface: Notion loses minutes of presence, and whoever owns that interface gains a feature without paying for it.

Figma is the sharpest case. Its MCP exists to give design context to tools that write code: the value moves downstream, to whoever generates the code, while the work of maintaining that context stays upstream.

The obvious objection is that the standard no longer belongs to any of them. That is true: MCP has been governed by a neutral foundation since December 2025. But neutrality concerns the specification, not the interface. Whoever owns the window the person types into keeps collecting the value, whoever governs the protocol.

The licence model bites its own tail

The same movement arrives from another direction. The business software of the last fifteen years is under pressure from four sides at once:

• Prices. The increases of the last two years have produced cancellations, not just grumbling.
• Overlap. General-purpose AI already covers some of what many vertical services sold as a distinguishing feature.
• Cost of building. Writing software with AI assistance makes it worthwhile to build a small single-purpose platform in-house instead of adopting an outside service.
• Licences. The per-user model bites its own tail: if I sell more productivity, fewer users are needed, so I sell fewer licences.

The fourth point is the most interesting, because it is structural and can’t be fixed with pricing. A vendor that sells per person and promises to make each person work better is promising to reduce its own revenue. That is why several vendors are moving to consumption pricing: charging for the operations performed instead of the people logged in.

What it means if you run on an ERP

For the vendor, the only defence left is to be the place where the data lives. For the buyer the reasoning flips: the value will not be in the interface of the systems you use, but in the fact that your data can be reached by an assistant when needed, with the right permissions. Three practical consequences:

• Ask what your ERP exposes. Full APIs, an MCP server, per-role permissions, a call log. If the answer is “just the screen”, that system is a constraint, not a foundation.
• Don’t build processes inside the interface. A rule that lives only in one vendor’s screen can’t be moved, and in a few years the screen may no longer be where the work happens.
• Keep a data layer of your own. It replaces no system: it normalises what arrives from several sources and makes it available under your own rules. It is the part that takes the most experience, but also the part that, once done, makes the rest downhill: exposing that data to an assistant over MCP becomes an addition, not a new project. We cover it on the data warehouse page.

A caution: this is a September 2026 reading of a fast-moving subject, and part of it will age quickly. The direction, though, looks clear to me. And a declaration of interest: we build exactly these layers, so weigh the above with that in mind.