Does this mean we have to stop selling per user?

Not immediately. The question is what share of the work in your product already arrives through an API rather than through a login. If that share is low and steady, the seat still measures something real. If it climbs every quarter, the seat measures a shrinking part of the usage, and it is better to change the model while the numbers are still good than after renewals start to slip.

How do we price the machine surface when it has no users to count?

The machine surface is priced on volume or on outcomes, and the choice between the two comes down to one thing: whether the action can be rolled back. If it can, you can guarantee an outcome and charge for the outcome, because mistakes can be corrected. If it cannot, you are selling access and an approval surface, and the price should say so rather than promise something you cannot deliver.

We have no agents in the product yet. Is this relevant to us now?

It is relevant as soon as the product has an API that customers or their vendors use. The machine surface does not appear on the day you launch an agent. It appears on the day somebody outside the company starts doing work in the product without opening your screens, and that usually happens before anyone internally has called it a strategy.

Who should own the design of the machine surface?

Whoever owns the naming and the error messages, which usually means a designer working with whoever owns the API. A machine surface has no screens, but it has names for actions, sequences that have to make sense and failures that have to be understandable with no person present. Left entirely to engineering, it becomes hard to use in the same way a bad screen is hard to use, only without anyone complaining in a usability test.

Can we simply not open the product to outside agents?

You can, and for some products that is the right call for a while yet. The price you pay is that customers do the work somewhere else once a competitor opens theirs, and that you lose both the usage and the data it created. The decision belongs in a distribution discussion with a date on it, not in a technical backlog where it waits until somebody has time.

Design

Salesforce moved the interface out of the product. The price has to follow.

Salesforce launched AIforce to let CRM work happen inside Claude, Slack and Teams. The interface does not disappear. It splits into a machine surface and a human surface, and only one of them has a seat to sell.

By Sveinung Totland3 min readSeptember 28, 2026

A glass-walled meeting room where a woman sketches two groups of boxes connected by arrows on a whiteboard while two colleagues listen at an oak table.

What happened

Salesforce launched AIforce at Dreamforce on 15 September 2026. The interface layer lets people do CRM work inside Claude, Slack and Teams rather than inside Salesforce, and it sits on top of Agentforce, Data 360 and Customer 360.

Why the launch reads as a design story

The launch is being read as a prediction that the screen goes away. That reading treats the interface as a layer somebody can remove, and it stops at the question of where the work is displayed.

The interface did not disappear. The interface moved out of the product and became several surfaces, and the new surfaces are owned by other companies. A business running CRM work inside Claude does not have fewer interfaces than before. It has one more, and it has lost control of how that one looks.

We want to disaggregate the UI and bring AI in to kind of replace it.

Patrick Stokes, President of Applications and Marketing at Salesforce, Dreamforce, 15 September 2026.

What it means if architecture, design and price are one decision

The seat is a unit of measurement that assumes an interface. A per-user licence counts how many people log in to the vendor's own surface. Once the work moves to Claude, Slack and Teams, there is no login left to count, and the pricing model loses its unit before anyone has decided to change it.

Salesforce disclosed no prices, no licensing model and no user numbers for AIforce at launch. The order of the decision is still readable. The architecture choice put an interface layer over the core, the design choice moved the work onto surfaces Salesforce does not own, and together those two choices took away the unit the pricing model was built on. How the three choices hang together is set out in Architecture, design and price are the same decision.

A product with an agent in it has two surfaces, and the two surfaces are different goods.

The machine surface
Where the agent works. The surface has no navigation, no visual design and no login to count. It has a set of actions, a set of permissions and high volume. The machine surface is cheap to offer and hard to price per user.
The human surface
Where somebody approves. The surface has few users and low frequency of use, and it carries the responsibility for what the agent has already done. The human surface is the one of the two that still has a seat to sell.

The cheapest place to discover that one of the two surfaces is missing is still in a drawing, and why that is so is set out in Design is where a technology choice gets cheap.

What we do differently

Apps AS runs both surfaces on apps.no at the same time, and they are built as two different things. The publishing agent that writes this article reaches the CMS in Munin, our own customer platform, through the machine surface. The agent reads the whole article archive, writes the article in Norwegian and English and files it as a draft. The publishing agent does not use the admin interface at all.

Approval happens on the other surface. A person opens the draft in Munin's own interface and publishes it, or leaves it where it is. Munin is built around exactly that split: you set which workflows run unattended, which escalate, and which wait for approval.

The rule we use when pricing something like this is to count the surface that carries the responsibility. The surface that does the work gets cheaper every year, and it is the first one to stop having users. The same problem seen from the consultant's side is set out in What a consultant delivers when agents do the work. What changes once the action has already been taken is set out in What changes when software acts on its own.

Count how many people actually log in

Do you sell per seat? Count how many of the seats were logged into last month, and what share of the work arrived through an API over the same period. Send the two numbers to hello@apps.no. We will reply with which of the two surfaces we would price, and what we would stop counting.

Sources

Salesforce Ben, Salesforce Launches AIforce at Dreamforce '26: 'AI Replaces the UI', 15 September 2026, read 25 September 2026. salesforceben.com
CIO Dive, Salesforce launches AIforce to harness agentic architecture, read 25 September 2026. ciodive.com
Apps AS, Munin, product page read 25 September 2026. apps.no

About this article. Written by Sveinung Totland, CEO of Apps. A take using the pillar Design, technology and business as one decision as its lens. The details about AIforce come from Salesforce Ben's and CIO Dive's coverage of Dreamforce, read 25 September 2026. Salesforce disclosed no prices, no licensing model and no user numbers at launch, and no such figures are estimated here. The description of the publishing agent is based on the agent's own setup against Munin. This article uses no client figures.

FAQ

Does this mean we have to stop selling per user?: Not immediately. The question is what share of the work in your product already arrives through an API rather than through a login. If that share is low and steady, the seat still measures something real. If it climbs every quarter, the seat measures a shrinking part of the usage, and it is better to change the model while the numbers are still good than after renewals start to slip.
How do we price the machine surface when it has no users to count?: The machine surface is priced on volume or on outcomes, and the choice between the two comes down to one thing: whether the action can be rolled back. If it can, you can guarantee an outcome and charge for the outcome, because mistakes can be corrected. If it cannot, you are selling access and an approval surface, and the price should say so rather than promise something you cannot deliver.
We have no agents in the product yet. Is this relevant to us now?: It is relevant as soon as the product has an API that customers or their vendors use. The machine surface does not appear on the day you launch an agent. It appears on the day somebody outside the company starts doing work in the product without opening your screens, and that usually happens before anyone internally has called it a strategy.
Who should own the design of the machine surface?: Whoever owns the naming and the error messages, which usually means a designer working with whoever owns the API. A machine surface has no screens, but it has names for actions, sequences that have to make sense and failures that have to be understandable with no person present. Left entirely to engineering, it becomes hard to use in the same way a bad screen is hard to use, only without anyone complaining in a usability test.
Can we simply not open the product to outside agents?: You can, and for some products that is the right call for a while yet. The price you pay is that customers do the work somewhere else once a competitor opens theirs, and that you lose both the usage and the data it created. The decision belongs in a distribution discussion with a date on it, not in a technical backlog where it waits until somebody has time.