14: Commercialization and the Future: From SaaS to Outcome as a Service

Across the first thirteen posts, we moved from the lowest layer to the product layer:

Tokens
↓
Next-token prediction
↓
Transformer and attention
↓
Pretraining, alignment, inference
↓
RAG, Tool Use, Agents
↓
Engineering systems and AI native products

Now there is one final question:

When these capabilities enter the business world,
what should the product actually sell?

Traditional software commercialization mostly sells tools.

The user buys a system, an account, or a set of features, then uses those tools to get work done.

AI products push this one step further:

The user is not only buying tools.
The user is increasingly buying completed work.

That is the topic of this post.

This does not mean SaaS disappears.

It does not mean every AI product must charge by outcome.

It means that once models, context, tools, and agents are composed together, software starts moving from helping people operate toward helping people finish. Business models naturally have to change with that shift.

1. Why AI Commercialization Is Not Just SaaS With a Price Increase

The traditional SaaS contract roughly says:

I provide a software system.
You pay by user, plan, or feature.
Your own team completes the work inside the system.

This model has been successful for a reason.

Traditional software has several useful properties:

Low marginal cost
Relatively deterministic output
Clear responsibility boundaries
The user still performs the labor
The vendor mainly delivers feature availability

Think of CRM, project management, spreadsheets, knowledge bases, finance systems, and design tools.

Software digitizes workflows, moves collaboration online, and structures data.

But the people who make judgments, write content, contact customers, review exceptions, and push work forward are usually still the users.

Once AI is added, the problem changes.

An LLM does not merely expose features.

It can participate in cognitive labor:

Understand the request
Read context
Generate a plan
Call tools
Check results
Iterate

So the business contract begins to loosen.

The user naturally asks:

If the system can already read documents, draft content, run workflows, and check exceptions,
why am I only paying for an account?
Is what I really want to buy the completion of this work?

This is the first way AI pressures SaaS.

It does not merely make old features smarter.

It shifts the reason users buy software from using features toward getting results.

2. First Principle: Users Do Not Buy Models, They Buy Task Outcomes

From first principles, commercialization should not begin with:

How strong is the model?
How impressive is the agent?
Can the feature chat?

It should begin with:

Why would the user pay?

Users do not usually pay for the model itself.

They pay for a change:

A task gets done faster.
A task gets done more cheaply.
A task gets done with fewer errors.
Results become more consistent.
The business depends less on scarce experts.
The operation becomes easier to scale.

So the commercialization chain for AI products should look like this:

User goal
↓
Repeatable task
↓
Verifiable outcome
↓
Manageable risk
↓
Sustainable cost
↓
Repeatable delivery

The model is only one layer in that chain.

What is purchased is the task outcome.

But an outcome cannot stay vague.

It must be defined.

For example:

Not "AI handles customer support,"
but "how many tickets are resolved within a defined knowledge base and permission scope."

Not "AI writes sales emails,"
but "how many qualified lead touches and follow-up records are produced."

Not "AI reviews legal documents,"
but "how many high-risk clauses are identified within agreed contract types."

Not "AI writes code,"
but "how many changes are completed under passing tests and code review constraints."

Once outcomes can be defined, measured, verified, and reviewed, the business model can move from selling software toward selling results.

This is also why Post 13 emphasized product systems.

A raw model does not directly become a business outcome.

Business outcomes come from:

Model capability
+ business context
+ tool calls
+ workflow orchestration
+ evaluation and validation
+ permission control
+ failure recovery
+ operational delivery

The core of AI commercialization is not wrapping a model as SaaS.

It is wrapping probabilistic capability as deliverable outcomes.

3. From Seat to Token to Outcome

AI product pricing tends to move among four models.

The first is seat-based pricing.

Charge by user count.

This is the familiar SaaS model.

Its strengths are simplicity, predictability, and fit with enterprise procurement.

But it has a problem:

AI cost and value are not always linear with headcount.

One heavy user may trigger a large amount of inference, retrieval, tool calling, and long-running work every day.

One light user may ask only a few questions.

If both are priced by the same seat, the vendor may absorb cost mismatch, and the customer may feel the value is uneven.

The second model is usage-based pricing.

Charge by tokens, credits, calls, document volume, or task count.

This model is closer to AI cost structure.

Inference cost really does rise with tokens, context length, tool calls, and retries.

But pure usage pricing has its own problem.

It creates anxiety:

Am I burning money every time I ask one more question?
Should I use the product less?
Why am I paying for failed attempts?

If pricing is tied only to usage, the user may be incentivized to use the product less, not delegate more work to it.

The third model is task-based pricing.

Charge per generated report, reviewed contract, screened candidate, or handled support case.

Task-based pricing is closer to user perception than tokens.

Users do not care how many tokens the model consumed.

They care whether the work was completed.

But task pricing requires clear task boundaries:

What counts as one task?
What counts as done?
How is failure handled?
What if a human takes over midway?
What if the user asks for many revisions?

The fourth model is outcome-based pricing.

Charge by resolved tickets, approved documents, qualified leads, completed deliveries, or cost savings.

This is closest to outcome as a service.

It is most aligned with customer value.

It is also the hardest.

Outcome pricing means the vendor takes on more responsibility:

Can the outcome be attributed?
Can quality be verified?
Can risk be controlled?
Does the price cover cost?
Does the customer workflow cooperate?
Who handles exceptions?

So the future is more likely to be hybrid than pure.

For example:

The base platform charges by seat.
High-consumption capabilities charge by usage.
Standard tasks are sold as task packages.
High-value scenarios charge by outcome or revenue share.

Pricing moves from “how much is an account?” to “how are different layers of value measured, priced, and risk-shared?“

4. Gross Margin Becomes a Product Design Problem

One attractive feature of traditional SaaS is low marginal cost.

Serving one more customer does increase cost, but usually not linearly with every user action.

AI products are different.

Every answer, retrieval, tool call, long-context operation, and retry can create real cost.

More importantly, users do not buy tokens.

They buy successful tasks.

So the key question is not:

What is the cost of one inference call?

It is:

What is the total cost per successful task?

Roughly:

Cost per successful task
= model inference cost
+ retrieval and tool cost
+ context assembly cost
+ failed retry cost
+ human review cost
+ monitoring, audit, and compliance cost

If a task fails after consuming a large amount of tokens and human review, that is still cost.

If the model gives a polished answer but the user never adopts it, that is not yet a business outcome.

This forces product and engineering teams to redesign the system.

For example:

Use cheaper models for simple tasks.
Route complex tasks to stronger models.
Require human confirmation for high-risk tasks.
Compress and retrieve long context before generation.
Cache repeated questions.
Structure outputs to reduce rework.
Evaluate and validate key steps.
Degrade quickly on failure instead of retrying forever.

This is why The Math Behind LLM Pricing is not only an engineering topic.

It directly affects the business model.

When AI products start selling outcomes, cost control is no longer a back-office optimization.

It becomes part of product design.

5. Product Shape: Workflows Monetize Better Than Chat

Chat is good for exploration.

Commercialization usually needs repeatability.

If an AI product is only a chat box, the user has to explain background, paste material, specify format, judge the result, and copy the output into another system every time.

That is valuable, but it is closer to an intelligent assistant than a scalable commercial product.

AI products that monetize well usually compress the capability into workflows.

A workflow answers:

What is the input?
Which context is required?
What are the intermediate steps?
When are tools called?
When does a human confirm?
What is the output format?
How is completion judged?
How does failure recover?
Where is the result delivered?

Take a sales scenario.

A chat-style AI might be:

Help me write a sales email.

A workflow-style AI is closer to:

Read target accounts from the CRM.
↓
Generate an outreach strategy from industry and interaction history.
↓
Write a personalized email for each account.
↓
Check compliance and tone.
↓
Ask the salesperson to confirm.
↓
Send the email.
↓
Record the touch.
↓
Schedule the next step from the reply.

The first sells generation capability.

The second sells a business process.

If the product wants to move toward outcome as a service, it has to move from chat into workflows, and in some cases into agentic task systems.

Only workflows make it practical to define boundaries, calculate cost, verify quality, accumulate data, and manage risk.

6. Organizational Boundaries: AI Products Enter Customer Operations

Traditional SaaS usually stands outside the customer organization.

It provides the system.

The customer uses the system.

The customer’s own team remains responsible for the final business result.

Outcome as a service pushes the vendor deeper into the customer’s operations.

If you want to be responsible for results, you have to understand and participate in the customer’s workflow.

This creates several changes.

First, delivery is no longer just account activation.

It also includes:

Connecting customer data
Understanding customer rules
Configuring task boundaries
Setting permissions and approvals
Building evaluation samples
Designing exception handling
Training the customer team to collaborate with the system

Second, customer success is no longer only teaching users how to use features.

It starts to look like operational delivery.

Customer success teams need to track:

Task completion rate
Human takeover rate
Error types
Time saved
Quality volatility
Cost and margin
Internal customer adoption

Third, the boundary between product teams and service teams becomes blurrier.

If the AI system cannot fully handle long-tail exceptions, the vendor may need to include some human operation inside the delivery chain.

That sounds unlike traditional SaaS.

But it may be closer to real commercialization.

In many high-value scenarios, customers are not simply buying software.

They are buying:

This business function becomes faster, cheaper, and more reliable.

Whoever can take responsibility for that gets closer to the value center.

7. Moats: Not Just Models, But Distribution, Context, Workflow, and Trust

When people discuss AI commercialization, they often ask:

Is the model the moat?

Models matter.

But for most application-layer products, the model is rarely the only moat.

Foundation models keep improving, API capabilities get stronger, and open models continue to catch up.

The application layer should pay attention to a different set of assets:

Distribution: can you reach and retain the target users?
Private context: are you connected to real work data?
Workflow integration: are you inside critical business processes?
Evaluation samples: do you know what a good result means?
Feedback data: can real tasks improve the system?
Trust system: will customers dare to delegate the task to you?
Cost operations: can you deliver results at sustainable cost?

These assets may be less glamorous than models.

They are closer to commercial defensibility.

This is especially true for outcome products.

If a product is deeply embedded in customer workflows, understands customer rules, has real evaluation samples, provides reliable audit, permission, and exception handling, and can complete tasks at lower cost, a later entrant cannot easily replace it just by connecting to a stronger model.

This is the difference between an AI native product and a thin model wrapper.

A wrapper’s core asset is the prompt.

An AI native product’s core asset is the task system.

An outcome-as-a-service product’s core asset is validated delivery capability.

8. Risk: The Closer You Get to Outcomes, the Less a Prompt Can Carry Responsibility

The closer a product gets to outcomes, the more risk matters.

If a chat assistant gives a wrong answer, the user may simply ask again.

If an agent sends the wrong email, changes the wrong data, misreads a contract, or approves the wrong expense, the consequences are different.

So outcome as a service cannot rely on:

Ask the model to be careful.

It needs system-level governance.

At minimum:

Task boundaries: what can and cannot be done
Permission system: what can be read, changed, and done on whose behalf
Approval mechanism: which actions require human confirmation
Audit logs: why each step happened and what context was used
Quality evaluation: how correctness and quality are judged
Exception handling: how failures are rolled back, repaired, and communicated
Responsibility allocation: what the vendor, customer, and end user each own

Risk governance is not a blocker to commercialization.

It is a commercialization capability.

Customers will pay for outcomes only when they dare to delegate the task.

Trust is not marketing copy.

Trust is product system capability.

9. The Future: SaaS Does Not Disappear, But It Gets Re-layered

Will AI replace SaaS?

My view is: not directly, but it will re-layer it.

Future software may contain several layers at once.

The first layer is the system of record.

Store customers, orders, contracts, documents, finance, knowledge, and permissions.

These systems remain important.

AI needs reliable data sources.

The second layer is the system of engagement.

Let people view, edit, approve, collaborate, and track work.

Humans still need interfaces.

But the interface may not be traditional forms and buttons. It may be conversation, canvas, review queue, or agent workspace.

The third layer is the system of intelligence.

Understand goals, assemble context, generate plans, and decide the next step.

This is the software layer most directly changed by LLMs.

The fourth layer is the system of action.

Call tools, execute workflows, handle exceptions, and push tasks forward.

This is where Tool Use and Agents create value.

The fifth layer is the system of accountability.

Validate results, record traces, manage risk, and uphold commitments.

This is the layer outcome as a service must add.

So SaaS does not become an obsolete word.

It expands.

Some SaaS products will continue selling systems.

Some will become copilots.

Some will become agent workspaces.

Some will evolve from software companies into something closer to AI-enabled service companies that commit to business outcomes.

10. Common Misconceptions

Misconception 1: AI Will Make All SaaS Disappear

It will not.

Many systems create value through records, permissions, collaboration, compliance, and organizational memory.

Those do not disappear just because a model can generate text.

AI is more likely to transform the engagement, intelligence, and action layers of SaaS.

Misconception 2: Outcome Pricing Is Always More Advanced Than Seats

Not always.

Outcome pricing works only when the result is definable, attributable, verifiable, and risk-controllable.

If task boundaries are fuzzy, customer workflows are complex, or quality is hard to judge objectively, forcing outcome pricing creates more disputes.

Misconception 3: If the Model Is Strong Enough, You Can Sell Outcomes

A strong model is only one prerequisite.

Selling outcomes also requires workflows, evaluation, permissions, audit, exception handling, cost control, and customer operations.

A raw model does not automatically become a deliverable business.

Misconception 4: Usage Pricing Is the Fairest

Usage pricing is fairer to vendor cost.

It is not always fairer to customer value.

Customers want completed work, not consumed tokens.

Good pricing balances cost, value, and risk.

Misconception 5: An Agent Is a Digital Employee

That phrase is memorable, but it oversimplifies.

Employees do not only execute tasks. They take responsibility, communicate, understand organizational context, and handle exceptions.

Agents can own parts of a task chain, but the product still has to define boundaries, permissions, review, and responsibility.

11. Product and Business Implications: Define the Outcome Before Designing the System

In practice, I would ask AI product teams to answer these questions first:

1. What task does the user truly want to delegate?
2. What are the input, output, and completion criteria?
3. Which steps can be automated, and which require human confirmation?
4. How is the result verified, and how does failure recover?
5. What is the real cost per successful task?
6. Should the pricing unit be seat, usage, task, or outcome?
7. Which risks will the vendor take, and which will it not take?
8. Which data, workflows, and evaluation samples become long-term defensibility?

These questions matter more than “should we add an AI feature?”

The key to AI commercialization is not whether a model is present.

It is:

Can you turn model capability into task outcomes customers will keep buying?

This changes product design, sales messaging, customer success, engineering architecture, cost models, and organizational capabilities.

In the past, many software companies watched:

How many users logged in?
How many features were used?
How many seats were sold?
What is the renewal rate?

AI products need another set of metrics:

How many tasks were completed?
What was the success rate?
What was the human takeover rate?
What was the cost per successful task?
Was outcome quality stable?
Is the customer willing to delegate higher-value tasks?

Once metrics move from usage to outcomes, the business model naturally changes.

12. One-Sentence Summary

Since the first post, we have kept returning to this:

At the bottom, an LLM predicts the next token from context.

But once that capability is placed inside a product system, it gradually becomes:

Understand the goal
↓
Assemble context
↓
Generate a plan
↓
Call tools
↓
Validate results
↓
Deliver the task

Commercialization cares about that final step.

In one sentence:

The endpoint of AI commercialization is not selling smarter software, but selling verifiable, accountable, sustainably delivered outcomes.

This does not mean every product must become outcome as a service.

It means AI will keep pushing software from tools into task systems, and from task systems into outcome delivery systems.

With that, the main arc of “Understanding LLMs from First Principles” is complete.

If the fourteen posts compress into one sentence, it is this:

LLMs begin with next-token prediction,
compress language and world structure through scaled training,
then move through alignment, inference, retrieval, tools, agents, engineering systems, and product design,
until they finally enter real tasks and business outcomes.

The next pieces are no longer the main arc. They are deeper topics: Mixture-of-Experts, long context, prompt injection, agent evaluation, multi-agent orchestration, cost optimization, on-device models, multimodality, and workflow agents.