How AI Becomes Real Work, Part 3: The End of the Software Seat

Once agents become users of software, seat-based pricing stops being a clean proxy for value.

Picture a sales rep with one CRM license and a growing cast of AI agents behind it. One updates records after calls. Another prepares a quote. A third drafts follow-ups, summarizes objections, and logs the next steps across systems. In finance, a similar pattern shows up when agents reconcile invoices, route exceptions, and draft procurement requests before a human ever steps in.

The org chart hasn’t changed. The seat count hasn’t changed. But the amount of software-driven work has.

That’s the economic mismatch at the center of the next phase of enterprise software.

For a long time, the seat was a sensible pricing unit because it tracked the thing that mattered most: how many people needed access to the software. If more employees used the product, the vendor could reasonably argue the customer was getting more value. It wasn’t perfect, but it was practical. Easy to package, easy to budget, easy to sell.

That logic starts to fray when software is no longer just waiting for a person to click the next button.

Seat-based pricing came from a world where the human user was the main actor. Software provided the interface, the workflow, the data model, and the permissions. The employee provided the labor.

In an agentic environment, that division changes.

Agents can now initiate tasks, complete steps, move information across systems, and make progress inside workflows with varying levels of human oversight. One person can supervise many software actors. Usage can spike without any increase in the number of employees licensed into the application. The login count barely moves while the work performed inside the system rises sharply.

That’s the key shift: the scarce resource is no longer just access. It’s execution.

A seat can still tell you who is authorized to use a product. It tells you much less about how much value the product is creating.

This is the real commercial transition underway.

Traditional SaaS mostly sold access to tools. You paid for the right number of people to log in, collaborate, and work through an interface. The value came from helping employees do their jobs more efficiently.

AI-native software increasingly sells something different: labor capacity embedded inside a workflow.

That doesn’t mean software becomes labor in every sense. But commercially, it starts to behave like it. It can perform variable amounts of work, at variable cost, with variable impact on the business. Once that happens, charging by headcount starts to look like charging for a factory by counting supervisors instead of output.

When software stops being only a tool and starts behaving like labor, the commercial model has to move with it.

There probably won’t be a single universal replacement. Different layers of the stack will price against different units, and that’s exactly what you’d expect.

At the infrastructure layer, pricing will often stay close to consumption: compute, tokens, API calls, storage, inference. At the platform layer, pricing may center on orchestration: runs, automations, workflow executions, agent sessions. At the application layer, the cleanest unit may be the business transaction itself: invoices reconciled, claims processed, quotes generated, documents reviewed, support cases resolved.

Some categories will push even further up the stack toward outcomes. Not because outcome pricing is easy, but because it’s attractive. If a product can credibly tie itself to revenue collected, time saved, or cost avoided, it moves closer to how the customer thinks about value in the first place.

That doesn’t mean every vendor will rush there. In many cases, the most durable pricing unit will simply be the one that best matches the work the product actually delivers and that both sides can measure without endless debate.

Pricing will move closer to the unit of work.

That’s the deeper pattern.

This is where AI pricing gets harder than it first appears.

Every software vendor wants some version of the same things: recurring revenue, healthy gross margins, pricing that customers can understand, and upside when usage expands. Those goals fit neatly together in a seat-based world. They become much harder to align when cost-to-serve varies with model choice, task complexity, workflow length, and customer behavior.

A product can be wildly useful and still have ugly economics underneath. High usage may delight customers while quietly crushing margins. Outcome pricing can sound elegant until both sides try to define the outcome cleanly. Customers want transparency and predictability. Sales teams want packaging that fits on a slide. Product teams need instrumentation, metering, and controls that reflect what is actually happening inside the system.

In AI software, a delightful user experience can still be a bad business model if the economics underneath aren’t controlled.

That’s why this is not just a pricing-page question. It’s a margin design question.

The old model made budgeting simpler because software spend often tracked headcount planning. More people, more seats. Fewer people, fewer seats. Procurement could compare contracts across vendors even when the products were very different because the commercial unit was familiar.

Now the questions get more operational.

How do you budget for variable agent activity? Who owns the spend when one automated workflow touches five systems? How does finance compare a seat-based contract with one priced by usage, runs, or completed actions? How do you allocate costs across teams when a shared agent stack serves sales, support, finance, and operations at the same time? How do you know whether the automation is actually cheaper than the labor it replaces or augments?

These aren’t edge cases. They become normal once software starts doing work on behalf of multiple teams.

That is why the buyer side will need more than procurement discipline. It will need a FinOps mindset for SaaS and AI: metering, tracing, spend visibility, cost attribution, policy controls, usage caps, approval thresholds. Not as bureaucracy for its own sake, but as the operating layer that makes variable software labor governable.

As software becomes more labor-like, software spend starts to look less like a licensing line item and more like operational spend.

This is where the conversation stops being only commercial and becomes architectural.

If pricing follows work, companies need technical visibility into work. Not just who logged in, but what ran, where, why, at what cost, with what result.

That requires workflow-level metering. End-to-end tracing across tools, models, and agents. Cost attribution by task, team, customer, or process. Model routing based on economics and risk. Policy controls for expensive or high-risk actions. Evaluation tied not only to model quality, but to business results and unit economics.

You can’t manage AI economics with application-level seat counts. You need workflow-level instrumentation.

Without that layer, every team sees only part of the picture. Procurement sees invoices. Engineering sees logs. Business owners see outcomes. Finance sees totals. Nobody sees the full unit economics of the work itself.

And that is exactly where a lot of confusion will come from over the next few years: companies will adopt agentic systems before they have the instrumentation needed to understand what those systems are really costing or returning.

The seat isn’t going to vanish overnight.

Most vendors will keep it around for a while because it still solves real problems. It gives customers a familiar base fee. It gives sales teams a clear package. It gives finance a predictable revenue foundation. In many categories, the near-term answer will be hybrid models: a platform fee plus usage, seats plus automation credits, access pricing layered with transaction volume.

That interim messiness is not a sign the market is failing. It’s what transition looks like.

Over time, each category will settle on the pricing unit that is easiest to measure, easiest to defend, and easiest for customers to budget against. Infrastructure will likely stay closer to consumption. Platforms will lean toward orchestrations and runs. Applications that sit closer to business processes will feel increasing pressure to price in terms of transactions, workflows, or results.

The common thread is simple: the pricing unit will move toward the work.

That’s where the value is moving, so that’s where the commercial model will eventually follow.

The seat worked when software value tracked human access.

It works less well when software is doing variable amounts of work on behalf of humans.

So the real question isn’t whether the seat disappears tomorrow. It’s whether seat count still describes where the value actually comes from. More and more, it doesn’t.

A good enterprise pricing model has always reflected how value is created. In the seat-based era, that meant charging for access. In the agent era, it will increasingly mean charging for execution.

And once software is priced by work completed, the next question isn’t commercial at all. It’s operational: how do you govern that work when agents are part of core business processes?

That’s where this goes next. Back to process.

Originally published at https://www.linkedin.com.