DEV Community: Ciroandrea

What Should an AI Runtime Remember About an Execution?

Ciroandrea — Thu, 03 Sep 2026 08:13:06 +0000

A while ago, I would have assumed that accurate usage tracking gave me most of what I needed to reason about the economics of an AI product.

If a workflow costs 10 credits, the important engineering problems seemed fairly clear.

Was the customer allowed to run it? Were the 10 credits consumed exactly once? Did retries preserve the intended commercial semantics? Did the final usage record match what actually happened?

Those are difficult problems, especially once concurrency, retries and distributed execution enter the picture. But if the system handled them correctly, I thought the resulting usage data would provide a solid foundation for understanding the business later.

I'm no longer sure that's enough.

Consider a record like this:

customer: customer_123
workflow: research_report
credits_consumed: 10
status: completed

From a commercial perspective, this may be perfectly correct.

The customer had enough credits. The workflow was authorized. Ten credits were consumed exactly once. The report was delivered.

Nothing is obviously wrong.

Now imagine that, a month later, someone asks a different question:

Why did this research workflow become more expensive to run?

The usage record suddenly tells us much less than it appeared to.

It doesn't tell us whether the workflow completed on its first attempt or its third. It doesn't tell us whether a tool failed, whether a fallback model was used, whether an external API was called or whether additional inference happened after a retry.

It tells us the commercial result of the execution.

It may not tell us enough about the execution itself.

I recently explored the conceptual distinction between customer value, commercial consumption and economic execution in the Licenzy Guides:

Your AI Product Has Three Different Units: Value, Commercial and Economic

I won't repeat that framework here. The engineering question I'm interested in now is what that separation means for the runtime underneath it.

The question is no longer only:

What should the system meter?

I'm increasingly interested in another one:

What should the runtime remember after an execution is over?

I Thought Accurate Metering Would Be Enough

There is a good reason to start with metering correctness.

If an AI product uses credits, quotas or another form of usage allowance, the commercial abstraction has to remain trustworthy under conditions that are anything but simple.

Two requests can arrive concurrently. A client can retry after a timeout. A worker can complete even though the caller never receives the response. The same logical operation can appear more than once at different points in a distributed system.

So a large part of the engineering work naturally focuses on preserving commercial correctness:

Commercial State
        ↓
Authorization
        ↓
Execution
        ↓
Consumption
        ↓
Updated Commercial State

If the customer has 10 credits and a workflow requires 10 credits, the system should not accidentally authorize two concurrent executions against the same allowance.

If a network retry occurs, it should not blindly charge the customer twice for what the product considers one logical operation.

This is the same class of problem that makes idempotency so important in distributed APIs: a caller may retry an operation without knowing whether the previous attempt already produced its side effect.

AWS has a useful treatment of this problem in Making retries safe with idempotent APIs.

If consumption succeeds but the response is lost, retrying the request should not silently create a second commercial event.

These are runtime correctness problems, and solving them matters.

But there is a subtle limitation.

Suppose we solve all of them.

The final commercial history might still reduce the entire interaction to something like:

execution_id: exec_42
credits_consumed: 10
result: completed

That record can answer an important question:

Was the commercial rule applied correctly?

What it cannot necessarily answer is:

What actually happened while producing the result?

Those questions looked much closer to me when I first started thinking about usage infrastructure.

The deeper I get into variable AI execution, the less interchangeable they seem.

One Commercial Event Can Hide Several Execution Attempts

Take a research workflow that consumes 10 credits.

On a normal run, the execution might look like this:

Research Request
      ↓
Retrieval
      ↓
Model Call
      ↓
Tool Call
      ↓
Validation
      ↓
Success

The runtime consumes 10 credits and records the workflow as completed.

Now consider another request for exactly the same product operation.

This time the tool call times out.

The runtime retries the work. The second attempt uses a fallback model, performs another retrieval, calls an external API and eventually succeeds.

Research Request
      ↓
Attempt 1
      ↓
Retrieval
      ↓
Model Call
      ↓
Tool Call
      ↓
Timeout
      ↓
Attempt 2
      ↓
Retrieval
      ↓
Fallback Model
      ↓
External API
      ↓
Tool Call
      ↓
Validation
      ↓
Success

Commercially, the product may still want both interactions to mean exactly the same thing:

10 credits consumed
1 research report delivered

That can be the correct product decision.

A retry caused by infrastructure failure does not automatically need to become a second customer charge. A fallback model does not automatically need to become a new pricing concept. An internal routing decision does not necessarily belong in the customer's mental model at all.

But economically, the second execution has a different history.

Some of the work that contributed to its cost happened during an attempt that ultimately failed. Some happened during the successful attempt.

And if we preserve only the final commercial event, that history can disappear behind a perfectly correct number:

10 credits consumed

This is the part I find interesting.

Commercial abstraction is useful precisely because it hides implementation complexity from the customer.

But once we intentionally hide that complexity commercially, we have to decide whether we are also willing to lose it internally.

Those are two very different decisions.

The Runtime Needs an Identity for the Work

Once I started thinking about what information should survive an execution, the first problem was identity.

At first, a request ID seems like an obvious answer.

A request enters the system, receives an identifier, produces some logs and eventually completes. If something goes wrong, we search for that ID and reconstruct the path.

That works reasonably well when one request maps cleanly to one execution.

AI workflows make that assumption much less comfortable.

A single customer operation can cross several boundaries. It may move through an API, a queue and one or more workers. It may pause while waiting for an external service. A failed attempt may be retried by infrastructure rather than by the original caller.

The HTTP request that started the work may disappear long before the work itself is finished.

More importantly, a retry creates an identity question.

Suppose a customer asks for one research report.

The first attempt fails after already consuming model and tool resources. The runtime retries and the second attempt succeeds.

From the product's perspective, this may still be one logical operation:

Customer Intent
      ↓
Generate Research Report
      ↓
10 Credits
      ↓
1 Completed Report

From the execution perspective, however, there were two attempts:

Logical Execution: exec_42
      │
      ├── Attempt: attempt_1
      │      ├── Retrieval
      │      ├── Model Call
      │      ├── Tool Call
      │      └── Timeout
      │
      └── Attempt: attempt_2
             ├── Retrieval
             ├── Fallback Model
             ├── External API
             ├── Tool Call
             └── Success

Collapsing those attempts into a single final state loses information.

Treating them as completely unrelated executions loses something else: the fact that both attempts belong to the same logical piece of work.

That suggests a distinction I now find useful:

The identity of the business operation and the identity of an execution attempt are not necessarily the same thing.

An execution_id can identify the logical work the product intended to perform.

An attempt_id can identify one attempt to perform that work.

The exact naming is less important than preserving the relationship.

execution_id: exec_42

attempt_1
    parent: exec_42
    result: failed

attempt_2
    parent: exec_42
    result: succeeded

Now a model call, tool invocation or external API interaction can be associated not only with the customer or workflow, but with the attempt during which it actually happened.

If I only know that exec_42 completed, I know the final state.

If I know that exec_42 required two attempts, and I can associate meaningful execution events with each one, I have a history.

And those are not the same thing.

What Is Actually Worth Remembering?

This creates another problem.

If preserving execution history is useful, the naive answer is to record everything.

Every prompt. Every response. Every internal state transition. Every network call. Every tool payload. Every retry. Every token count. Every latency measurement. Every provider response.

That quickly becomes both impractical and conceptually messy.

It also turns the problem into generic observability.

That is not what I'm interested in here.

The question is narrower:

Which facts about an execution might still matter when I need to understand its economic behavior later?

For the research workflow, a minimal history might look something like this:

execution.started
      ↓
model.usage.observed
      ↓
tool.invoked
      ↓
tool.failed
      ↓
attempt.failed
      ↓
retry.started
      ↓
model.usage.observed
      ↓
external_api.used
      ↓
execution.completed
      ↓
commercial_consumption.applied

Not every application needs these exact events.

The point is not the taxonomy.

The point is that some execution facts may deserve a different lifecycle from ordinary diagnostic data.

For example, imagine that a model invocation contributes a meaningful variable cost to the workflow.

A durable record might contain something conceptually similar to:

{
  "executionId": "exec_42",
  "attemptId": "attempt_2",
  "type": "model.usage.observed",
  "provider": "example-provider",
  "model": "model-b",
  "inputUnits": 18420,
  "outputUnits": 2310,
  "observedAt": "..."
}

This is deliberately much smaller than the model interaction itself.

I may not need the complete prompt to answer an economic question. I may not need the generated text. I may not even need every piece of diagnostic metadata that was useful while the request was running.

What I may need is enough information to establish that a particular execution attempt consumed a particular measurable resource at a particular point in time.

The same reasoning can apply to a paid external API:

{
  "executionId": "exec_42",
  "attemptId": "attempt_2",
  "type": "external_api.used",
  "service": "example-search-api",
  "quantity": 1,
  "observedAt": "..."
}

Or to a failed attempt:

{
  "executionId": "exec_42",
  "attemptId": "attempt_1",
  "type": "attempt.failed",
  "failureCategory": "tool_timeout",
  "observedAt": "..."
}

Individually, these records do not explain the economics of the workflow.

Together, however, they preserve facts that would otherwise disappear behind the final state.

I don't want an economic system to infer that a retry probably happened because latency increased. If the retry itself matters, I would rather preserve the fact that it happened.

I don't want it to guess that a fallback model was probably responsible for higher cost because provider spend increased. If the runtime knows which model executed, that fact can be recorded when the evidence exists.

This is where I've started thinking less in terms of collecting more metrics and more in terms of preserving evidence.

Logs, Metrics and Evidence Are Not the Same Thing

I'm using the word evidence deliberately, but not as a claim that this is some established industry taxonomy.

It is a distinction that has become useful while reasoning about the architecture.

Logs, metrics and durable execution evidence can overlap in the information they contain, but I increasingly think they serve different questions.

Mechanism	Useful Question
Logs	What happened inside the system while I debug or operate it?
Metrics	How much, how often or how quickly is something happening?
Execution evidence	What durable facts would let me reconstruct this specific execution later?

A log line might tell me that a tool call timed out.

A metric might tell me that tool failures increased from 1% to 4% this week.

Both are useful.

But suppose I want to understand why exec_42 had a different economic profile from exec_17.

Now I need to connect specific facts.

Which attempts belonged to each execution? Which model invocations occurred? Which paid tools or APIs were used? Did a failed attempt consume resources before the successful attempt began? Which commercial consumption event ultimately corresponded to the logical operation?

The problem is no longer only observability in the operational sense.

It is reconstruction.

That changes what I care about in the data.

Operational telemetry can be optimized for debugging, aggregation, sampling and retention policies appropriate to the observability system.

Evidence that may later participate in attribution has different requirements.

Distributed tracing already solves an adjacent problem: preserving enough context to correlate work across service boundaries. OpenTelemetry, for example, uses trace and span identities, parent relationships and context propagation to reconstruct related operations across a distributed system.

What I'm exploring here is whether economically meaningful execution facts need a different durability and lifecycle from that operational telemetry.

I may care much more about stable identity. I may care about preserving relationships between records. I may care about knowing when the fact was observed and where it came from.

And for some facts, I may care about retaining the original observation rather than silently replacing it when better information arrives later.

This does not mean every log should become an immutable business record.

That would be the wrong conclusion.

It means the system needs to decide which facts cross that boundary.

High-volume operational telemetry
             │
             │ select economically meaningful facts
             ↓
     Durable execution evidence
             │
             ↓
    Attribution / Reconstruction

The boundary is the interesting part.

Store too little and later analysis becomes guesswork.

Store everything and the evidence layer becomes an expensive copy of the observability stack.

The engineering problem is deciding what deserves to survive.

Retries Make History More Important Than Final State

Retries make this distinction especially visible because they expose the difference between state and history.

At the end of our research workflow, the application may only need to know:

status: COMPLETED
credits_consumed: 10

That is a perfectly useful representation of current state.

But it does not describe how the system reached that state.

The execution history could have been:

Execution exec_42

Attempt 1
    Model inference
    Tool invocation
    Tool timeout
    Result: FAILED

Attempt 2
    Retrieval
    Fallback model inference
    External API
    Tool invocation
    Validation
    Result: SUCCESS

Final commercial state
    10 credits consumed
    Report delivered

Both attempts may have consumed real resources.

Only one produced the final result.

The customer may correctly be charged once.

The commercial state may correctly show one workflow consumption.

Nothing about runtime correctness requires exposing the failed attempt to the customer.

But if I later ask what it cost to produce that report, removing the failed attempt from history would produce an incomplete answer.

This is an important separation:

A failed attempt can be commercially irrelevant while remaining economically relevant.

That does not mean every failure has meaningful cost.

Some fail before any expensive work happens. Some retries are cheap. Some provider operations are not billed when they fail.

The runtime should not manufacture economic significance where none exists.

But when an attempt does consume a measurable resource, the fact that it failed does not make that consumption disappear.

This is one reason I'm becoming increasingly cautious about deriving economic understanding only from final application state.

Final state answers:

Where did the workflow end?

History answers:

What happened on the way there?

For variable-cost execution, those can become very different questions.

But Immutable Doesn't Mean Infallible

Preserving execution history creates another problem.

The information available while a workflow is running is not always the best information the system will ever have.

Suppose exec_42 calls an external provider.

At execution time, the runtime knows that the call happened and can record the measurable usage returned by the provider. But perhaps the exact monetary cost is not available yet. Maybe pricing depends on a rate table maintained elsewhere. Maybe the provider reports final usage asynchronously. Maybe an internal attribution process later discovers that the event was associated with the wrong workflow.

The first record was not necessarily useless.

It represented what the system knew at that point.

But it may need to be corrected.

The obvious implementation is to update the original row:

evidence_id: ev_100
execution_id: exec_42
type: external_api.used
quantity: 1
cost: 0.08

Later:

UPDATE evidence
SET cost = 0.11
WHERE evidence_id = 'ev_100';

The database now contains the latest value.

But something has disappeared.

We no longer know that the system originally believed the cost was 0.08.

That may not matter for every application. For economically meaningful records, however, silently rewriting history can make later reconstruction harder.

An alternative is to preserve the original observation and represent the correction explicitly:

ev_100
execution_id: exec_42
type: external_api.cost
amount: 0.08
status: SUPERSEDED

      ↓ superseded by

ev_143
execution_id: exec_42
type: external_api.cost
amount: 0.11
supersedes: ev_100
status: ACTIVE

Now the current interpretation is still 0.11.

But the system also knows how it got there.

This is the property I care about more than immutability by itself.

The objective is not to pretend that the first observation was perfect.

It is to make corrections visible.

That leads to a useful distinction:

Immutable evidence does not mean immutable interpretation.

New information can arrive. Attribution can improve. A provider can send corrected usage. A bug can be discovered.

The system should be able to incorporate those changes without requiring the historical record to pretend they never happened.

This is also why I would be cautious about describing an append-only evidence layer as a source of "truth."

It can preserve provenance.

It can preserve corrections.

It can make reconstruction more reliable.

It cannot guarantee that every observation entering the system was correct in the first place.

That distinction becomes even more important once we start asking economic questions.

Evidence Still Doesn't Tell Us What Something Cost

There is another boundary that I initially found easy to blur.

Recording resource consumption and determining its monetary value are not necessarily the same operation.

Suppose the runtime preserves this fact:

execution_id: exec_42
attempt_id: attempt_2
provider: model_provider
model: model_b
input_units: 18420
output_units: 2310
observed_at: ...

That is measurement evidence.

It tells us what was consumed.

To answer:

What did this model invocation cost?

we may need additional information.

Observed Usage
      +
Applicable Rate
      ↓
Valuation

The applicable rate may depend on the provider, model, pricing version, contract, timestamp or some other commercial rule.

That means storing:

cost: 0.23

directly on every execution event may be convenient, but it can also collapse two different facts:

What did we observe?

and:

How did we value what we observed?

Keeping those concepts separate can preserve another useful form of lineage.

For example:

Measurement Evidence
input: 18420
output: 2310
      ↓
Rate Policy
model_b / version_7
      ↓
Valuation
amount: 0.23

Now, if a pricing rule changes tomorrow, the original measurement does not have to change.

And if somebody asks why an execution was valued at a particular amount, there is at least a path back to both the observed consumption and the rate used to value it.

Again, this does not mean every AI application needs to build a miniature accounting system.

Depending on the provider and the level of precision a product needs, cost information may already be available directly from provider reporting or existing infrastructure.

In other cases, the product may need to derive valuation from measured usage and the rate that applied when that usage occurred.

The architectural point is narrower:

Measurement, valuation and commercial consumption describe different facts, even when they eventually contribute to the same economic analysis.

For our research workflow, we may now have several related records:

Logical Execution
exec_42
      │
      ├── Commercial Consumption
      │      10 credits
      │
      ├── Attempt 1
      │      ├── Model usage
      │      ├── Tool invocation
      │      └── Failure
      │
      └── Attempt 2
             ├── Model usage
             ├── External API usage
             ├── Tool invocation
             └── Success

Each execution fact can then be connected to whatever valuation information is appropriate.

This is much richer than:

credits_consumed: 10

But notice what it still does not tell us.

It does not tell us whether the workflow was profitable.

It does not tell us whether the customer is healthy.

And it definitely does not tell us why the economics of the product changed.

We have improved the evidence.

We have not yet produced an explanation.

Attribution Is Where the Questions Get Harder

Once execution evidence exists, another deceptively simple question appears:

What does this cost belong to?

Sometimes the answer is obvious.

A model call happens inside attempt_2, which belongs to exec_42, which belongs to one customer workflow.

The relationship can be preserved directly:

Customer
   ↓
Workflow
   ↓
Execution
   ↓
Attempt
   ↓
Model Usage

But real systems do not always stay that clean.

A retrieval service may batch work. A shared cache may serve many customers. A background process may support several executions. An external service may report usage later using its own identifiers.

Infrastructure cost may exist at a level that does not map naturally to one request.

This is where I think it is important not to confuse having evidence with having perfect attribution.

Some costs can be attributed directly.

Some can be attributed later.

Some require an allocation rule.

Some may never be meaningfully attributable at request level.

The system should be able to represent that uncertainty instead of manufacturing precision.

For the parts that can be attributed reliably, preserving relationships early makes later reasoning much easier.

For example:

evidence_id: ev_220
type: external_api.usage
source_ref: provider_event_918

      ↓ attributed to

execution_id: exec_42
attempt_id: attempt_2

The provider event and the attribution are related, but they are not necessarily the same fact.

That matters if the attribution changes later.

Perhaps provider_event_918 was initially associated with exec_42, but a reconciliation process later discovers that it belonged to exec_51.

If the original provider evidence remains intact, the attribution can be corrected without rewriting the source observation itself.

Conceptually:

Source Evidence
provider_event_918
      │
      ├── original attribution → exec_42
      │
      └── corrected attribution → exec_51

This separation starts to create an interesting chain:

Observe
   ↓
Preserve
   ↓
Attribute
   ↓
Value

At each stage, the system adds interpretation.

And at each stage, preserving where that interpretation came from makes the next question easier to investigate.

Evidence Is Not Explanation

At this point it would be tempting to take one more step.

We have execution identity.

We have attempt lineage.

We have resource observations.

We have commercial consumption.

We may have valuation and attribution.

Surely now we can answer:

Why did the economics change?

Not necessarily.

Imagine that the average cost of our research workflow increases by 30% this month.

Execution evidence might reveal several changes:

More retrieval operations
More fallback-model usage
Higher retry frequency
Increased external API usage
Longer model contexts

Those are useful observations.

They may even be strong candidates for explaining the change.

But moving from correlation to explanation requires more care.

Perhaps customers started submitting more complex research tasks. Perhaps a model-routing change altered execution behavior. Perhaps a provider changed pricing. Perhaps the product deliberately introduced a more expensive validation step that significantly improved report quality.

Perhaps several of those things happened at once.

The evidence gives us something much better than a guess.

It gives us a history we can investigate.

But I don't think that justifies jumping directly from:

Metrics changed

to:

Therefore this is why your economics changed.

That shortcut becomes especially tempting when an LLM can inspect a dashboard and generate a plausible explanation.

The explanation may sound convincing.

The harder question is whether the underlying system can show which evidence supports it.

This is where my thinking is still evolving.

The architecture I'm increasingly interested in looks less like:

Metrics
   ↓
LLM
   ↓
Advice

and more like:

Evidence
   ↓
Attribution
   ↓
Explanation

Even that last arrow contains a lot of unresolved questions.

What level of evidence is sufficient? How should conflicting evidence be handled? How much causality can actually be established rather than inferred? How should an explanation communicate uncertainty? Which economic changes can be traced to execution behavior, and which require business context outside the runtime?

I don't think those questions have simple answers.

But I'm becoming more convinced that they are much harder to answer if the execution history was never preserved in the first place.

The Question Arrives After the Request Is Gone

There is a timing problem underneath all of this.

When an AI request is executing, engineering is usually concerned with immediate questions:

Is it authorized?
Is it progressing?
Did the provider respond?
Should we retry?
Did it complete?
Should we consume allowance?

The economic question often arrives much later.

Maybe the workflow takes thirty seconds to complete.

The question about its economics may arrive thirty days later:

Why did this customer's cost-to-serve increase?

Or:

Why did this workflow become more expensive after the last release?

Or simply:

What happened here?

By then, the request is gone.

The worker is gone.

The transient execution context is gone.

Some logs may have expired.

Metrics may have been aggregated.

The provider dashboard may show total consumption without knowing how your application interpreted the work.

At that point, the quality of the answer depends heavily on what the system decided was worth preserving while the execution was still observable.

That is what changed the problem for me.

I started from usage tracking.

Then I started thinking about runtime correctness.

And once commercial consumption became intentionally separate from the complexity underneath it, another requirement appeared:

The runtime may need to preserve enough execution history for economically meaningful behavior to remain reconstructable later.

Not every event.

Not every log.

Not every internal detail.

Enough evidence to connect a commercial operation to the meaningful work that actually occurred.

I'm increasingly thinking of this as an economic observability problem.

Not because observability can tell us whether every execution was good or bad, and not because collecting more telemetry automatically produces economic understanding.

But because before we can ask sophisticated questions about AI economics, we need trustworthy information about what actually happened.

From "What Happened?" to "Why Did It Change?"

This leaves me with a progression that I'm currently investigating:

OBSERVE
   ↓
What happened?

ATTRIBUTE
   ↓
Where did it belong?

EXPLAIN
   ↓
Why did the economics change?

The first question is primarily about evidence.

The second introduces relationships and attribution.

The third is much harder.

And I don't think we should pretend that solving the first two automatically solves the third.

Execution evidence can tell us that retries increased.

Attribution can tell us which workflows incurred the additional work.

Valuation can tell us how much that work contributed to measured cost.

But explaining why the economics changed may require context that does not exist inside the runtime at all: customer behavior, product changes, provider pricing, revenue, retention, quality improvements or strategic decisions.

The runtime sees an important part of the system, not the entire business.

That is why I'm treating the progression toward economic explanation as a research question rather than a solved architecture.

Still, there is an ordering here that increasingly makes sense to me:

Evidence
   ↓
Attribution
   ↓
Explanation

rather than:

Metrics
   ↓
Plausible Explanation

If an explanation eventually influences a recommendation, a simulation or even a runtime decision, being able to trace that explanation back to the underlying evidence seems increasingly important.

But that is further ahead.

The immediate engineering problem is much more concrete.

What should survive the execution?

What Should an AI Runtime Remember?

I don't think the answer is "everything."

The answer probably depends on the product, its cost structure and the questions the team expects to ask later.

But for variable AI workflows, I'm increasingly interested in preserving a small set of relationships:

Logical Execution
      │
      ├── Commercial Context
      │
      ├── Attempt 1
      │      ├── Meaningful Resource Evidence
      │      └── Result
      │
      ├── Attempt 2
      │      ├── Meaningful Resource Evidence
      │      └── Result
      │
      └── Final Outcome

with enough provenance to answer:

What was observed?

During which execution?

During which attempt?

Where did the observation come from?

What commercial operation was it related to?

Was the observation later corrected?

How was measurable consumption eventually valued?

That still does not produce economic truth automatically.

It produces something more modest and, I think, more useful:

a reconstructable history.

Final Thoughts

I started with a fairly simple assumption: if usage was measured correctly, I would have most of the information needed to reason about the economics later.

I don't think that anymore.

Correct usage can tell me that a customer was authorized, that 10 credits were consumed exactly once and that the commercial state remained consistent.

It cannot necessarily tell me what happened underneath that commercial event.

For variable AI execution, that difference matters.

A successful workflow may contain failed attempts. A retry may consume resources without creating another customer charge. A fallback model may change the cost of execution without changing the product outcome. An external provider may report usage after the workflow has already completed.

The final state can be completely correct while much of the economically relevant history has disappeared.

That is why the question I'm increasingly interested in is not simply:

What should we meter?

but:

What facts about an execution should still exist when we need to understand it later?

I don't think the answer is to preserve everything.

It is to preserve enough.

Enough identity to connect work across attempts. Enough provenance to know where an observation came from. Enough history to distinguish what happened from what was later inferred. Enough correction lineage to improve what we know without pretending the original observation never existed.

And enough separation between measurement, valuation and attribution to avoid turning one convenient number into more certainty than the system actually has.

That still doesn't explain why the economics changed.

But perhaps that is exactly the point.

Before a system can explain economic behavior, it needs something trustworthy to reason from.

The progression I'm currently investigating looks increasingly like this:

Evidence
   ↓
Attribution
   ↓
Explanation

There are still difficult questions beyond that last arrow, and I'm not convinced they can all be solved inside the runtime.

But the prerequisite feels much more concrete.

If the execution history disappears, the economic question eventually becomes an inference problem.

If the important facts survive, it becomes an investigation problem.

While building Licenzy, this is one of the assumptions I'm continuing to test as I move from runtime correctness toward economic observability.

An AI execution may last seconds.

The question that matters may arrive weeks later.

By then, your system can only reason from what it chose to remember.

Your AI Product Has Three Different Units. Stop Treating Them as One.

Ciroandrea — Tue, 25 Aug 2026 07:50:27 +0000

AI pricing conversations often begin with the unit.

Should we charge per token?
Per request?
Per generation?
Per workflow?
Should we use credits?
Should customers receive a monthly quota?

These are useful questions.

But they may come too early.

Before deciding which unit should appear in a pricing model, there is a more fundamental distinction worth making:

Should the thing a customer values, the thing a product commercially allocates, and the thing infrastructure actually consumes be represented by the same unit?

For some products, they may align reasonably well.

For others, forcing them into the same abstraction can make both pricing and infrastructure harder to reason about.

Consider an AI research agent.

A customer asks:

Research this company and produce a report.

From the customer's perspective, the interaction is straightforward.

Request
   ↓
Research
   ↓
Completed Report

The customer wants the report.

The product might represent that task commercially as:

1 Report
   ↓
10 Credits

But the infrastructure may experience something very different:

Research Request
       ↓
Context Retrieval
       ↓
Model Call
       ↓
Search
       ↓
Tool Calls
       ↓
External API
       ↓
Model Call
       ↓
Tool Failure
       ↓
Retry
       ↓
Validation
       ↓
Storage
       ↓
Completed Report

One customer-visible outcome.

One commercial deduction.

Many underlying execution events.

All three describe the same product interaction.

But they describe different realities.

That gives us a useful mental model:

Value Unit ≠ Commercial Unit ≠ Economic Unit

Not because these units must always be different.

But because there is no reason to assume they must always be the same.

One Number Is Trying to Do Too Many Jobs

When teams debate pricing units, several concerns often become compressed into one question.

What will customers understand?

What should the product sell?

What should the customer be allowed to consume?

What should the backend meter?

What actually drives infrastructure cost?

What protects margins?

Those questions are related.

They are not identical.

Suppose our research agent exposes its underlying token consumption directly to the customer.

That creates a close relationship between infrastructure consumption and commercial consumption.

For some products, that may be appropriate.

But the customer may not care whether a report required 18,000 or 42,000 tokens.

They care whether the research was useful.

Now suppose the product instead charges ten credits per report.

The customer gets a more predictable commercial abstraction.

But ten credits do not tell the company what producing the report actually cost.

The credit solves one problem.

The execution data solves another.

And the completed report represents something else again: the value the customer came to the product to receive.

Trying to make one unit perfectly represent all three can create unnecessary coupling.

A change in model architecture can change token consumption without changing customer value.

A change in commercial packaging can change how many credits a workflow consumes without changing its infrastructure cost.

A more complex research request can increase execution cost without changing either the customer's visible outcome or the commercial deduction.

The system therefore contains three separate questions:

What does the customer value?
            ↓
What does the product commercially allow?
            ↓
What does execution actually consume?

Understanding the distinction between them makes the rest of the pricing conversation easier to reason about.

Unit #1 — What Does the Customer Think They're Buying?

Start with the customer.

A user rarely opens an AI product because they want to consume tokens.

They usually want something to happen.

Analyze this contract.

Resolve this ticket.

Research this company.

Process this document.

Generate this report.

For our research agent, the customer wants:

1 Completed Research Report

We can think of that as the Value Unit.

The Value Unit describes the thing the customer perceives as useful.

It is not necessarily the unit the company should charge for.

It is not necessarily something that can even be measured precisely.

Its purpose in this framework is simpler:

What is the customer actually trying to get from the product?

For a research agent, a completed report may be a reasonable answer.

For a support automation product, it might be a resolved conversation.

For document processing, it might be a correctly processed document.

But outcome-like units do not work cleanly for every AI product.

A coding assistant may contribute value continuously across dozens of interactions.

A creative tool may support exploration rather than produce one objectively successful outcome.

A conversational assistant may create value throughout a session without any single event representing completion.

So the Value Unit should not automatically become a pricing unit.

And it should not be interpreted as an argument for outcome-based pricing.

It is simply the customer side of the system.

The distinction matters because infrastructure and customers often describe the same product in completely different language.

Infrastructure sees execution.

The customer sees value.

Unit #2 — What Does the Product Commercially Allow?

Now suppose the research agent is sold through a credit-based plan.

The customer receives a monthly allowance.

A completed research workflow consumes:

10 Credits

Those credits are not the research itself.

They are not tokens.

They are not necessarily a direct representation of infrastructure cost.

They are a Commercial Unit.

Commercial Units are abstractions used to translate a commercial agreement into product behavior.

Depending on the product, they might be:

Credits
Runs
Quotas
Included usage
Prepaid balances
Entitlements

Their role is different from the Value Unit.

They can help answer questions such as:

What has the customer purchased?

How much are they allowed to use?

What should happen when the allowance is exhausted?

Which capabilities are currently available?

This is why credits can be useful without needing to represent underlying infrastructure cost exactly.

A credit may provide predictable packaging.

It may create a spending boundary.

It may make allowance easier for customers to understand.

It may give the runtime something concrete to authorize against.

None of that requires one credit to map permanently to a specific number of tokens or a fixed amount of provider spend.

That separation can be valuable because implementation changes.

Models change.

Providers change.

Prompts change.

Workflows change.

If the customer-facing commercial abstraction is tightly coupled to every internal implementation detail, infrastructure changes can leak directly into the pricing experience.

But abstraction does not eliminate economics.

If ten credits allow an execution that consistently costs more than the commercial model can support, calling it ten credits does not make the problem disappear.

The Commercial Unit governs allowance.

It does not, by itself, explain cost-to-serve.

Unit #3 — What Did Execution Actually Consume?

Now look beneath the ten-credit deduction.

The research report may have required:

Context Retrieval
        ↓
Model Inference
        ↓
Search
        ↓
Tool Calls
        ↓
External API
        ↓
Retry
        ↓
Additional Inference
        ↓
Validation
        ↓
Storage

These operations belong to the economic side of execution.

They consume resources.

Some create direct variable costs.

Some use shared infrastructure.

Some occur only on exception paths.

Some may be difficult to attribute precisely to a single workflow.

Together, they help describe the Economic Unit side of the system: what producing the customer-visible result actually consumed.

For the same research report, that may include:

Model and token cost
Retrieval
Tool execution
External API usage
Retries and failed attempts
Compute
Storage
Validation or evaluation overhead

Unlike a credit, there may not be one neat Economic Unit.

The economic layer may be composed of several cost drivers that need to be understood together.

That is especially relevant for AI products because execution paths can vary.

Two requests for the same feature do not necessarily perform the same work.

One report may require a short context, a few searches and a straightforward model path.

Another may require more retrieval, several tools, additional inference and a retry.

The customer may still receive:

1 Research Report

The commercial system may still deduct:

10 Credits

But underneath those two identical abstractions, the execution economics can be different.

And that gives us the first important consequence of separating the three units:

Same Value Unit

1 Research Report
        ↓

Same Commercial Unit

10 Credits
        ↓

Different Economic Reality

Different execution paths
Different resource consumption
Different cost-to-serve

The variance itself is not necessarily a problem.

The problem begins when the business cannot see or explain it.

Same Outcome. Same Credits. Different Economics.

Now we can put the three units together.

Two customers use the same AI research agent. Both ask for a company analysis, both receive a completed research report, and both consume 10 credits from their plan.

From the customer's perspective, the transaction looks identical. From the commercial system's perspective, it is identical too.

The execution paths, however, may tell a different story.

Customer A

Value Unit
1 completed research report

Commercial Unit
10 credits

Execution
├── Short context
├── 2 retrieval operations
├── 2 model calls
├── 1 tool call
├── No retries
└── Validation

Customer B

Value Unit
1 completed research report

Commercial Unit
10 credits

Execution
├── Long context
├── 6 retrieval operations
├── 4 model calls
├── Multiple tool calls
├── 1 external API
├── 1 failed tool call
├── 1 retry
└── Validation

Customer A and Customer B received the same customer-visible unit of value. The commercial system also treated them identically: each workflow consumed 10 credits.

But producing those reports required different amounts of work.

Customer B's report may have consumed more tokens, more retrieval capacity, more third-party services and an additional execution attempt. Depending on the underlying cost structure, the difference in cost-to-serve could be meaningful.

This creates a simple but important relationship:

Same customer value. Same commercial consumption. Different economics.

That does not mean Customer B is a bad customer. Higher execution cost may be perfectly justified by higher revenue, stronger retention, greater strategic value or simply the economics of the plan as a whole.

Nor does it mean every report needs a different credit price. Exposing every variation in infrastructure cost to the customer could make the product unnecessarily difficult to understand.

The problem is not that execution costs vary.

The problem is not understanding that variance.

If the business cannot connect commercial consumption with the execution behind it, several different economic profiles can collapse into the same dashboard number:

Customer A                    Customer B
────────────────────────────────────────────
1 report                      1 report
10 credits                    10 credits
$X cost-to-serve              $Y cost-to-serve
Healthy margin?               Healthy margin?

At small scale, those differences may not matter much. As usage grows and workflows become more complex, however, the distribution can become more important than the average.

A plan may look healthy overall while containing a small set of customers or execution paths with very different economics. Conversely, an expensive customer may still be highly profitable because the commercial relationship more than compensates for the additional cost.

This is why usage volume alone is not enough to describe customer profitability. What matters is the relationship between what the customer pays, what the commercial model allows, and what the runtime actually consumes to deliver the value.

Tokens Are an Infrastructure Unit, Not a Customer Outcome

Token measurement remains essential.

Tokens help engineering teams understand model consumption, compare providers, investigate execution behavior and estimate an important component of variable cost. For some AI products, token consumption may even explain most of the marginal cost of serving a request.

The distinction is not that tokens are the wrong unit. It is that they answer a specific question:

What did model execution consume?

Our research-agent customer is asking a different question:

Did I get the research report I came here for?

And the commercial system may be asking another:

Was this customer allowed to consume the 10 credits required for this workflow?

These three questions can coexist:

Perspective	Question
Infrastructure	What did execution consume?
Commercial	What was the customer allowed to use?
Customer	Did I get what I came here for?

The mistake is not measuring tokens. The mistake is assuming that because tokens are measurable, they must also be the best abstraction for customer value or commercial packaging.

Sometimes they may be.

An API product sold to developers, for example, may have customers who already understand and accept consumption-based infrastructure units. In other products, exposing the implementation directly may create complexity without adding useful information.

The important thing is to make the choice deliberately rather than assuming one unit has to serve every layer.

Why Separating the Units Can Improve Pricing Predictability

Return to the research agent.

The customer wants a report. Internally, producing that report may involve different models, varying context sizes, changing providers, retries, retrieval operations and external tools.

If every internal variation were reflected directly in the customer-facing price, understanding the cost of a report could become difficult.

Imagine a user having to reason about:

Input tokens
+ Output tokens
+ Retrieval operations
+ Tool calls
+ External API usage
+ Retry consumption
+ Model routing
= Final price

For some infrastructure products, that level of granularity is appropriate. For a customer buying a research outcome, it may not be.

A Commercial Unit can create a boundary between those two worlds.

Customer
   ↓
1 Research Report
   ↓
10 Credits
────────────────────
Commercial Boundary
────────────────────
   ↓
Models
Retrieval
Tools
Retries
APIs
Compute
   ↓
Variable Execution Cost

The customer interacts with a relatively stable commercial abstraction. Internally, the company can still observe the more granular economic reality required to understand cost-to-serve.

This separation can also give engineering teams room to change implementation without necessarily changing the customer's mental model every time.

A workflow might move to a different model. Retrieval could become more efficient. A provider could change. A tool could be replaced. An optimization might reduce the number of model calls required to produce the same report.

If the customer continues receiving the same value and the commercial model remains sustainable, those implementation details do not necessarily need to become pricing events.

This leads to a principle I find useful:

Your customer shouldn't need to understand your AI economics. Your runtime does.

But abstraction does not eliminate economic risk.

If the product sells ten credits for an amount that consistently fails to cover the execution they authorize, predictable pricing has simply hidden an unsustainable cost structure.

The business still needs to understand the relationship between its commercial abstraction and the economics underneath it.

So separating the units is not about hiding cost. It is about allowing each layer to use the abstraction appropriate to its responsibility while preserving visibility across the system.

The Three Units Create Three Different Questions

We can now reduce the framework to three layers.

Layer	Unit	Question
Value	Outcome / Job	What does the customer value?
Commercial	Credits / Runs / Quota	What is the customer allowed to consume?
Economic	Execution Costs	What does producing it actually cost?

For our research agent:

VALUE
1 completed research report

        ↓

COMMERCIAL
10 credits

        ↓

ECONOMIC
Models + Retrieval + Tools + APIs
+ Retries + Compute + Storage

These layers influence each other, but they do not need to collapse into a single unit.

The Value Unit helps explain why the product matters to the customer. The Commercial Unit translates the business model into allowance and access. The Economic Unit helps the company understand what fulfilling that allowance actually costs.

A healthy monetization model therefore does not necessarily require finding one perfect unit. It requires understanding the relationship between the units the business chooses to use.

That relationship becomes especially important when execution is variable. If ten credits can authorize workflows with materially different cost-to-serve, the commercial abstraction may remain perfectly useful — but the infrastructure needs enough visibility to understand what is happening underneath it.

And at that point, what initially looked like a pricing problem starts becoming an architecture problem.

This Becomes a Runtime Problem

Once Value Units, Commercial Units and Economic Units are separated, a new responsibility appears.

Something still has to connect them.

For our research agent, the commercial system may know that the customer has enough allowance for another report. The customer may understand that the report consumes 10 credits. The execution layer, meanwhile, is about to trigger models, retrieval, tools and external services whose actual cost is not yet fully known.

Those realities meet at runtime.

A simplified lifecycle might look like this:

Payment
   ↓
Commercial State
   ↓
Entitlement / Allowance
   ↓
Authorization
   ↓
Execution
   ↓
Metering
   ↓
Cost Attribution
   ↓
Outcome
   ↓
Economics

Each stage answers a different question.

Payment establishes a commercial event. Commercial state represents what the customer has purchased. Entitlements and allowances describe what the product should make available. Authorization determines whether a particular operation should proceed.

Execution then creates the actual workload.

Metering records what happened. Cost attribution attempts to connect meaningful execution costs back to customers and workflows. Outcome information provides context about what the execution produced. Only after connecting these layers can the business begin reasoning about the resulting economics.

This is why billing infrastructure and runtime infrastructure have different responsibilities.

A payment provider does not need to understand every model call, retry or tool execution inside the research agent. That is not the responsibility of payment infrastructure.

Similarly, knowing that a customer successfully paid does not tell the application whether every future execution should be allowed.

A useful distinction is:

Billing records commercial events. A monetization runtime governs what should happen during execution.

The two layers complement each other.

Suppose our customer purchases a plan containing 100 credits.

The payment event establishes the commercial relationship. But when the customer requests a research report three weeks later, the runtime may still need to determine whether the account is active, whether sufficient allowance remains, whether the requested capability is available and whether consumption can be applied correctly.

Payment says:

"Commercial event completed."

Runtime asks:

"Given the current commercial state,
should this execution happen now?"

That distinction becomes more important when execution itself has meaningful variable cost.

Once authorization allows the workflow to proceed, the business begins consuming resources. A decision that looks like access control at the application layer can therefore also determine whether the company incurs model, tool and infrastructure costs.

But authorization is only the beginning.

The system also needs trustworthy information about what happened after execution was allowed.

If usage is recorded incorrectly, retries consume allowance twice, concurrent requests overspend the same balance or failed executions disappear from the data, later economic analysis inherits those inconsistencies.

Before asking whether usage was profitable, we first need confidence that usage was correct.

From Correct Usage to Profitable Usage

There is a useful progression here:

Payment ≠ Access
       ↓
Access ≠ Correct Usage
       ↓
Correct Usage ≠ Profitable Usage

Each step introduces a different problem.

Payment ≠ Access

A successful payment is an event.

Product access is an ongoing state.

A customer may upgrade, downgrade, cancel, receive additional allowance or lose access to a capability. Payment information therefore needs to become reliable application state before the runtime can make execution decisions from it.

The important question is no longer only:

Did the customer pay?

It also becomes:

Given the customer's current commercial state, should this operation be available now?

This is where commercial state, entitlements and runtime authorization begin to matter.

Access ≠ Correct Usage

Now suppose the customer is correctly authorized to run the research workflow.

That still does not guarantee that consumption will remain correct during execution.

Two requests might arrive concurrently. A network timeout might cause a retry. A client might resend the same operation. A worker may complete successfully while the caller believes the request failed.

The customer was allowed to execute.

The harder question becomes whether the system preserves the intended commercial semantics while those distributed-system behaviours occur.

For example:

Customer has 10 credits
        ↓
Workflow costs 10 credits
        ↓
Two concurrent requests arrive
        ↓
Both observe the same balance
        ↓
What happens?

This is no longer simply a pricing question.

It is an engineering correctness problem involving concepts such as atomic consumption, idempotency, concurrency control, reconciliation and retry-safe execution.

The objective is to make the commercial abstraction trustworthy even when the underlying system is distributed and imperfect.

Correct Usage ≠ Profitable Usage

Now assume the system handles all of that correctly.

The customer is entitled to execute.

Authorization succeeds.

Ten credits are consumed exactly once.

Retries preserve the intended usage semantics.

Metering accurately describes what happened.

The research report is successfully delivered.

From a runtime-correctness perspective, the system behaved exactly as intended.

But return to our two customers:

Customer A

1 report
10 credits
Simple execution path
Lower cost-to-serve

Customer B

1 report
10 credits
Complex execution path
Higher cost-to-serve

Both executions can be commercially correct.

Both can be operationally correct.

Both can produce exactly the value the customer expected.

Their economics can still differ.

This is the third layer of the problem.

Correct usage tells us whether the commercial rules were executed reliably. It does not automatically tell us whether those rules produced healthy economics.

One useful way to reason about this distinction is:

Commercial Correctness
        ↓
Was the customer's commercial state represented correctly?

Runtime Correctness
        ↓
Was execution authorized, consumed and recorded correctly?

Economic Understanding
        ↓
What economics did that correct execution produce?

The final step should be treated carefully.

It does not imply that every request needs a real-time profitability calculation before it executes. Nor does it mean that an expensive workflow should automatically be blocked.

Some high-cost workflows produce substantial customer value. Some customers justify lower margins. Some execution costs can only be understood after the workflow completes. Some forms of value cannot be attributed cleanly to a single request at all.

The important point is narrower:

An execution can be correctly authorized, correctly consumed and correctly charged while still producing economics the business may want to understand.

That is where the relationship between our three units becomes especially useful.

The Value Unit tells us what the customer received.

The Commercial Unit tells us what allowance was consumed.

The Economic Unit tells us what producing that result required.

None of those facts alone is enough to describe the whole system.

What This Means for AI Builders

This framework does not produce a universal pricing model.

It does not tell every AI company to sell outcomes. It does not tell teams to replace credits with usage-based billing, or usage-based billing with subscriptions. It does not tell developers to expose infrastructure costs directly to customers.

Instead, it suggests a set of questions worth answering before choosing the abstraction.

What does the customer actually perceive as value?

For the research agent, that may be a completed report. For another product, value may be continuous, exploratory or difficult to reduce to one event.

The goal is to understand the customer's mental model before deciding whether an infrastructure unit should become a pricing unit.

What unit makes commercial allowance understandable?

Credits, runs, quotas or included usage can provide useful commercial boundaries.

The right abstraction depends on the product, the customer and the variability of the underlying execution.

The question is not whether credits are inherently good or bad. It is what responsibility they are supposed to serve.

What does execution really consume?

Which costs materially affect the economics of delivering the product?

For some systems, inference may dominate. For others, retrieval, tools, third-party APIs, retries, storage or human intervention may materially change cost-to-serve.

Not every cost needs perfect request-level attribution. The objective is enough visibility to explain economically meaningful variance.

How variable is cost-to-serve?

Can two customers consume the same Commercial Unit while generating very different execution costs?

If so, how frequently does that happen, how large is the variance, and does the broader commercial relationship compensate for it?

Which variance should the customer see?

Some infrastructure variability may belong in customer pricing.

Some may be better absorbed by the product.

A provider change, retry or internal routing decision does not automatically need to become a new concept the customer has to understand.

Which complexity should infrastructure absorb?

Every abstraction moves complexity somewhere.

A simple customer-facing pricing model can require more sophisticated internal measurement. A highly granular usage model can expose more infrastructure economics directly to the customer.

Neither approach is automatically correct.

The important thing is knowing where the complexity lives.

These questions lead to a different way of approaching AI monetization.

Instead of beginning with:

What is the perfect unit to charge for?

begin with:

Which unit describes customer value, which unit governs the commercial relationship, and which units describe the economics of execution?

Only then decide where those units should align — and where they should remain separate.

Closing — Three Units, One Economic System

Return to the research agent one last time.

The customer asks for a company analysis and receives:

1 Completed Research Report

That is the unit closest to the value they came to the product to receive.

The commercial system deducts:

10 Credits

That is the abstraction the product uses to represent allowance.

Underneath both, the runtime executes:

Retrieval
   ↓
Model Inference
   ↓
Search
   ↓
Tool Calls
   ↓
External API
   ↓
Retry
   ↓
Additional Inference
   ↓
Validation
   ↓
Storage

Those operations describe the economic reality of producing the result.

Three perspectives on the same interaction:

VALUE UNIT

What the customer values
1 Research Report

        ↓

COMMERCIAL UNIT

What the product allocates
10 Credits

        ↓

ECONOMIC UNIT

What execution consumes
Models + Tools + APIs + Retries + Infrastructure

The important insight is not that these units should always be different.

Sometimes they may align naturally.

A developer-facing API may expose consumption in a way customers already understand. A predictable workflow may have sufficiently stable execution costs that its Value Unit and Commercial Unit can closely correspond. Another product may deliberately expose infrastructure consumption because that transparency is useful to its customers.

The point is that alignment should be a design decision, not an assumption.

What the customer values, what the product sells or allocates, and what the infrastructure consumes are related — but they are not necessarily the same unit.

Once those units are separated conceptually, a different architecture becomes easier to reason about.

The customer does not necessarily need to understand every model call, retry, retrieval operation or provider cost.

The Commercial Unit can provide an understandable boundary.

The runtime can preserve that boundary during authorization and consumption.

And the economic layer can observe what fulfilling that commercial promise actually required.

Customer Value
      ↕
Commercial Model
      ↕
Runtime Execution
      ↕
Economic Reality

The challenge is not making every layer identical.

The challenge is maintaining a trustworthy relationship between them.

If the commercial layer says the customer has 10 credits, the runtime should be able to enforce that state correctly.

If the runtime records a workflow, the resulting usage data should describe what actually happened.

If the business later analyzes cost-to-serve, that analysis should be built on execution data it can trust.

This is where the distinction between monetization and billing becomes useful.

Billing establishes and records commercial events.

Runtime infrastructure has to carry those commercial decisions into the actual execution of the product.

And as AI execution becomes more variable, trusted runtime data can provide the foundation for understanding what those decisions eventually mean economically.

That progression can be summarized as:

Payment
   ↓
Commercial Correctness
   ↓
Runtime Correctness
   ↓
Economic Observability
   ↓
Economic Understanding

Each layer depends on the reliability of the one beneath it.

There is little value in sophisticated profitability analysis if the underlying usage data is wrong. There is little value in correct usage accounting if execution ignores the customer's commercial state. And a successful payment alone cannot guarantee either of those properties.

This is also the broader problem I'm currently investigating while building Licenzy.

Licenzy is being developed as an AI Monetization Runtime, focused on maintaining correctness between commercial state and runtime execution after payment.

That foundation is primarily about questions such as whether execution is authorized, whether allowance is consumed correctly and whether runtime behavior remains consistent with the commercial state of the customer.

Beyond that foundation, Runtime Intelligence / ProfitLens represents an evolving direction we're exploring: connecting trusted execution data with deeper visibility into customer, workflow and economic behavior.

The distinction matters.

Reliable execution is something infrastructure can enforce.

Economic understanding is more contextual.

A system should not pretend that every expensive workflow is unhealthy, that every low-margin customer should be blocked or that profitability can always be calculated perfectly at request level.

Those conclusions depend on information that may exist outside the runtime: revenue, retention, strategic value, customer behavior, product outcomes and costs that are difficult to attribute precisely.

So the immediate opportunity is not autonomous economic optimization.

It is better economic visibility built on trustworthy execution data.

And that brings us back to the three units.

VALUE UNIT
What does the customer value?

COMMERCIAL UNIT
What does the product allow?

ECONOMIC UNIT
What does producing it actually consume?

For some AI products, the three may remain relatively close.

For others, they may diverge significantly.

Neither situation is inherently wrong.

The important question is whether the business understands the relationship between them well enough to design its pricing, infrastructure and product deliberately.

Because the challenge ahead may not be finding one perfect unit for AI monetization.

It may be learning how to operate a product where several different units can all be correct at the same time.

And that leaves a broader question worth investigating:

How do you build and monetize software when every customer, every workflow, and even two executions of the same workflow can have different economics?

Before choosing your next pricing unit, there may be an even simpler question to ask:

Am I designing my AI product as if Value, Commercial and Economic Units were the same thing?

The Real Cost of an AI Workflow Is More Than the Model Call

Ciroandrea — Mon, 17 Aug 2026 08:00:00 +0000

A customer asks an AI agent to complete a task.

From the outside, the interaction looks simple:

User Request
     ↓
     AI
     ↓
Successful Result

One request went in.

One result came out.

If the model call cost $0.20, it is tempting to think of $0.20 as the cost of serving that request.

But production AI systems rarely behave like a single API call.

Look inside the same workflow and the execution may have looked more like this:

User Request
     ↓
Context Retrieval
     ↓
Model Call
     ↓
Tool Call
     ↓
Tool Failure
     ↓
Retry
     ↓
Second Model Call
     ↓
External API
     ↓
Validation
     ↓
Successful Outcome

The customer still experienced one task.

The infrastructure experienced an execution graph.

Retrieval consumed resources.

The first model call consumed tokens.

The failed tool call may have incurred cost.

The retry required additional execution.

A second model call consumed more tokens.

The external API may have charged for usage.

Validation required additional processing.

And only then did the customer receive the result.

Nothing about this makes the workflow inefficient by definition.

The retry may have been necessary.

The external service may have been essential.

The second model call may have materially improved the result.

But it reveals an important distinction.

The price of the successful model call and the cost of producing the successful outcome are not necessarily the same thing.

That difference becomes increasingly important as AI products move from simple model interactions to production workflows.

The Model Call Is the Easiest Cost to See

AI teams naturally pay close attention to model costs.

They monitor:

Input tokens
Output tokens
Cached tokens
Inference costs
Provider pricing
Cost per request

They should.

These metrics provide essential visibility into one of the largest variable cost components of many AI products.

They help teams compare models, detect unusual consumption, estimate infrastructure spend and understand how changes in prompts or context affect cost.

Token visibility is not becoming obsolete.

Model cost is not becoming irrelevant.

The limitation is simply that these metrics answer a specific question:

What did the model execution cost?

That may not be the same question as:

What did it cost to produce the customer outcome?

Consider an agent workflow that uses $0.30 of inference.

If that inference is the only meaningful variable-cost operation required to complete the task, then model cost may be an excellent approximation of execution cost.

But suppose the same $0.30 model call exists inside a workflow that also requires retrieval, two paid external APIs, a failed tool execution and a retry.

The model price has not changed.

The economics of the workflow have.

This distinction matters because optimizing the visible component does not necessarily optimize the entire execution.

Reducing inference cost by 20% may be valuable.

But if repeated tool failures are responsible for most of the workflow's unnecessary spending, changing models may have relatively little impact on the economics of the completed task.

The model bill tells you something important.

It just doesn't always tell you the whole story.

A Production AI Request Is Usually a Workflow

The simplest mental model for an AI product is:

Request
   ↓
Model
   ↓
Response

For some products, that remains reasonably accurate.

For many others, production execution increasingly looks more like a graph:

Input
   ↓
Retrieval
   ↓
Reasoning
   ↓
Tool Selection
   ↓
External Service
   ↓
Validation
   ↓
Potential Retry
   ↓
Outcome

An AI support system may retrieve account context before generating an answer.

A document-processing workflow may extract data, classify it, validate the result and send uncertain cases for review.

A research agent may perform searches, retrieve documents, invoke several tools and make multiple model calls before producing its final report.

A voice application may combine transcription, inference, synthesis and external services within a single customer interaction.

The user experiences a feature.

The infrastructure executes a workflow.

That difference changes how cost can be understood.

At the infrastructure level, individual operations still matter.

Teams still need to know what each model, API and service costs.

But when those operations exist primarily to produce a single customer-visible result, another economic unit becomes useful:

the workflow itself.

Instead of looking only at:

Model Call A      $0.12
Model Call B      $0.08
External API      $0.04

we can also ask:

Workflow
   ↓
All meaningful execution required
to produce the outcome
   ↓
Total economic cost

This does not mean every infrastructure expense can or should be attributed perfectly to an individual workflow.

Shared compute complicates attribution.

Caches serve multiple executions.

Some APIs are purchased in bundles.

Background jobs may support several customers.

Storage costs accumulate over time.

Human intervention can be especially difficult to allocate precisely.

Economic attribution is inherently imperfect.

The goal is not accounting precision at arbitrary granularity.

The goal is enough visibility to understand where meaningful costs originate.

Because once an AI request becomes a workflow, optimizing only the most visible operation can leave much of its economics unexplained.

Failures Still Cost Money

In traditional application monitoring, a failed request is usually represented as an operational event.

Something went wrong.

The request failed.

The system may retry it.

Eventually, the operation either succeeds or surfaces an error.

AI workflows add another dimension to that sequence.

Work may already have been paid for before the failure occurred.

Consider a simplified execution:

Attempt #1

Model inference        $0.14
Tool call              $0.05
Result                  Failure

          ↓

        Retry

          ↓

Attempt #2

Model inference        $0.16
External API           $0.07
Result                  Success

From the customer's perspective, one task was completed.

From the runtime perspective, two attempts occurred.

From an economic perspective, both attempts mattered.

The failed model call still consumed tokens.

The failed tool operation may still have generated a charge.

The successful attempt then required additional resources before the customer received the outcome.

If we measure only the final successful execution, part of the cost disappears from the economic picture.

This is one reason failure economics can matter in AI systems.

A failed execution does not necessarily produce zero value.

It may provide information used by the next attempt.

It may be an expected part of a resilient workflow.

And retries themselves are not inherently wasteful.

Retries exist because distributed systems fail.

Networks time out.

Providers become temporarily unavailable.

External services return transient errors.

Long-running workflows encounter conditions that cannot always be predicted in advance.

Removing retries simply to reduce cost would often make the system less reliable.

The more useful distinction is between resilience cost and execution waste.

A retry that recovers a valuable customer workflow may be economically justified.

A loop that repeatedly performs the same expensive operation because the underlying failure cannot recover is something very different.

Both appear as retries.

Their economics are not the same.

This means retry rate alone is not enough.

Teams may eventually need enough context to understand questions such as:

Which workflows generate repeated attempts?
Where in the execution path do failures occur?
How much work happens before failure?
Which retries eventually produce useful outcomes?
Which failure patterns repeatedly consume resources without changing the result?

The goal is not to eliminate failed execution.

That is unrealistic.

The goal is to understand the economic consequences of failure well enough to distinguish useful resilience from repeated spending that produces little additional value.

A failed AI execution can still have a cost even when it never produces a customer-visible outcome.

Tool Calls Change the Cost Model

This becomes even more important as AI products move beyond model-only execution.

An agent may decide to search the web.

Query a database.

Call an enrichment provider.

Execute code.

Store a generated asset.

Send a message through a communication API.

Invoke another model.

Each operation expands what the workflow can accomplish.

It can also expand its cost surface.

Consider a research workflow:

User Request
     ↓
Model
     ↓
Search
     ↓
Retrieval
     ↓
Model
     ↓
External Data API
     ↓
Validation
     ↓
Final Response

The model calls may still represent the largest variable expense.

But they are no longer necessarily the only meaningful expense.

Suppose the model portion costs:

$0.35

The workflow may also generate:

Search / retrieval       $0.06
External data API        $0.18
Validation               $0.04
Storage                  $0.02

The exact numbers are not important.

The structure is.

Looking only at inference would describe one component of the execution while leaving the rest outside the analysis.

In that sense:

Model Cost
     ≠
Complete Workflow Cost

But even that distinction needs qualification.

Workflow cost is not always something that can be calculated by simply adding every infrastructure event together.

Production systems contain shared resources.

A retrieval result may be cached and reused across customers.

A database cluster supports thousands of workflows simultaneously.

An external API may charge through a monthly commitment rather than per request.

Background processing may serve multiple execution paths.

Storage costs may persist long after a workflow completes.

Some infrastructure costs are marginal.

Others are allocated.

Others are effectively fixed within a certain capacity range.

Trying to attribute every cent precisely can create more complexity than useful insight.

The objective is therefore not:

Calculate the exact accounting cost of every workflow.

A more practical objective is:

Understand which execution components materially change the economics of the workflows you care about.

For one product, that may primarily be model inference.

For another, external APIs may dominate.

For an agentic product, tool loops and repeated model calls may matter more.

For document processing, human review may be the expensive exception path.

For voice AI, several services may contribute materially to a single interaction.

The relevant cost model depends on the architecture.

What matters is recognizing that once AI execution becomes a multi-step workflow, the provider's model bill is no longer guaranteed to describe the complete economic behaviour of the product.

It describes one important layer.

The workflow provides the context around it.

The Customer Doesn't Buy Tokens

Infrastructure teams naturally think in infrastructure units.

Tokens.

Requests.

GPU time.

API calls.

Compute.

These units matter because they describe what the system consumes.

But they are rarely what the customer is actually trying to buy.

A customer using an AI support product wants a ticket resolved.

A customer using document automation wants a document processed correctly.

A sales team may want a qualified lead.

A research user may want a completed analysis.

A creative tool may exist to produce a usable asset.

The customer experiences the outcome.

The company pays for the execution required to produce it.

That creates an important bridge between infrastructure economics and customer value.

Consider a support automation system.

Suppose it processes 1,000 conversations during a given period.

Its model bill is:

Model inference: $300

That number is useful.

Now suppose the complete workflows also involve retrieval, external services and retries:

Model inference        $300
Retrieval               $40
External services       $85
Retry execution         $35
                         ───
Observed workflow cost  $460

The workflow-level view provides additional context.

But there is still another question.

What did that $460 produce?

Suppose 700 conversations were resolved successfully without human escalation.

For this particular product, one potentially useful lens becomes:

Observed workflow cost
          ↓
Successful resolutions
          ↓
Cost per useful outcome

In this simplified example:

$460
 ÷
700 resolved conversations
 =
$0.66 per resolved conversation

That number does not replace token cost.

It answers a different question.

Token cost helps explain the economics of inference.

Workflow cost helps explain the economics of execution.

Cost per useful outcome can help connect that execution to something closer to customer value.

For some AI products, that connection can be extremely useful.

For others, it may be difficult or even misleading.

What is the "useful outcome" of an AI coding assistant?

A generated function?

An accepted suggestion?

A merged pull request?

Developer time saved?

What is the useful outcome of a research assistant?

A completed report?

A correct decision?

Knowledge acquired by the user?

Not every product produces discrete outcomes that can be measured cleanly.

And even when an outcome can be identified, assigning business value to it may remain difficult.

So cost per useful outcome should not be treated as a universal AI metric.

It is better understood as an economic lens.

Where outcomes can be meaningfully defined, it can help teams move from:

What did the infrastructure consume?

toward:

What did we spend to produce something the customer actually valued?

That is a different level of understanding.

From Cost per Call to Cost per Workflow

There are several ways to observe the economics of the same AI system.

None needs to replace the others.

They answer different questions.

Infrastructure View	Workflow View	Economic View
Model calls	Total execution path	Useful outcome
Tokens	Retries and failures	Cost to produce outcome
Inference	Tool execution	Revenue relationship
API calls	External services	Resulting margin
Compute	Operational overhead	Business value

The infrastructure view asks:

What resources did the system consume?

The workflow view asks:

What did the complete execution require?

The economic view asks:

What did that execution produce, and was the relationship between cost and value healthy?

All three matter.

Without infrastructure visibility, teams cannot understand the underlying cost drivers.

Without workflow context, they may struggle to explain why apparently similar requests have very different costs.

Without economic context, they may know exactly what was consumed without knowing whether that consumption was healthy for the business.

The progression might look like this:

Model Events
     ↓
Execution Events
     ↓
Workflow
     ↓
Outcome
     ↓
Economic Context

This is not a maturity model.

A company does not necessarily need every layer of attribution.

A simple AI feature may be understood perfectly well through provider costs and aggregate margins.

Adding workflow-level instrumentation where it produces no useful decision would only create additional complexity.

The level of visibility should follow the economic questions the business actually needs to answer.

But as workflows become more complex, aggregate infrastructure metrics can become less explanatory.

A $0.10 model call inside a successful one-step workflow and the same $0.10 model call inside a five-attempt workflow are technically the same model expense.

They exist inside very different execution economics.

The objective is therefore not to move away from cost-per-call metrics.

It is to preserve them while adding enough context to understand the system around them.

Two Identical Customers Can Have Completely Different Economics

Workflow variance eventually appears at the customer level.

Consider two customers paying the same subscription price.

From the commercial system, they may look almost identical.

Customer A          Customer B

Plan: Pro           Plan: Pro
Revenue: $200       Revenue: $200
Status: Active      Status: Active

Now look at how they actually use the product.

Customer A

Clean inputs
Short context
Standard execution path
Few retries
Predictable tool usage

Customer B

Messy inputs
Long context
Exception-heavy execution
Multiple retries
Expensive tool usage

The product may expose the same features to both.

Their visible usage may even appear broadly similar.

Their cost-to-serve can still be very different.

This is where workflow economics and customer profitability begin to intersect.

A customer who frequently triggers expensive execution paths may produce lower margins than another customer on the same plan.

But high cost does not automatically mean a bad customer.

A power user may also:

Generate more revenue
Purchase additional capacity
Retain for longer
Create strategically valuable usage
Produce high-value outcomes
Justify the infrastructure they consume

Similarly, a relatively low-usage customer may still be economically unattractive because of support overhead, pricing structure or other costs.

The relevant question is not:

Who uses the most AI?

It is:

What is the economic relationship between what a customer pays, how they use the product and what it costs to serve them?

That relationship is difficult to understand from subscription revenue alone.

It is also difficult to understand from token consumption alone.

The missing context often lives inside the workflows connecting the two.

This is why averages can hide important differences.

Two customers can generate the same revenue.

Two requests can consume the same number of tokens.

Two workflows can produce the same visible outcome.

And yet the economics underneath them can be materially different.

The problem is not necessarily the expensive customer, the expensive workflow or the expensive model.

The problem is making business decisions without being able to see those differences.

Measuring Usage Is Not the Same as Understanding Economics

Reliable usage data is foundational.

A production system should be able to answer questions such as:

What executed?
How much was consumed?
When did consumption occur?
Which customer initiated it?
Was the operation recorded correctly?

If those answers are unreliable, any economic analysis built on top of them becomes unreliable too.

Suppose a retry is counted twice when it should have been counted once.

Or an execution occurs but never reaches the usage ledger.

Or consumption is attributed to the wrong customer.

Or a stale entitlement allows execution under commercial conditions that are no longer valid.

The resulting profitability analysis may look precise.

The underlying data is not.

This is why runtime correctness comes first.

Authorization needs to be trustworthy.

Consumption needs to be recorded correctly.

Retries need to preserve the intended semantics.

Commercial and application state need to remain aligned.

Usage accounting needs to describe what actually happened.

Only then can the business begin asking economic questions with confidence.

But correct metering still answers only part of the problem.

Imagine the runtime reports:

Customer:      A
Execution:     8f21
Model calls:   3
Tokens:        48,200
Tool calls:    4
Retries:       1
Usage:         Recorded correctly

That is valuable operational information.

It still does not necessarily tell us:

Which workflow was this?

Why did it require three model calls?

Which tool caused the retry?

What did the complete execution cost?

Did it produce a useful outcome?

What was the commercial relationship with the customer?

Was the resulting cost-to-serve economically healthy?

The usage data may be completely correct.

The economic picture may still be incomplete.

That distinction matters.

Runtime Correctness helps establish that execution and consumption happened according to the system's rules.

Economic understanding requires connecting those trusted events to additional context.

Trusted Runtime Events
          +
Workflow Context
          +
Cost Context
          +
Outcome Context
          +
Commercial Context
          ↓
Economic Understanding

Correct runtime data does not automatically produce correct economic conclusions.

But without correct runtime data, trustworthy economic conclusions become much harder to produce.

Visibility Comes Before Optimization

Once teams begin seeing workflow-level cost differences, optimization becomes tempting.

Use a cheaper model.

Reduce context.

Change retry policies.

Introduce stricter limits.

Modify packaging.

Adjust pricing.

Route certain workflows differently.

Some of those decisions may eventually be appropriate.

But optimization should not be the first step.

Understanding should.

Consider a workflow whose average execution cost suddenly increases.

A team looking only at provider spend might conclude that the model has become too expensive.

But the underlying cause could be very different.

Perhaps retrieval started returning substantially more context.

Perhaps a tool integration began timing out.

Perhaps a new customer segment naturally requires more complex workflows.

Perhaps an external API changed its pricing.

Perhaps retry frequency increased after a deployment.

Or perhaps customers are simply completing more high-value tasks.

Each situation could produce higher infrastructure spending.

They do not imply the same response.

Higher Cost
    ↓
Could Mean
    ↓
More Valuable Usage
Workflow Inefficiency
Failure Overhead
Customer Mix Change
Pricing Misalignment
Architecture Change

Cost is a signal.

Context gives the signal meaning.

Before attempting to optimize economics, teams need enough visibility to trace meaningful cost back through the system:

Where did the cost originate?
          ↓
Which workflow created it?
          ↓
Which customer triggered it?
          ↓
What happened during execution?
          ↓
Did the workflow produce a useful outcome?
          ↓
What economics resulted?

Again, the objective is not perfect attribution.

A company may never know the exact economic value of every execution.

It may not need to.

The objective is enough visibility to make better decisions.

Once that visibility exists, teams can reason more deliberately about:

Architecture
Model selection
Retry behaviour
Usage limits
Packaging
Pricing
Workflow design

Without attribution, optimization risks solving the wrong problem.

A cheaper model does not fix an expensive retry loop.

A higher subscription price does not fix unnecessary tool execution.

A stricter usage limit may damage a high-value workflow whose cost is perfectly justified.

And reducing infrastructure spending is not automatically an improvement if it also reduces the value customers receive.

The goal is not minimum cost.

The goal is healthier economics.

Optimization without attribution is guesswork.

From Runtime Events to Runtime Intelligence

Production AI systems already generate much of the information needed to understand their behaviour.

The difficulty is that this information often lives in separate systems.

Payment infrastructure understands commercial state.

Authorization infrastructure knows whether execution was permitted.

AI providers expose model consumption.

Application telemetry describes execution behaviour.

Metering systems record usage.

Observability systems capture failures and retries.

Product systems may know whether a workflow completed successfully.

Finance sees revenue and aggregate spending.

Each system answers part of the question.

The economic picture emerges when those signals can be connected.

One way to think about the architecture is:

Commercial State
        ↓
Runtime Authorization
        ↓
Execution
        ↓
Cost Events
        ↓
Workflow
        ↓
Outcome
        ↓
Economics

The first layers tell us whether execution should happen and what actually happened.

The later layers help explain what that execution meant economically.

This creates an interesting infrastructure problem.

AI systems are producing enough runtime information to reason about more than consumption alone.

The challenge becomes connecting:

Commercial State
        +
Runtime Execution
        +
Economic Context

We can describe this longer-term architectural direction as Runtime Intelligence.

Not as an established market category.

And not as a claim that infrastructure can automatically determine the correct economic decision for every request.

Many decisions remain contextual.

Some outcomes cannot be valued precisely.

Some customers are intentionally served at lower margins.

Some workflows create strategic value that cannot be captured by immediate revenue.

And some economic signals only become visible after execution has completed.

Runtime Intelligence is therefore better understood as a visibility problem before it becomes an optimization problem.

The objective is to connect trusted runtime events with enough commercial and economic context to help teams understand questions such as:

What happened?

For which customer?

Inside which workflow?

Through which execution path?

At what meaningful cost?

Did it produce the intended outcome?

What economics resulted?

That information does not make the decision automatically.

It makes a better decision possible.

And that may become increasingly important as AI products move from simple model calls toward complex, variable-cost execution graphs.

Closing — What Did This Workflow Actually Cost?

Return to the workflow from the beginning.

From the customer's perspective, it looked like this:

User Request
     ↓
     AI
     ↓
Successful Result

One request.

One result.

A simple interaction.

But inside the infrastructure, producing that result may have required:

User Request
     ↓
Context Retrieval
     ↓
Model Call
     ↓
Tool Call
     ↓
Tool Failure
     ↓
Retry
     ↓
Second Model Call
     ↓
External API
     ↓
Validation
     ↓
Successful Outcome

Every meaningful operation along that path contributed to the execution.

Some generated direct variable costs.

Some consumed shared infrastructure.

Some existed because failure is unavoidable in production systems.

Some may have been necessary to make the result useful.

Others may have added cost without adding meaningful customer value.

The final model response was only the visible end of that process.

This is why the easiest AI cost to measure may not always be the most useful economic unit to understand.

Model pricing remains important.

Token visibility remains important.

Inference optimization remains important.

But they describe one layer of a larger system.

A model call has a price.

A workflow has an economic cost.

A useful outcome has business value.

The interesting part of AI economics exists in the relationship between the three.

Model Call
    ↓
Price

Workflow
    ↓
Execution Cost

Useful Outcome
    ↓
Business Value

Understanding that relationship does not require perfect attribution.

It does not require assigning a precise financial value to every customer interaction.

And it does not mean every expensive workflow should become cheaper.

Sometimes expensive execution produces disproportionately valuable outcomes.

Sometimes retries are the correct price of reliability.

Sometimes a high-cost customer is also one of the healthiest customers in the business.

The objective is not to minimize execution cost at all costs.

It is to understand what the business is spending, why it is spending it, and what that spending produces.

That understanding begins with reliable runtime data.

If authorization is incorrect, usage is incomplete, retries are miscounted or execution events cannot be trusted, the economic conclusions built on top of them cannot be trusted either.

Runtime Correctness therefore remains the foundation.

The next challenge is connecting that foundation to the economics it produces.

That is the direction I'm currently exploring with Licenzy.

Licenzy is being developed around reliable AI Monetization Runtime infrastructure: keeping commercial state and AI execution correctly aligned.

Runtime Intelligence represents the evolving direction beyond that foundation — exploring how trusted runtime events can be connected with workflow, customer and economic context.

That direction is still being explored.

It is not an argument that infrastructure should automatically decide what is profitable, or that every economic decision belongs inside the runtime.

The more immediate goal is simpler:

Make the economics of execution easier to understand.

Because as AI products become more complex, knowing what the model costs is only part of the picture.

The broader questions are:

What did this workflow actually cost — and was the outcome worth it?

And eventually:

Is my AI business actually healthy — and why?

Your AI Execution Can Be Correct — and Still Lose Money

Ciroandrea — Mon, 10 Aug 2026 08:54:00 +0000

Everything Worked

Imagine a customer triggers an AI workflow in production.

The request reaches the authorization layer.

The customer has an active entitlement.

There is enough usage capacity available.

Authorization succeeds.

The workflow starts.

It retrieves the required context, calls the model, executes an external tool and produces the expected result.

Usage is recorded correctly.

The customer's balance is updated.

The result is delivered.

Observability shows green.

No exception was raised.

No duplicate execution occurred.

No usage event was lost.

No reconciliation issue appeared later.

From an engineering perspective, the system behaved exactly as designed.

Everything worked.

Now look at the same execution from a different perspective.

The workflow required several model calls.

The context was larger than usual.

One external API added another variable cost.

An intermediate step failed and had to be retried.

The final result required additional processing before it became useful to the customer.

None of this made the execution incorrect.

The customer was entitled to the workflow.

The infrastructure handled the retry safely.

Usage was measured accurately.

The customer was charged according to the product's rules.

And yet, after accounting for what it actually cost to produce the useful outcome, the execution generated less revenue than it consumed.

Nothing failed.

The execution simply wasn't economically healthy.

That distinction matters because production systems are usually designed to detect incorrect behaviour.

They are much less likely to tell you when technically correct behaviour is producing unhealthy economics.

Correct Execution Is Not the Same as Healthy Execution

AI infrastructure has become increasingly good at answering questions about runtime correctness.

Was the request authorized?

Was the customer entitled to use the feature?

Was consumption applied atomically?

Were retries handled idempotently?

Was usage recorded correctly?

Did application state remain synchronized with commercial state?

These are important questions.

Getting them wrong can produce duplicate consumption, incorrect access, lost revenue or broken customer experiences.

But even a system that answers all of them correctly still leaves another question unresolved:

Was this execution economically sustainable?

Consider two properties of the same workflow.

Runtime perspective	Economic perspective
Request authorized correctly	Cost justified by the revenue or value produced
Entitlement valid	Customer remains healthy to serve
Usage recorded correctly	Usage cost remains sustainable
Retry handled safely	Total retry cost remains acceptable
Execution completed	Completed outcome remains economically viable
Customer charged correctly	Revenue adequately covers cost-to-serve

The left side does not guarantee the right side.

A request can be perfectly authorized and still be expensive.

Usage can be perfectly metered and still represent an unhealthy consumption pattern.

A retry can be perfectly idempotent and still add legitimate cost to an already low-margin workflow.

A customer can be charged exactly according to plan and still cost more to serve than the revenue that plan generates.

This is not an argument against runtime correctness.

Quite the opposite.

Runtime correctness is foundational.

Without it, the economic picture cannot be trusted in the first place.

But correctness tells us whether the system behaved according to its rules.

It doesn't necessarily tell us whether those rules produced a healthy business outcome.

That is a different problem.

And AI makes that distinction increasingly difficult to ignore.

AI Makes This Problem Different

Traditional software has always had infrastructure costs.

Servers cost money.

Databases cost money.

Storage, bandwidth and third-party services cost money.

But for many SaaS products, the marginal cost of one additional customer action is relatively small.

A user opens another dashboard.

Creates another project.

Runs another database query.

Sends another internal request.

The infrastructure performs more work, but the economics of the business rarely depend on the profitability of that individual action.

AI changes this relationship.

A single customer request may trigger a chain of operations with directly measurable variable costs:

Model inference
Input and output tokens
GPU workloads
Vector search
Retrieval pipelines
External APIs
Agent tool calls
Image generation
Voice processing
Human review

And those costs are rarely uniform.

The same feature may be inexpensive for one execution and significantly more expensive for another.

A short support question may require one small model call.

A complex research task may require a long context window, multiple model calls, retrieval, several tools and repeated reasoning steps.

Both may appear in the product as the same feature.

Operationally, they are not the same workload.

Economically, they may be completely different.

This creates a tighter connection between architecture and business economics.

Model selection matters.

Context size matters.

Retry behaviour matters.

Workflow design matters.

Tool selection matters.

Exception handling matters.

Not because every expensive execution is necessarily bad.

An expensive workflow can be perfectly healthy if it creates enough value or supports sufficient revenue.

The important point is that execution now has an economic dimension that cannot always be inferred from whether the request succeeded.

The Cost of the Successful Request Is Not the Whole Cost

Suppose an AI workflow eventually completes successfully.

The final execution consumed $0.18 of model inference.

It would be tempting to record $0.18 as the cost of producing the result.

But production workflows rarely exist as isolated model calls.

The actual execution history may look more like this:

Customer Request
       ↓
Model Call
       ↓
Tool Call
       ↓
Tool Timeout
       ↓
Retry
       ↓
Second Model Call
       ↓
External API
       ↓
Human Correction
       ↓
Successful Outcome

The final model call may have cost $0.18.

But $0.18 is not necessarily what it cost the business to produce the outcome.

The failed attempt still consumed resources.

The retry still consumed resources.

The tool call may have generated a third-party charge.

The external API may have its own usage cost.

Human intervention may have introduced support or operational overhead.

The useful economic unit is therefore not always the final successful request.

Sometimes it is the entire path required to produce the successful outcome.

That distinction matters.

Imagine two executions producing the same customer-visible result:

Execution A

1 model call
1 successful tool call
No retry

Total execution cost: $0.24

Execution B

2 model calls
1 failed tool call
1 retry
1 successful tool call

Total execution cost: $0.61

From a product perspective, both workflows succeeded.

From a billing perspective, the customer may have paid exactly the same amount.

From an economic perspective, they are not equivalent.

This is where execution-level visibility becomes useful.

Not because every internal operation needs to become a financial metric.

That would create complexity of its own.

Attribution has a cost.

Instrumentation has a cost.

Human support can be difficult to allocate precisely.

Shared infrastructure costs rarely map perfectly to a single request.

The objective is not perfect accounting at arbitrary granularity.

It is enough visibility to understand where economically meaningful differences are coming from.

For some products, model and API costs may provide sufficient visibility.

For others, retries, workflow stages or human intervention may materially change the economics and deserve to be included.

The appropriate level of attribution depends on the product.

But the principle remains:

The cost of a successful AI outcome may include every meaningful attempt required to produce it—not only the request that finally succeeded.

This also changes how we think about failure.

A failed execution is not always financially neutral.

The customer may never receive an outcome.

The business may still have paid for the work performed before the failure.

At sufficient scale, that difference becomes important.

A technically correct usage ledger can tell you exactly what was consumed.

Understanding whether that consumption created sustainable value requires another layer of analysis.

Customer Profitability Is a Distribution Problem

Aggregate metrics are useful because they compress complexity.

Total revenue.

Average revenue per customer.

Average infrastructure cost.

Gross margin.

At a company level, these numbers can provide a reassuring picture.

But averages hide distribution.

And in AI products, that distribution can matter significantly.

Consider two customers on the same plan.

Both pay:

$200 / month

Both use the same product.

Both appear as equally valuable accounts in a revenue dashboard.

Their underlying economics, however, may look very different.

Customer A

Short context
Standard model
Predictable workflow
Few retries
Minimal support

Monthly cost-to-serve: $38

Customer B

Long context
Expensive model routing
Multiple tool calls
Frequent retries
Exception-heavy workflows
Regular support intervention

Monthly cost-to-serve: $176

The revenue is identical.

The economics are not.

Customer A contributes substantial margin.

Customer B may still be profitable, but only narrowly.

Add a few unusual execution paths, additional support requests or expensive failures and that account could become unprofitable without anything appearing wrong in the billing system.

The customer paid exactly what they were supposed to pay.

The product delivered exactly what was promised.

The problem exists in the relationship between revenue and cost-to-serve.

This is why customer profitability is fundamentally a distribution problem.

A portfolio can look healthy in aggregate while containing customers with radically different economic profiles.

For example:

100 Customers
      ↓
Average Gross Margin: 70%
      ↓
Looks Healthy

But underneath that average:

70 customers → high margin
20 customers → moderate margin
 8 customers → low margin
 2 customers → negative margin

The 70% average is not wrong.

It is simply incomplete.

It tells you about the portfolio.

It doesn't tell you where profitability comes from.

I explored this problem from the business side in Your AI Business Can Grow While Your Margins Shrink, where I looked at why averages can hide radically different customer and workflow economics.

That distinction becomes more important when AI consumption varies significantly between accounts.

It also means that high usage should not automatically be treated as a problem.

A power user may generate substantial cost while also generating substantial revenue, retention value or strategic importance.

Another customer may consume far less infrastructure but still be economically unattractive because of pricing, support overhead or inefficient workflows.

Usage alone doesn't determine profitability.

The relationship between revenue, consumption and cost-to-serve does.

The question isn't which customers use the most AI. It's whether the economics of serving them remain healthy.

Workflow Profitability May Matter More Than Model Cost

Customer-level profitability provides one useful perspective.

But it still leaves an important question unanswered.

Why is one customer more expensive to serve than another?

The answer often exists one level deeper.

Inside the workflows they execute.

AI engineering teams naturally monitor infrastructure metrics such as:

Token consumption
Model cost
Latency
API calls
GPU utilization
Retry rates

These metrics are valuable.

They help teams understand how the system behaves.

But they don't necessarily explain whether that behaviour creates enough value to justify its cost.

Consider two workflows.

Workflow A

Cost: $1.40

Outcome:
A qualified sales opportunity

Workflow B

Cost: $0.22

Outcome:
An internal summary that is rarely used

Workflow B is cheaper.

That doesn't automatically make it economically better.

The relevant question depends on what the product is trying to accomplish.

Customers don't usually purchase tokens, inference calls or tool executions as ends in themselves.

They purchase outcomes.

A resolved support ticket.

A processed document.

A completed research task.

A qualified lead.

A successfully completed agent workflow.

This suggests another useful unit of analysis:

Cost per useful outcome.

Instead of measuring only:

Cost per Model Call

some products may benefit from understanding:

Total Cost of Workflow
        ↓
Successful Outcome
        ↓
Cost per Useful Outcome

Suppose a support automation processes 1,000 conversations.

The infrastructure metrics show:

Total AI Cost: $420

That number is useful.

But imagine only 600 conversations are resolved without escalation.

Looking at successful outcomes provides additional context:

$420 total execution cost
        ÷
600 resolved conversations
        =
$0.70 per resolved conversation

Now the infrastructure cost can be compared with something closer to business value.

That might help answer questions such as:

Is automation still cheaper than the alternative?
Which workflows create the most expensive successful outcomes?
Do retries materially change outcome economics?
Does changing models improve cost without reducing completion quality?
Are some execution paths expensive but still economically justified?

This metric is not universally applicable.

Defining a "useful outcome" can be difficult.

Some products create value gradually rather than through discrete completions.

A research assistant may influence a decision without producing an easily measurable economic event.

An AI coding tool may save developer time that is difficult to attribute precisely.

Multi-step agent systems may produce value across several workflows.

Attribution can quickly become more complex than the insight it provides.

The objective is therefore not to force every AI product into a single profitability metric.

The architectural lesson is simpler.

Infrastructure cost becomes more useful when it can be connected to the customer activity and business outcome that produced it.

Token cost tells you what the model consumed.

Workflow cost tells you what the system consumed.

Outcome economics begin to tell you whether that consumption was worth it.

Those are different levels of understanding.

Visibility Before Optimization

Once teams discover that AI costs vary significantly across customers and workflows, the natural reaction is to optimize.

Use a cheaper model.

Reduce context size.

Introduce stricter limits.

Change pricing.

Route requests differently.

Reduce retries.

These may all be reasonable decisions.

But they assume something important:

That the team already understands where the economic problem actually is.

Often, it doesn't.

A rising model bill tells you that spending increased.

It doesn't tell you which customers caused the increase.

A high token count tells you that the system processed more context.

It doesn't tell you whether that context produced valuable outcomes.

A high retry rate tells you that executions required additional attempts.

It doesn't tell you whether those retries were necessary, wasteful or economically significant.

And a declining gross margin tells you that the business is becoming more expensive to operate.

It doesn't tell you why.

Before optimization, teams increasingly need enough visibility to connect several layers of the system:

Customer
    ↓
Workflow
    ↓
Execution
    ↓
Retries / Failures
    ↓
Usage
    ↓
Cost
    ↓
Outcome

The goal is not perfect attribution.

Perfect attribution may be impossible or unnecessarily expensive.

The goal is decision-quality visibility.

Enough information to distinguish between very different situations.

For example, suppose infrastructure costs increase by 20%.

Without additional context, the obvious response might be to move more traffic to a cheaper model.

But deeper visibility could reveal that the increase came primarily from one workflow experiencing repeated tool failures.

The model wasn't the problem.

Or perhaps one customer segment began using significantly longer contexts because of a new product behaviour.

The pricing model may need attention.

Or perhaps costs increased because customers are completing more high-value workflows.

In that case, higher infrastructure spending may be perfectly healthy.

The same cost increase can therefore represent:

Waste

or

Product Growth

or

Pricing Misalignment

or

Workflow Inefficiency

or

Healthy High-Value Usage

The number alone cannot tell you which one.

Context can.

This is why optimization without visibility is mostly guesswork.

Engineering Is Becoming Part of Economic Analysis

Once execution data is connected to customers and workflows, familiar engineering signals begin to acquire a second meaning.

A retry rate is no longer only a reliability metric.

It may also explain why a workflow costs more than expected.

A metering discrepancy is no longer only a data-quality issue.

It may distort the company's understanding of customer profitability.

A stale entitlement is no longer only an access-control problem.

It may allow expensive execution under commercial conditions that are no longer valid.

A reconciliation gap is no longer only an operational inconsistency.

It may prevent the business from knowing whether recorded revenue and actual consumption describe the same reality.

This does not mean engineering teams should become finance teams.

Nor does it mean every infrastructure decision should be reduced to margin.

Reliability, latency, quality and customer experience still matter independently.

The change is that these concerns can no longer always be evaluated in isolation.

In AI products, infrastructure behaviour increasingly influences the economic behaviour of the business.

Consider a model-routing decision.

Engineering might evaluate:

Latency
Quality
Reliability
Cost per call

Those are useful dimensions.

But once the same execution is connected to workflow outcomes, another comparison becomes possible:

Model A

Higher cost per call
Better completion rate
Fewer retries
Higher useful-outcome rate

versus:

Model B

Lower cost per call
Lower completion rate
More retries
More escalations

The cheaper model is not necessarily the cheaper workflow.

And the more expensive workflow is not necessarily the worse business decision.

The answer depends on the outcome economics.

This is where engineering telemetry begins to become business intelligence.

Not because infrastructure metrics suddenly become financial metrics.

But because connecting them provides context that neither side has independently.

From Runtime Correctness to Economic Correctness

Up to this point, we have been discussing two different properties of an AI system.

The first is familiar.

The system should behave correctly.

Requests should be authorized.

Consumption should be atomic.

Retries should be safe.

Usage should be accurate.

Commercial and application state should remain aligned.

Runtime authorization is one part of that problem. In The Most Expensive AI Request Is the One You Should Have Blocked, I explored why deciding whether an AI request should execute can itself become an economic decision.

We can think of this as Runtime Correctness.

It answers:

Did the system execute correctly?

But the examples throughout this article expose another question.

Suppose all of those guarantees hold.

The request was authorized.

The workflow executed correctly.

The retry was legitimate.

Usage was recorded accurately.

The customer was charged exactly according to plan.

And the completed outcome still cost more to produce than its economics could support.

The runtime was correct.

The business outcome was unhealthy.

A useful way to reason about this second property is Economic Correctness.

Not as an established industry category, but as a mental model.

It asks:

Did this technically correct execution also make economic sense?

The distinction looks simple:

Runtime Correctness	Economic Correctness
Was execution authorized?	Was execution economically justified?
Was consumption correct?	Was cost-to-serve sustainable?
Was usage accurate?	Did usage produce sufficient value?
Were retries safe?	Did retries preserve healthy outcome economics?
Was commercial state respected?	Did the resulting execution remain commercially viable?

Neither replaces the other.

Economic analysis built on incorrect runtime data cannot be trusted.

And technically correct execution without economic visibility can still produce an unhealthy business.

A sustainable AI product increasingly needs to understand both.

Correct Execution
        +
Economic Understanding
        ↓
Healthier AI Economics

This does not mean every request needs a real-time profitability calculation before it executes.

That would often be impractical, unnecessary or based on incomplete information.

Some economics can only be understood after the workflow completes.

Some costs arrive later.

Some outcomes are difficult to quantify.

Some customers should rationally be served at lower margins for strategic reasons.

Economic correctness is therefore not a binary runtime rule.

It is a way of asking whether the technical behaviour of the system remains aligned with the economic objectives of the business.

And asking that question requires connecting information that traditionally lives in different systems.

The Missing Connection Is Runtime Intelligence

The signals required to understand AI economics already exist in many production systems.

The problem is that they usually exist in different places.

Payment systems understand commercial state.

Authorization systems understand whether execution is allowed.

AI providers report model consumption.

Application logs describe execution behaviour.

Metering systems record usage.

Observability platforms capture failures and retries.

Product systems may know whether the workflow produced a useful outcome.

Finance sees revenue and aggregate cost.

Each system contains part of the story.

Very few contain the whole story.

A simplified execution may therefore generate information across several layers:

Commercial State
        ↓
Authorization
        ↓
Execution
        ↓
Metering
        ↓
Retries / Failures
        ↓
Outcome
        ↓
Economics

Individually, these signals answer useful questions.

Commercial state tells us what the customer purchased.

Authorization tells us whether the operation was allowed.

Execution telemetry tells us what actually happened.

Metering tells us what was consumed.

Failure data tells us what additional work occurred.

Outcome data tells us whether the workflow achieved its objective.

Economic data tells us what serving that activity ultimately cost.

The harder problem is connecting them.

Suppose a customer generates unusually high model spend.

That fact alone tells us very little.

Perhaps the customer is unprofitable.

Perhaps they are one of the company's most valuable accounts.

Perhaps a specific workflow is inefficient.

Perhaps a provider started producing more failures.

Perhaps retries increased after a deployment.

Perhaps usage increased because the product is delivering significantly more value.

The cost signal becomes useful only when it can be interpreted in context.

This suggests an architectural direction that goes beyond traditional observability.

We can think of it as Runtime Intelligence.

Not as an established infrastructure category, and not as a system that automatically knows which business decisions are correct.

Rather, as the ability to connect runtime behaviour with the commercial and economic context surrounding it.

Instead of observing only:

What happened?

the system begins helping teams understand:

What happened?

For which customer?

Inside which workflow?

Under which commercial conditions?

At what cost?

After which failures or retries?

And with what outcome?

That additional context can make infrastructure data substantially more useful to both engineering and business teams.

It can help reveal patterns such as:

Customers whose cost-to-serve changes significantly over time
Workflows where retries materially affect economics
Execution paths responsible for disproportionate infrastructure spending
Features whose usage grows faster than the value they produce
Expensive workflows that remain healthy because they generate high-value outcomes
Differences between expected and observed consumption

The objective is not to automate every decision.

Visibility may lead to a pricing change.

Or a workflow redesign.

Or different model routing.

Or better retry handling.

Or a product decision.

Or no change at all.

The important step is understanding the system well enough to make that decision deliberately.

Runtime Intelligence, in this sense, is less about autonomous optimization and more about connecting technical behaviour to economic consequence.

Closing

Return to the execution from the beginning.

The customer was authorized.

The entitlement was valid.

The workflow executed successfully.

Retries were handled correctly.

Usage was recorded accurately.

The customer was charged exactly according to the product's rules.

Observability showed green.

Everything worked.

That remains an important achievement.

But we can now ask one more question.

What did it actually cost to produce the useful outcome?

Perhaps the answer shows a healthy execution.

Perhaps the workflow was expensive but generated enough value to justify that cost.

Perhaps the customer remains highly profitable despite heavy usage.

Or perhaps several technically correct behaviours combined to produce an outcome whose economics are difficult to sustain.

Runtime correctness alone cannot distinguish between those situations.

It was never designed to.

That is why the next challenge for AI infrastructure may not simply be making execution more reliable.

It may be making the economics produced by that execution more visible.

Not every company needs request-level profitability.

Not every workflow has an easily measurable outcome.

Not every expensive customer should be optimized for margin.

And not every economic decision belongs inside the runtime.

But as AI products become more dependent on variable-cost execution, the connection between infrastructure behaviour and business health becomes harder to ignore.

The question evolves from:

Is my AI system working correctly?

to something broader:

Is my AI business actually healthy — and why?

That is the problem I'm currently exploring with Licenzy.

Licenzyis being developed around the idea of an AI Monetization Runtime: infrastructure for keeping commercial state and AI execution correctly aligned.

The direction we're exploring beyond that foundation is Runtime Intelligence — connecting reliable runtime behaviour with better visibility into the customer, workflow and economic outcomes it produces.

That work is still an exploration.

But the underlying question is already useful regardless of which infrastructure a team ultimately uses.

Your AI system may be working exactly as designed.

The harder question is whether you understand the economics it is producing.

Your AI Business Can Grow While Your Margins Shrink

Ciroandrea — Mon, 03 Aug 2026 07:56:21 +0000

Most founders love seeing graphs like this.

Revenue      ↗
Customers    ↗
Usage         ↗

Everything appears to be moving in the right direction.

More customers.

More subscriptions.

More AI requests.

More revenue.

For traditional SaaS businesses, those trends usually tell a reassuring story.

Growth often brings economies of scale.

Serving one additional customer typically costs very little.

Average metrics become reasonably good indicators of business health.

AI products are different.

An AI business can continue growing while quietly becoming less profitable.

Revenue increases.

Usage increases.

Customers remain happy.

Yet margins slowly deteriorate.

Not because pricing is wrong.

Not because customers stop paying.

But because the economics of AI are hidden inside the distribution of usage rather than the averages shown on most dashboards.

Growth tells you that the business is expanding.

It does not necessarily tell you that the business is becoming healthier.

Traditional SaaS trained us to think differently

For years, software companies learned to evaluate success through a relatively small set of financial metrics.

Dashboards typically focused on indicators such as:

Monthly Recurring Revenue (MRR)
Annual Recurring Revenue (ARR)
Average Revenue Per User (ARPU)
Gross Margin
Customer Growth

These metrics work remarkably well for many traditional SaaS products.

Once the software has been built, serving one additional customer usually introduces very little additional cost.

A customer logs in.

Views another dashboard.

Creates another project.

Runs another report.

The infrastructure certainly performs more work, but the marginal cost of those actions often remains relatively small.

That economic model shaped the way many founders learned to interpret growth.

If revenue increased while gross margins remained healthy, the business was generally moving in the right direction.

Average metrics provided a reliable picture of the company's overall health.

AI products challenge that assumption.

The cost of serving one additional request is no longer close to zero.

Every interaction may consume resources that directly affect profitability.

The averages still matter.

They simply stop telling the entire story.

AI products changed the economics

Unlike traditional SaaS, AI products often incur variable operational costs every time customers use the product.

A single interaction may trigger:

Model inference
Token consumption
GPU time
Retrieval pipelines
Agent execution
Image generation
Voice synthesis
External APIs

Each of those operations consumes infrastructure with a measurable financial cost.

Two customers paying the same subscription price may generate completely different operating costs.

One may submit a handful of lightweight requests each day.

Another may execute hundreds of long-running agent workflows.

From a revenue perspective, they appear identical.

From a profitability perspective, they may have almost nothing in common.

This is one of the biggest economic shifts introduced by AI.

Revenue becomes increasingly predictable.

This shift also changes how companies think about AI monetization after payment, something I explored in Why Payment Is Only the Beginning for AI Products.

Costs become increasingly variable.

That changes the questions founders need to ask.

Instead of looking only at how much revenue the business generates, they also need to understand where that revenue creates healthy margins—and where it quietly erodes them.

Why averages become dangerous

Most dashboards summarize a business using averages.

Average revenue per customer.

Average infrastructure cost.

Average gross margin.

Average usage.

Those metrics are useful.

The problem is that they can also be deeply misleading.

Imagine an AI product with one hundred paying customers.

The dashboard reports:

Revenue Growth        ↑
Average Margin        68%
Customer Growth       ↑

Everything appears healthy.

Now imagine looking beneath those averages.

100 Customers

↓

5 customers generate 42% of AI costs

↓

3 workflows consume 58% of total compute

↓

1 AI agent produces most retry-related spending

The business hasn't changed.

The perspective has.

The averages suggested a healthy company.

The distribution reveals where profitability is actually being won—or lost.

This is one of the biggest differences between traditional SaaS and AI products.

AI costs rarely distribute evenly across customers or workflows.

A small number of interactions often accounts for a disproportionately large share of infrastructure spending.

Revenue grows across the entire customer base.

Costs tend to concentrate.

Without visibility into that distribution, healthy-looking metrics can hide unhealthy economics.

Averages tell you how the business looks. Distributions tell you how the business behaves.

Workflow profitability is becoming more useful than token counts

When AI costs begin increasing, many teams instinctively monitor token consumption.

That is a reasonable starting point.

Tokens are measurable.

Easy to aggregate.

Easy to visualize.

Unfortunately, they rarely answer the question founders actually care about.

The business doesn't exist to optimize token counts.

It exists to produce profitable outcomes.

Consider two AI workflows.

Workflow A

120,000 tokens

↓

Generates a contract worth £500

Workflow B

35,000 tokens

↓

Produces an internal summary worth almost nothing

Looking only at token usage, Workflow A appears far more expensive.

Looking at business value, it may be significantly healthier.

The important question is no longer:

How many tokens did we consume?

It becomes:

Was the outcome worth the cost of producing it?

That shift changes what companies need to measure.

Instead of asking only:

Which model generated the cost?
How many tokens were consumed?

Teams increasingly need answers such as:

Which customer generated this cost?
Which workflow generated this cost?
Which feature generated this cost?
Did the completed workflow remain profitable?
Did retries significantly change its economics?
Would we make the same execution decision again?

This is why workflow profitability is becoming a far more meaningful metric than raw infrastructure usage.

Customers purchase outcomes.

Healthy AI businesses increasingly optimize the economics of those outcomes rather than the cost of individual model calls.

Visibility must come before optimization

When founders notice AI costs increasing, the first instinct is often to revisit pricing.

Should subscriptions become more expensive?

Should credits be introduced?

Should usage limits change?

Should top-ups become mandatory?

Those are reasonable questions.

But they all assume the company already understands where its costs come from.

In practice, many teams don't.

They know the cloud bill increased.

They know model usage is growing.

They know margins are changing.

They often don't know why.

Pricing decisions made without operational visibility are mostly educated guesses.

Before changing pricing, companies increasingly need answers to questions such as:

Which customers are consistently profitable?
Which workflows generate the highest costs?
Which AI features create the most business value?
Which execution paths require repeated retries?
Which providers contribute most to operational costs?
Which outcomes become unprofitable after infrastructure overhead is included?

Without this visibility, optimisation becomes reactive.

The business adjusts prices without understanding the underlying economics.

That may improve revenue.

It rarely fixes the real problem.

Understanding the distribution of costs should come before attempting to redistribute them.

Engineering is becoming part of business strategy

For many years, engineering and business strategy were largely separate conversations.

Engineering focused on building reliable systems.

Finance focused on revenue, margins and profitability.

Product teams focused on customer experience.

AI products increasingly blur those boundaries.

Today, infrastructure decisions directly influence business performance.

A metering error can distort customer profitability.

A retry policy can change workflow economics.

I've previously written about why retry behaviour is increasingly becoming an economic concern rather than just a reliability concern in Why Retry Safety Is Becoming a Business Problem for AI Products.

Incorrect usage accounting can make pricing appear successful when margins are quietly deteriorating.

A missing authorization check can turn profitable customers into unprofitable ones.

None of these issues begins in a pricing spreadsheet.

They begin inside the runtime.

This is one of the most significant shifts introduced by AI.

Infrastructure is no longer just responsible for delivering software.

It increasingly determines how healthy the business becomes as it scales.

Engineering decisions now influence questions that traditionally belonged to finance:

Which customers are profitable?
Which workflows should be encouraged?
Which features justify their operational cost?
Which execution paths should be redesigned?

The conversation is no longer simply about building systems that work.

It is about building systems whose economics continue to work as the company grows.

Engineering no longer supports business strategy. In AI products, it increasingly shapes it.

A new way of thinking

Traditional SaaS businesses often begin with a familiar question:

How much revenue are we generating?

That question still matters.

But for AI products, it is no longer sufficient.

A more useful question is:

Which customers and workflows are actually profitable?

Those questions produce very different decisions.

The first encourages growth.

The second encourages sustainable growth.

One useful mental model looks like this:

Revenue
      ↓
Customer
      ↓
Workflow
      ↓
Runtime Events
      ↓
Infrastructure Cost
      ↓
Business Outcome

Each layer provides context that averages alone cannot reveal.

Revenue tells you that customers are paying.

Runtime events explain what actually happened.

Infrastructure costs show what the company spent.

Business outcomes reveal whether those costs created value.

Healthy AI companies increasingly optimise across the entire chain—not just the first metric.

Growth remains important.

But understanding how growth is generated is becoming just as important as measuring how much growth exists.

Revenue tells you how fast your AI business is growing. Profitability distribution tells you how healthy it is becoming.

Closing

The first generation of AI products taught us how to integrate models.

The second generation is teaching us how to operate them sustainably.

Those are different challenges.

Building an AI application is becoming increasingly accessible.

Building an economically healthy AI business remains considerably harder.

The companies that succeed won't necessarily be the ones with the largest models or the lowest inference costs.

They'll be the ones that understand the economics hidden inside their own infrastructure.

That means looking beyond averages.

Looking beyond monthly revenue.

Looking beyond total token consumption.

Instead, they'll understand:

Which customers generate healthy margins.
Which workflows create sustainable value.
Which runtime behaviours quietly erode profitability.
Which engineering decisions influence business outcomes.

Growth is still important.

But growth without visibility can be misleading.

Revenue can continue increasing while the underlying economics quietly deteriorate.

Healthy AI businesses increasingly optimise for something more fundamental than growth alone.

They optimise for sustainable profitability.

Learn More

As AI products mature, a new infrastructure pattern is beginning to emerge.

Rather than treating payments, runtime execution and business analytics as completely separate systems, many teams are starting to connect them into a single operational layer.

Its objective isn't simply to process payments or record usage.

It's to keep commercial state, runtime execution and business economics aligned throughout the lifecycle of every AI request.

That increasingly includes capabilities such as:

Runtime authorization
Usage accounting
Cost attribution
Retry-safe execution
Idempotent consumption
Reconciliation
Workflow profitability
Revenue leakage prevention

Some companies build this infrastructure internally.

Others adopt specialised platforms designed for AI monetization.

Solutions such as Licenzy are part of this emerging AI Monetization Runtime category, helping engineering teams maintain economically correct AI execution while products continue to scale.

The category is still evolving.

The underlying problem, however, is already here.

Understanding how infrastructure shapes profitability is becoming just as important as understanding how infrastructure delivers software.

Why Retry Safety Is Becoming a Business Problem for AI Products

Ciroandrea — Mon, 27 Jul 2026 10:28:18 +0000

Retries are one of the oldest reliability patterns in modern software.

A request times out.

The client retries.

A webhook fails to arrive.

The provider delivers it again.

A worker crashes halfway through a job.

The queue schedules another attempt.

For decades, these behaviours have been considered normal.

Distributed systems are inherently unreliable.

Networks fail.

Services become temporarily unavailable.

Messages are delayed.

Retries exist because failures are inevitable.

They help systems recover automatically without exposing every transient error to the customer.

In many ways, they became one of the foundations of reliable software.

But AI products have changed the economics of retrying.

A retry is no longer just another attempt to complete a request.

It may trigger another model inference.

Another image generation.

Another agent execution.

Another external API call.

Another usage event.

Another infrastructure cost.

Reliability is still the objective.

But reliability alone is no longer enough.

Modern AI systems increasingly need something else.

They need economic correctness.

A retry should not only recover from failure.

It should recover without changing the economic outcome of the original request.

Reliability solved one problem

Distributed systems cannot assume that every operation succeeds on the first attempt.

Temporary failures happen constantly.

Connections drop.

Providers become temporarily unavailable.

Requests time out.

Queues delay delivery.

External APIs return transient errors.

Without retries, many of these situations would become customer-visible failures.

An AI response might never be delivered.

A payment confirmation might never reach the application.

A workflow could remain permanently incomplete because of a momentary network interruption.

Retry mechanisms were designed to solve exactly this problem.

Rather than failing immediately, the system simply tries again.

Used carefully, retries improve resilience by allowing infrastructure to recover from short-lived failures such as:

Network interruptions
Temporary provider outages
Rate limits
Queue delivery failures
Database contention
External API instability

This pattern has become so common that most engineers rarely question it.

Retries are simply considered good engineering practice.

And in most distributed systems, they are.

The objective is straightforward:

Complete the requested operation despite temporary failure.

For years, that objective was enough.

AI products introduced a second requirement.

Completing the operation is no longer sufficient.

The system also needs to complete it without accidentally duplicating its economic effects.

...but AI changed the economics

Traditional SaaS products usually have a relatively low marginal cost per request.

A customer refreshes a dashboard.

Clicks the same button twice.

An API endpoint receives a duplicate request.

The infrastructure still performs additional work, but in many applications that extra cost is operationally insignificant.

AI products behave differently.

Almost every meaningful execution consumes resources with measurable financial impact.

A single request may involve:

Model inference
Input and output tokens
GPU time
Image generation
Speech synthesis
Vector search
External APIs
Agent orchestration

Retrying that request may repeat some or all of those costs.

From the customer's perspective, only one action occurred.

From the infrastructure's perspective, multiple expensive operations may have been executed.

The system successfully recovered.

The economics did not.

That is what makes retries fundamentally different in AI products.

A retry is no longer just another request.

It is another financial decision.

When retries quietly become revenue leakage

Most retry-related failures don't look like financial incidents.

They look like ordinary production behaviour.

A request times out.

A queue redelivers a message.

A worker restarts.

A webhook arrives twice.

An AI agent repeats the same tool call.

Individually, none of these events appears particularly alarming.

Most engineering teams have seen them hundreds of times.

The application usually continues working.

Customers still receive a response.

Operational dashboards remain green.

Yet every unnecessary execution consumes resources that can never be recovered.

That's what makes retry-related revenue leakage so difficult to detect.

Nothing appears broken.

The business simply spends more money than it intended.

Consider a few common production scenarios.

Duplicate executions

A client times out while waiting for an LLM response.

Believing the request failed, it retries.

The original inference had already completed.

The second request executes the same expensive operation again.

The customer receives one answer.

The infrastructure pays for two.

Concurrent retries

Two workers receive the same retry event.

Neither knows the other has already started processing it.

Both execute the workflow.

Only one result is ultimately returned.

The duplicate compute has already been consumed.

Race conditions

Two requests validate the same credit balance at almost exactly the same time.

Both conclude sufficient credits remain.

Both begin execution.

The commercial state allowed one operation.

The runtime performed two.

Delayed commercial state

A payment succeeds.

A webhook is delayed.

Another system still believes the customer has no active entitlement.

Or the opposite happens.

Access should already have expired, but stale state allows expensive AI execution to continue.

The infrastructure isn't behaving maliciously.

It's simply making decisions using outdated information.

Incorrect usage accounting

Execution succeeds twice.

Usage is recorded once.

Or execution succeeds once.

Usage is recorded twice.

Neither situation necessarily causes an outage.

Both quietly distort the economics of the product.

Revenue leakage rarely comes from one catastrophic engineering failure. It usually emerges from thousands of perfectly ordinary events that were never designed to preserve economic correctness.

Retry safety is no longer only about reliability

For years, retry safety meant one thing.

Recover from failure.

If the customer eventually received the expected result, the system had done its job.

AI products raise the standard.

A successful retry should not only recover the operation.

It should preserve the economics of the original request.

That means protecting several independent concerns at the same time:

Idempotency
Runtime authorization
Atomic consumption
Usage correctness
Reconciliation

These capabilities solve different problems.

Together, they protect the business from duplicate economic effects.

The objective is no longer simply:

Don't lose the request.

It is:

Execute exactly once.

Consume exactly once.

Record usage exactly once.

Charge exactly once.

In practice, distributed systems cannot always guarantee literal exactly-once execution.

Networks remain unreliable.

Providers still experience failures.

Messages can still be duplicated.

The practical objective is different.

The customer should experience one economically correct outcome, even if the infrastructure internally performs multiple attempts.

That distinction is becoming one of the defining architectural principles of modern AI products.

Retry safety requires more than retry logic

For many years, retry safety was largely considered a transport problem.

How many attempts should the client make?

Should retries use exponential backoff?

How long should the system wait before trying again?

Those questions are still important.

But they don't answer a more fundamental one.

What exactly is being retried?

That distinction matters.

A network request is not the same as a business operation.

One customer action may generate several technical requests.

A timeout.

A worker restart.

A queue redelivery.

A provider retry.

Treating every request as a completely new execution is operationally simple.

It is also economically dangerous.

Modern AI infrastructure increasingly needs to understand the difference between retrying a request and retrying an intent.

The customer didn't ask for multiple model executions.

They asked for one outcome.

This is the same architectural shift behind why authorisation should happen before expensive AI execution rather than after it.

If you're interested in that topic, I explored it in The Most Expensive AI Request Is the One You Should Have Blocked.

Protecting that outcome requires more than retry logic.

It requires architectural guarantees.

Idempotency

Every business operation should have a stable identity.

If the same operation reaches the execution layer multiple times, the infrastructure should recognise it as the same intent.

A transport retry should not become a second economic event.

Atomic consumption

Authorizing access, consuming credits and starting execution should not happen as unrelated steps.

If those operations are separated, concurrent requests can observe inconsistent state and spend the same balance more than once.

Economic decisions should happen atomically.

The system should secure the right to spend before expensive compute begins.

Runtime authorization

A successful payment doesn't guarantee that every future execution is valid.

Before retrying an expensive operation, the infrastructure should still verify:

Available credits
Active entitlements
Spending limits
Customer status
Runtime policies

Retries should preserve the original authorization intent rather than bypass it.

Usage correctness

Recording usage sounds straightforward.

In production, it rarely is.

A model may execute successfully while usage recording fails.

Usage may be written before execution completes.

A retry may generate duplicate usage events.

Or no usage event at all.

The objective isn't simply to count requests.

It's to ensure that recorded usage reflects what actually happened.

Reconciliation

Even well-designed distributed systems drift over time.

A provider may complete work after the caller has already timed out.

A webhook may arrive minutes later.

An internal ledger may disagree with an external billing record.

Reconciliation exists to compare expected state with observed reality and repair those differences before they become permanent.

Retries are unavoidable.

Economic inconsistency doesn't have to be.

Billing systems cannot solve this

Billing platforms solve an essential problem.

They establish the commercial relationship between a company and its customers.

They answer questions such as:

Has the customer paid?
Is the subscription active?
Was the invoice settled?
Should the next renewal occur?

Runtime infrastructure answers a completely different set of questions.

Has this operation already executed?
Is this retry part of the same business intent?
Has usage already been consumed?
Should another model inference begin?
Can this workflow safely continue?

Neither layer replaces the other.

Both are necessary.

Billing determines the commercial state.

Runtime infrastructure preserves that state while expensive AI execution is taking place.

I explored this separation between commercial state and runtime behaviour in more detail in Why Payment Is Only the Beginning for AI Products, where I explain why payment alone cannot govern AI execution.

A simplified architecture increasingly looks like this:

Commercial State
        ↓
Runtime Authorization
        ↓
Idempotency
        ↓
AI Execution
        ↓
Usage Accounting

Payment answers whether the customer is allowed to use the product.

Runtime determines whether the next execution remains economically correct.

That distinction becomes increasingly important as AI products scale.

Engineering decisions are becoming financial decisions

For a long time, engineering and finance measured success using different metrics.

Engineering focused on:

Availability
Latency
Throughput
Error rates

Finance focused on:

Revenue
Margins
Customer profitability
Operating costs

AI products are bringing those worlds closer together.

Infrastructure decisions increasingly influence financial outcomes.

A retry policy affects infrastructure costs.

A race condition can consume duplicate credits.

Incorrect usage accounting distorts customer profitability.

A stale commercial state may allow expensive execution that should never have happened.

None of these problems begin in finance.

They begin in software.

That represents a significant shift in how AI products should be designed.

Reliability is no longer measured only by whether the system eventually succeeds.

It is increasingly measured by whether the business outcome remains economically correct after recovery.

The engineering conversation is changing from:

Did the request succeed?

to:

Did the request succeed without compromising the economics of the product?

Those are no longer the same question.

Operational correctness is becoming economic correctness

Reliable systems recover from failure.

Economically correct systems recover without changing the intended business outcome.

That difference may appear subtle.

In production, it changes everything.

A workflow that executes twice may still produce the correct response.

A duplicate inference may remain invisible to the customer.

An agent may successfully finish its task after multiple retries.

Operationally, the system looks healthy.

Financially, it may be creating unnecessary cost, inaccurate usage records or incorrect profitability metrics.

Success can no longer be measured only by completed requests.

It increasingly needs to be measured by economically correct outcomes.

One useful mental model looks like this:

Customer Intent
        ↓
Runtime Authorization
        ↓
Economic Validation
        ↓
AI Execution
        ↓
Usage Accounting
        ↓
Reconciliation
        ↓
Business Economics

Every stage protects a different aspect of the business.

The objective isn't simply to make AI execute reliably.

It's to ensure that every execution remains aligned with the commercial reality of the product.

A new infrastructure layer is emerging

As AI products become more sophisticated, many teams are discovering that neither billing systems nor AI providers own this responsibility.

Billing platforms establish the commercial relationship.

AI providers execute workloads.

Application code orchestrates workflows.

Usage systems record consumption.

Each layer solves a different problem.

None of them is responsible for maintaining economic correctness across the entire execution lifecycle.

That responsibility increasingly sits between commercial state and AI execution.

Commercial State
        ↓
Authorization
        ↓
Execution
        ↓
Usage Accounting
        ↓
Business Economics

This emerging infrastructure layer exists to ensure that expensive AI operations happen under the correct commercial conditions, produce the correct usage records and preserve the intended economic outcome.

Rather than replacing billing or AI providers, it complements them by connecting business rules with runtime behaviour.

As AI products continue to mature, this architectural pattern is becoming increasingly common.

Platforms such as Licenzy are part of this emerging AI Monetization Runtime category, focusing on runtime authorization, usage correctness, idempotent consumption and economically correct AI execution.

The important trend, however, is larger than any individual platform.

The market is gradually recognising that reliability alone is no longer sufficient.

Modern AI infrastructure must also preserve economic correctness while software is running.

Final thoughts

Retries have always been part of building reliable distributed systems.

That hasn't changed.

What has changed is the cost of getting retries wrong.

In AI products, every unnecessary execution has the potential to consume compute, distort usage, reduce workflow profitability and quietly erode margins.

A retry is no longer just another technical attempt.

It is another economic event that must be handled correctly.

The next generation of AI infrastructure will still care about availability, latency and resilience.

But it will also care about something equally important.

Whether every successful recovery preserved the economics of the business.

Because in modern AI products, reliability is no longer the finish line.

Economic correctness is.

Learn More

As AI systems evolve, a new category of infrastructure is emerging between commercial state and AI execution.

Its purpose is not simply to process payments or meter usage.

Its purpose is to maintain economically correct execution throughout the entire AI runtime.

This increasingly includes capabilities such as:

Runtime authorization
Idempotent consumption
Usage correctness
Retry-safe execution
Atomic consumption
Reconciliation
Revenue leakage prevention

Some engineering teams build this layer internally.

Others adopt specialised infrastructure designed specifically for AI monetization.

Platforms such as Licenzy are part of this emerging AI Monetization Runtime category, helping engineering teams connect commercial state with runtime behaviour while protecting both operational reliability and business economics.

Most AI Revenue Leakage Isn't Fraud. It's Engineering.

Ciroandrea — Fri, 17 Jul 2026 12:23:18 +0000

When founders hear the term revenue leakage, they usually picture obvious threats.

Fraud.

Chargebacks.

Stolen accounts.

Unauthorized payments.

Those problems certainly exist.

But for many AI companies, they're not where the largest losses actually come from.

The biggest source of margin erosion is often far less dramatic.

It's engineering.

Not because engineers make mistakes.

But because modern AI products execute millions of decisions every day, and small operational inefficiencies quietly accumulate into significant business costs.

Revenue leakage in AI products rarely arrives all at once.

It happens one unnecessary request at a time.

One duplicate execution.

One retry.

One stale permission.

One workflow that should never have run.

Individually, these events seem insignificant.

Together, they slowly erode profitability.

The challenge isn't simply preventing fraud.

It's preventing infrastructure from spending money when it shouldn't.

The way most founders think about revenue leakage

Most software companies have traditionally viewed revenue leakage as a finance problem.

The usual suspects are familiar:

Payment fraud
Chargebacks
Account sharing
Subscription abuse
Failed collections

These are legitimate concerns.

They're also relatively visible.

Finance teams monitor them.

Payment providers offer protection.

Risk systems are designed to detect them.

AI businesses introduce a different kind of leakage.

One that often happens entirely inside the product itself.

No customer is acting maliciously.

No payment has failed.

No fraud has occurred.

The infrastructure simply consumes more resources than the business intended.

That difference is important.

Traditional revenue leakage usually happens because money isn't collected.

AI revenue leakage often happens because unnecessary costs are incurred.

The invoice may be completely correct.

The margins are not.

Invisible engineering decisions that quietly destroy margins

Few engineering teams intentionally design systems that waste money.

Most revenue leakage comes from perfectly reasonable engineering decisions made in isolation.

Consider a few examples.

A network timeout triggers an automatic retry.

An AI agent accidentally executes the same workflow twice.

A webhook is delivered more than once.

A customer's entitlements haven't refreshed yet.

A background job continues after access has expired.

A request reaches an expensive model before credits are validated.

None of these situations looks particularly alarming.

In many cases, the customer receives exactly the experience they expected.

From an operational perspective, the system appears healthy.

From a financial perspective, however, every unnecessary execution consumes resources that can never be recovered.

That's what makes engineering-driven revenue leakage so difficult to identify.

The application continues working.

Customers remain satisfied.

Revenue continues growing.

Meanwhile, margins quietly decline in the background.

The most dangerous revenue leakage isn't the kind that breaks your product. It's the kind that leaves your product working exactly as expected while quietly increasing operating costs.

Every unnecessary AI request has a real cost

Traditional SaaS products are remarkably forgiving.

A customer refreshes a dashboard.

Clicks the same button twice.

Reopens a page.

In most cases, the additional infrastructure cost is almost negligible.

AI products operate under a different economic model.

Nearly every meaningful interaction consumes resources that have a measurable cost.

A single request may involve:

LLM inference
Input and output tokens
GPU time
Image generation
Speech recognition
Speech synthesis
Vector database queries
External APIs
Agent orchestration

Unlike traditional software, execution itself becomes part of the cost structure.

That changes how engineering decisions should be evaluated.

A duplicate request isn't simply redundant.

It may trigger another model inference.

Another API call.

Another workflow.

Another bill.

Individually, these costs are usually small.

At scale, they become part of the product's unit economics.

Every unnecessary execution directly reduces the margin generated by that customer, that workflow, or that feature.

Revenue leakage isn't always measured by money that never arrives.

Sometimes it's measured by money that never needed to be spent.

Why billing systems cannot solve this

When AI companies begin thinking about monetization, billing is often the first layer they implement.

That's entirely reasonable.

Customers need to subscribe.

Invoices need to be generated.

Payments need to be collected.

Billing systems answer an essential business question:

Did the customer pay?

For AI products, however, another question becomes equally important:

Should this request execute?

They're runtime decisions. I've explored why this question has become fundamental for modern AI products in The Most Expensive AI Request Is the One You Should Have Blocked.

A successful payment doesn't necessarily mean the next AI request should run.

The customer may have exhausted their credits.

Their subscription may still be active while a premium entitlement has expired.

A spending limit may have been reached.

A duplicate request may already be processing.

A retry may already have consumed the necessary resources.

None of those situations are billing problems.

They're runtime decisions.

Billing records financial events.

Runtime infrastructure governs resource consumption.

This distinction between payment and runtime control is becoming increasingly important as AI monetization evolves.

As AI products become more sophisticated, separating those responsibilities becomes increasingly important.

One determines whether money has been collected.

The other determines whether more money should be spent.

Revenue leakage starts before invoices are generated

Many companies try to measure revenue leakage after the fact.

They analyze invoices.

Review cloud bills.

Investigate customer profitability.

Build dashboards to understand where margins are disappearing.

Those activities are valuable.

But they're also reactive.

By the time a dashboard shows an unnecessary AI execution, the infrastructure has already spent the money.

The real financial decision happened much earlier.

It happened the moment the request entered the system.

Healthy AI products increasingly introduce business validation before expensive compute begins.

Typical checks include:

Authorization
Entitlement validation
Credit verification
Spending limits
Duplicate detection
Runtime policies

Only after those checks pass does the application execute expensive AI workloads.

This approach doesn't eliminate operational costs.

It prevents unnecessary ones.

That's an important distinction.

The cheapest AI request isn't the one that uses fewer tokens.

It's the one that never needed to execute in the first place.

Engineering is becoming part of financial operations

For many years, engineering and finance operated in largely separate worlds.

Engineering focused on reliability.

Finance focused on revenue, costs and profitability.

AI products are bringing those worlds closer together.

Today, backend architecture directly influences business metrics such as:

Gross margins
Customer profitability
Workflow profitability
Infrastructure efficiency
Pricing sustainability

A retry strategy can affect operating costs.

A race condition can consume duplicate compute.

An authorization decision can determine whether a customer generates profit or loss.

These are no longer purely technical concerns.

They're business decisions implemented in software.

The more AI becomes part of a company's product, the more engineering becomes part of its financial operations.

Building economically healthy AI businesses increasingly depends on building economically aware infrastructure.

A new infrastructure layer is emerging

As AI products mature, a new architectural pattern is beginning to appear.

Instead of moving directly from payment to execution, many teams are introducing an additional decision layer.

Payment
    ↓
Authorization
    ↓
Execution
    ↓
Usage Tracking
    ↓
Business Economics

Each stage answers a different question.

Layer	Primary Question
Payment	Did the customer pay?
Authorization	Should this request execute?
Execution	Produce the requested AI outcome.
Usage Tracking	What resources were actually consumed?
Business Economics	Was this interaction economically healthy?

This isn't simply another infrastructure component.

It's a shift in how AI businesses think about monetization.

The objective is no longer just collecting revenue.

It's ensuring that every AI request contributes to a sustainable business model.

As this architectural pattern continues to evolve, a new category is beginning to emerge around it.

Rather than focusing exclusively on payments or billing, these platforms help companies make economically informed decisions before expensive AI resources are consumed.

Solutions such as Licenzy are part of this emerging AI Monetization Runtime category, providing the infrastructure that connects payment, authorization, usage and business economics into a single runtime layer.

The category is still taking shape.

But the underlying problem it addresses is becoming increasingly common as AI products scale.

Final thoughts

When founders hear the phrase revenue leakage, they often imagine fraud.

In AI businesses, the bigger risk is frequently much quieter.

It's infrastructure spending money when it didn't need to.

One duplicate execution.

One unnecessary retry.

One stale entitlement.

None of these events seem significant on their own.

Together, they shape the economics of the business.

That's why revenue leakage is increasingly becoming an engineering discipline as much as a financial one.

The companies that build healthy AI businesses won't simply be the ones with the best models or the lowest token prices.

They'll be the ones that make better decisions before compute begins.

Because in modern AI products, every engineering decision has the potential to become a financial decision.

The Most Expensive AI Request Is the One You Should Have Blocked

Ciroandrea — Mon, 13 Jul 2026 09:26:39 +0000

The most expensive AI request isn't the one that costs the most.

It's the one that should never have executed in the first place.

Many AI teams spend months optimizing inference speed.

Reducing latency.

Choosing better models.

Lowering token costs.

Those are all worthwhile optimizations.

But they only happen after the decision to execute has already been made.

A more important question often comes first.

Should this request execute at all?

That question becomes increasingly important as AI products grow.

Every unnecessary request consumes resources.

Every duplicate execution compresses margins.

Every unauthorized inference quietly increases costs.

Building an AI application is no longer just about making models run efficiently.

It's about deciding when they should run in the first place.

Why this matters

Imagine an AI customer who has:

Exhausted their monthly credits
Reached their spending limit
Lost access to a premium feature
Canceled their subscription

Now imagine your infrastructure still executes the request.

The model generates a response.

Tokens are consumed.

External APIs are called.

The workflow completes successfully.

From the customer's perspective, everything worked.

From the business perspective, something went wrong.

The infrastructure spent money before confirming that the request should have been allowed.

The financial impact of a single request might be negligible.

But AI businesses rarely process a single request.

They process thousands.

Sometimes millions.

Small authorization mistakes repeated at scale quietly become revenue leakage.

AI execution has become cheap to start but expensive to scale

Launching an AI product has never been easier.

Today, developers can integrate powerful language models, image generation APIs, voice services and agent frameworks in a matter of hours.

The barrier to experimentation has fallen dramatically.

The barrier to profitability has not.

Unlike traditional SaaS products, AI applications incur operational costs almost every time they create value.

Every interaction may consume:

LLM tokens
Image generation credits
Voice processing time
External API calls
Agent workflows
Vector database queries

The more successful the product becomes, the more infrastructure those requests consume.

Success doesn't only increase revenue.

It also increases operating costs.

That's what makes AI fundamentally different from many traditional software businesses.

Scaling usage doesn't simply increase customer value.

It also increases financial exposure.

The challenge is no longer making AI execute.

The challenge is making sure it only executes when it should.

Every AI request is a financial decision

Traditional software rarely forces you to think this way.

A customer clicks a button.

The application responds.

The cost of serving that request is usually negligible.

AI products work differently.

Almost every meaningful interaction consumes real resources.

A single request may trigger:

Millions of input and output tokens
Image generation
Speech-to-text processing
Text-to-speech synthesis
Multiple tool calls
External APIs
Agent reasoning
Background workflows

From an engineering perspective, that's simply execution.

From a business perspective, every one of those operations has a cost.

That's why every AI request is also a financial decision.

The moment compute begins, the business starts spending money.

Not all requests create value

One of the biggest misconceptions in AI products is assuming that every incoming request deserves to be executed.

It doesn't.

Consider a few common scenarios.

A customer has already consumed all available credits.

A subscription expired yesterday.

A duplicate request is accidentally retried.

An AI agent receives the same task twice because of a network timeout.

A webhook is delivered multiple times.

An administrator revoked access minutes earlier.

If the infrastructure executes those requests anyway, the product still incurs compute costs.

The customer may never even notice.

The finance team eventually will.

Every unnecessary execution quietly reduces margins.

The cost of a single request is rarely the problem.

The problem is allowing thousands of unnecessary requests to execute over time.

Why payment doesn't solve this problem

A common assumption is:

"The customer paid, therefore the request should execute."

That works well for traditional subscription software.

AI products introduce another layer of complexity.

A payment confirms a financial transaction.

It does not automatically answer questions like:

Does this customer still have credits?
Have they reached their usage limit?
Is this feature included in their plan?
Has access expired?
Is this request within their spending policy?
Should this workflow continue?

Payment is an event.

Authorization is a decision.

Those are two very different responsibilities.

As AI products evolve, separating them becomes increasingly important.

Every execution should begin with authorization

A healthy AI product doesn't start with model execution.

It starts with a question.

Should this request execute?

Only after that question has been answered should infrastructure begin consuming compute.

A simplified decision flow might look like this:

Incoming Request
        ↓
Authorize Request
        ↓
Validate Credits
        ↓
Validate Entitlements
        ↓
Validate Usage Limits
        ↓
Execute AI
        ↓
Track Usage
        ↓
Update Remaining Balance

Notice where AI execution appears.

Near the end.

Not at the beginning.

The healthiest AI businesses don't optimize models first.

They optimize decisions first.

Because every prevented execution protects infrastructure costs before they're ever incurred.

Healthy AI businesses authorize before spending

One pattern is becoming increasingly common across mature AI products.

Instead of asking:

"Can we execute this request?"

They first ask:

"Should we execute this request?"

That small change completely shifts how AI systems are designed.

Authorization is no longer just a security concern.

It's an economic decision.

Before expensive compute begins, healthy AI businesses increasingly validate things like:

Available credits
Spending limits
Active entitlements
Feature permissions
Usage policies
Customer status

Only after those checks pass does the application consume AI resources.

The objective isn't to deny legitimate requests.

It's to ensure that every execution creates value for both the customer and the business.

Every request that is blocked before compute starts is infrastructure cost that never had to be incurred.

The hidden cost of "just execute it"

Early in a product's life, executing every request often feels like the safest option.

The infrastructure is simple.

The customer receives a response.

Everything appears to work.

As usage grows, however, that assumption quietly becomes expensive.

Consider what happens when systems automatically execute requests without validating whether they should.

Situation	Technical Outcome	Business Outcome
Duplicate request	AI executes twice	Double infrastructure cost
Network retry	Request processed again	Silent revenue leakage
Race condition	Multiple executions	Incorrect credit balance
Stale entitlements	Access still allowed	Unpaid AI consumption
Failed workflow retry	Same task runs twice	Margin erosion

None of these failures usually break the application.

The customer often receives the expected result.

That's precisely why they're difficult to notice.

They don't create obvious outages.

They quietly create unnecessary costs.

Engineering problems become financial problems

Many of these situations are traditionally viewed as engineering concerns.

Retries.

Idempotency.

Concurrency.

Distributed systems.

Webhook delivery.

Queue processing.

On their own, they're technical challenges.

In AI products, they also become financial ones.

Every duplicate execution means compute was paid for twice.

Every stale entitlement means resources were consumed without authorization.

Every missing usage event reduces visibility into customer profitability.

As AI infrastructure becomes a larger part of operating costs, engineering reliability and financial health become increasingly connected.

Good architecture doesn't just improve reliability.

It protects margins.

Every unnecessary AI execution is a business expense disguised as an engineering event.

That may become one of the defining architectural principles of modern AI products.

Because once compute begins, the cost has already been incurred.

The cheapest AI request isn't the fastest one.

It's the one your infrastructure correctly decided not to execute.

A better mental model

Traditional SaaS products were largely built around a simple question:

Did the customer pay?

For many years, that was enough.

A successful payment activated a subscription.

The customer gained access.

The software continued working until the subscription expired.

AI products introduce a different reality.

Every interaction has the potential to consume real infrastructure.

That changes the question entirely.

Healthy AI businesses increasingly ask:

Should this AI request execute?

The distinction may seem subtle.

It isn't.

The first question is about a transaction.

The second is about protecting the economics of the business.

Every incoming request becomes a decision.

Should this customer consume more credits?

Should this workflow continue?

Should this feature still be available?

Should this expensive model be called?

Those questions are no longer edge cases.

They're becoming part of the runtime architecture of modern AI products.

A useful mental model looks like this:

Customer Request
        ↓
Authorization
        ↓
Business Validation
        ↓
AI Execution
        ↓
Usage Tracking
        ↓
Customer Access Updated

Notice what changed.

AI execution is no longer the first step.

It's the consequence of a successful business decision.

Final thoughts

For years, engineering teams optimized software for execution.

Could the request be processed?

Could the infrastructure scale?

Could the API respond faster?

Those questions still matter.

But AI products introduce a new engineering challenge.

Not every request that can execute should execute.

As compute becomes one of the largest operational costs for AI companies, profitability increasingly depends on making better decisions before infrastructure starts spending money.

That means thinking beyond payments.

Beyond subscriptions.

Beyond pricing.

It means designing systems that understand who is making the request, what they're entitled to use, how much they've already consumed, and whether executing another AI request actually makes business sense.

The companies that build economically healthy AI products won't simply have the fastest models or the most sophisticated prompts.

They'll have the discipline to spend compute only when it creates value.

That may become one of the defining engineering principles of the next generation of AI products.

Learn More

A new category of infrastructure is beginning to emerge between payment and AI execution.

Its role isn't to process transactions or run models.

Its role is to decide whether expensive AI resources should be consumed in the first place.

That infrastructure increasingly includes capabilities such as:

Real-time authorization
Creditsand prepaid balances
Usage validation
Access control
Entitlements
Runtime decision making

Some engineering teams build these systems internally.

Others adopt specialized infrastructure designed specifically for AI monetization.

Platforms such as Licenzy are part of this emerging AI Monetization Runtime category, helping AI companies protect margins, prevent revenue leakage, authorize requests before compute is consumed, and build economically healthy AI businesses without rebuilding this layer from scratch.

What percentage of AI requests in your product actually need to execute?

The answer might reveal more about your business than your pricing page ever could.

Building an AI Product Is Easy. Building a Profitable One Isn't.

Ciroandrea — Mon, 06 Jul 2026 12:15:12 +0000

Over the past two years, building AI products has become dramatically easier.

Founders can integrate state-of-the-art models in hours.

Launching an AI assistant, a content generator, or an AI agent no longer requires a large research team.

The technical barriers have fallen.

Ironically, the business barriers have become much higher.

Most founders spend months thinking about:

Which model to use
Prompt engineering
User experience
Pricing
Growth

Far fewer spend the same amount of time thinking about:

Margins
Customer profitability
Revenue leakage
Usage visibility
Cost attribution
Long-term sustainability

Yet these are often the factors that determine whether an AI company survives.

Building an AI product and building a profitable AI business are no longer the same challenge.

One is primarily an engineering problem.

The other is an economics problem.

And as AI products mature, economics increasingly become part of the product architecture itself.

Why this matters

Imagine two AI startups.

Both charge $49 per month.

Both have the same number of customers.

Both are growing at roughly the same pace.

On paper, they look almost identical.

But internally, they're very different.

The first company understands exactly:

how much each customer costs
which features generate the highest infrastructure costs
where revenue leakage occurs
which customers are profitable
how usage evolves over time

The second company only knows one thing.

Monthly Recurring Revenue.

From the outside, both businesses look healthy.

Only one actually is.

This is becoming one of the biggest differences between successful AI companies and those that struggle to scale.

The companies that survive aren't necessarily the ones with the best models.

They're often the ones that understand their economics the best.

Why pricing isn't the hardest problem anymore

For years, pricing was considered one of the hardest parts of building a SaaS business.

How much should you charge?

Monthly or annual?

Free trial or freemium?

Today, those questions are still important.

But they're no longer the hardest ones.

The market has evolved.

Subscriptions have become familiar.

Payment processing has become remarkably simple.

Modern payment platforms have significantly reduced the complexity of accepting online payments, allowing founders to focus on what happens after the transaction.

Receiving money is no longer the bottleneck.

The difficult part begins after the payment succeeds.

That's when your product has to answer questions like:

How much usage should this customer receive?
Which features should be available?
How should usage be tracked?
How do you prevent duplicate consumption?
How do you protect margins as usage grows?
Which customers are actually profitable?

Pricing determines how customers pay.

The infrastructure behind your product determines whether that pricing model remains economically sustainable.

That's an entirely different challenge.

AI costs are fundamentally different

One reason AI businesses behave differently from traditional SaaS is that their costs don't grow in the same way.

In a typical SaaS product, serving one additional customer often adds only a small incremental cost.

The software is already built.

Infrastructure costs are relatively predictable.

AI changes that equation.

Every interaction may generate a real infrastructure cost.

This is one reason why pricing AI products differs from traditional SaaS, where infrastructure costs are typically more predictable.

A customer might:

Generate thousands of images
Process millions of tokens
Run long AI agent workflows
Make continuous API requests
Hold extended voice conversations

Another customer on exactly the same subscription might use only a fraction of those resources.

Both pay the same monthly fee.

They don't generate the same economics.

This creates a challenge that traditional SaaS businesses rarely had to solve.

Revenue becomes predictable.

Costs do not.

Variable costs create unpredictable businesses

Imagine two customers on a $49/month plan.

Customer	Monthly Revenue	AI Usage	Infrastructure Cost
Customer A	$49	Light	Low
Customer B	$49	Heavy	High

From a billing perspective, they're identical.

From a profitability perspective, they're completely different businesses.

The goal isn't to discourage heavy users.

They're often your most engaged customers.

The challenge is understanding whether your pricing model still makes sense as usage grows.

Without visibility, founders often optimize the wrong metric.

They celebrate new subscriptions while margins quietly shrink in the background.

Profitability is becoming an infrastructure problem

Many founders assume profitability is primarily determined by pricing.

Charge more.

Reduce costs.

Increase conversions.

Those levers still matter.

But AI products introduce another variable.

Operational accuracy.

Profitability increasingly depends on whether your product can reliably answer questions like:

Was this request tracked?
Was usage deducted only once?
Can this customer still access this feature?
Which customer generated these infrastructure costs?
Which workflow consumed the most resources?

These questions don't belong to finance.

They belong to your application.

As AI products become more sophisticated, profitability becomes tightly connected to how reliably the product measures, authorizes and records usage.

Visibility changes decision making

Imagine you're looking at your dashboard.

One customer generated $99 this month.

At first glance, that sounds like a great customer.

Now imagine you can also see:

AI infrastructure cost: $82
Credits consumed: 98%
Long-running agent executions: 147
Duplicate requests prevented: 36

The conversation immediately changes.

You're no longer asking:

"How much revenue did this customer generate?"

You're asking:

"Is this customer profitable?"

That's a much more valuable question.

Because profitable growth doesn't come from maximizing subscriptions.

It comes from understanding the relationship between revenue, usage and cost.

The more visibility founders have into that relationship, the better decisions they can make about pricing, product design and long-term growth.

Healthy AI businesses share common characteristics

As more AI products mature, certain patterns begin to emerge.

Not because companies copy each other.

Because they start solving the same economic problems.

Different products may choose different pricing strategies.

Different founders may target different markets.

Yet many successful AI companies gradually adopt similar building blocks.

Instead of relying on a single subscription, they begin combining:

Subscriptions for predictable recurring revenue
Credits to allocate usage fairly
Top-ups for customers with higher consumption
Usage tracking to understand where costs come from
Access control to manage feature availability
Real-time authorization to evaluate every request

None of these components exists in isolation.

Together, they create a system that balances customer experience with business sustainability.

Balancing revenue and cost

One of the biggest challenges in AI products is that revenue and infrastructure costs rarely move together.

Revenue is often fixed.

Usage is not.

A healthy monetization model tries to keep those two dimensions aligned.

Business Goal	Supporting Infrastructure
Predictable revenue	Subscriptions
Fair consumption	Credits
Flexible growth	Top-ups
Cost visibility	Usage tracking
Reliable permissions	Access control
Healthy margins	Real-time authorization

Notice something interesting.

None of these components replaces pricing.

They support it.

Pricing defines the commercial model.

Infrastructure ensures that model remains economically sustainable as the business grows.

Customer trust is part of profitability

Profitability isn't only about reducing costs.

It's also about building trust.

Imagine a customer who sees:

Credits disappearing unexpectedly
Features becoming unavailable without explanation
Different balances across devices
Inconsistent usage history

Even if the billing is technically correct, the experience feels unreliable.

The opposite is also true.

When customers can clearly understand:

how credits are assigned
how they're consumed
what they can access
why a request was allowed or denied

they're far more likely to trust the product.

In AI businesses, operational transparency is increasingly becoming a competitive advantage.

Common founder mistakes

Most monetization problems don't start with pricing.

They start with assumptions that work well during the MVP stage but become increasingly fragile as products grow.

One of the most common is believing that pricing alone determines profitability.

In reality, pricing is only one variable.

The way usage is measured and controlled often has an even greater impact.

Another common mistake is assuming that a successful payment automatically means the customer should have access.

Payments and authorization solve different problems.

Treating them as the same responsibility usually creates unnecessary complexity over time.

Many teams also postpone usage tracking until after launch.

At first, that feels reasonable.

Growth matters more than analytics.

But once customers begin using the product heavily, recovering accurate usage history becomes extremely difficult.

Finally, many founders measure business performance almost entirely through revenue.

Revenue is important.

But revenue alone doesn't answer questions like:

Which customers are profitable?
Which features are expensive to operate?
Which workflows generate the highest AI costs?
Where is revenue leakage occurring?

Without that visibility, optimization becomes guesswork.

Growing an AI business isn't only about acquiring more customers.

It's about understanding the economics behind every customer you already have.

A better mental model

For years, many SaaS companies optimized for one thing above all else:

More subscriptions.

In the AI era, that mental model is becoming incomplete.

Subscriptions still matter.

Growth still matters.

But sustainable AI businesses increasingly optimize for something broader.

A useful way to think about it is like this:

Revenue
      ↓
Margins
      ↓
Predictability
      ↓
Customer Trust
      ↓
Healthy Growth

Notice what's missing.

The goal isn't simply maximizing revenue.

It's building a business where revenue, costs, customer experience and profitability remain aligned over time.

That requires much more than choosing the right pricing page.

It requires understanding how customers consume your product, how infrastructure costs evolve, and how every request affects the economics of the business.

The strongest AI companies aren't just building better models.

They're building businesses that remain economically healthy as usage grows.

That's a very different challenge.

Final thoughts

Building an AI product has never been more accessible.

Models are improving faster than ever.

Development frameworks continue to evolve.

Launching an AI application is becoming easier every year.

Building a profitable AI company is not.

As products scale, founders eventually discover that the biggest challenges aren't only technical.

They're operational.

They're economic.

They're architectural.

Success increasingly depends on questions like:

Can we understand where our costs come from?
Can we trust our usage data?
Are our customers actually profitable?
Can we scale without compressing our margins?
Are we delivering exactly the access customers purchased?

Those aren't billing questions.

They're business questions.

And they're becoming some of the most important questions an AI company can answer.

The companies that thrive over the next decade won't simply build impressive AI products.

They'll build systems that make those products economically sustainable.

Learn More

As AI companies grow, many eventually discover they need more than payment processing.

They need infrastructure that helps them understand and manage the economics of their products.

That often includes:

Credits
Usage tracking
Cost attribution
Entitlements
Access control
Real-time authorization

Some teams choose to build these capabilities internally.

Others adopt specialized infrastructure platforms designed to solve these operational challenges.

Platforms such as Licenzy focus on helping AI companies protect margins, prevent revenue leakage, manage usage, and turn successful payments into reliable product access—allowing engineering teams to spend more time building products and less time rebuilding monetization infrastructure.

If you could measure only one metric beyond revenue in your AI product, what would it be?

Customer profitability, usage visibility, margin, or something else?

Why Payment Is Only the Beginning of AI Monetization

Ciroandrea — Mon, 29 Jun 2026 10:09:45 +0000

A customer clicks Buy.

The payment succeeds.

Stripe confirms the transaction.

Success.

For many founders, this feels like the end of the monetization flow.

The customer has paid.

The problem is solved.

In reality, that's only the first event.

Now your product has to answer a series of questions that have nothing to do with processing a payment.

Can this customer access GPT-4?

How many AI credits should they receive?

Which features are included in their plan?

How should future usage be tracked?

What happens when their credits run out?

What if they purchase additional credits?

When should access expire?

These questions are no longer about payments.

They're about running a product.

And this is where many AI companies discover that accepting payments is actually the easiest part of monetization.

Why this matters

Accepting online payments has never been easier.

Today, founders can integrate providers like Stripe, Paddle or Lemon Squeezy in just a few hours and start selling subscriptions almost immediately.

That's a huge improvement compared to a decade ago.

Payment processing has become a solved problem for most SaaS companies.

Today, platforms like Stripe, Paddle, and Lemon Squeezy have significantly simplified online payment processing, allowing founders to launch products much faster than in the past.

But AI products introduce a new challenge.

Unlike traditional software, AI applications often have variable costs, dynamic usage, multiple pricing models and different levels of access depending on how customers use the product.

Receiving money is only the beginning.

The real challenge starts after the payment succeeds.

Payment processing is only one piece of the puzzle

Imagine a customer purchases your Pro AI Plan.

From a payment perspective, everything is finished.

The transaction succeeds.

The invoice is generated.

The subscription becomes active.

But your application still has work to do.

For example, it needs to determine:

Which AI models the customer can use
How many credits should be assigned
Which premium features become available
Whether API access should be enabled
What usage limits apply
How future requests should be authorized

None of these decisions are made by the payment itself.

They're part of your application's monetization layer.

This is why payment processing and monetization should be viewed as two different responsibilities.

A payment tells you that money was received.

Your monetization layer decides what the customer can actually do.

Payment is not authorization

One of the biggest misconceptions in AI products is treating payment and access as the same thing.

At first glance, they seem closely related.

A customer pays.

The customer gains access.

Simple.

But these are actually two completely different events.

A payment is a financial transaction.

Authorization is an application decision.

Imagine a customer purchases access to your AI product.

The payment provider knows that money has been received.

It does not know:

Which AI models should be available
How many credits the customer should receive
Whether API access should be enabled
Which usage limits apply
Which premium features are included
Whether access should expire tomorrow or next month

Those decisions belong to your application.

Modern SaaS products typically implement a dedicated authorization layer that separates financial events from application permissions.

That's why it's useful to think about them separately.

Payment Processing	Authorization
Money received	Can the customer use GPT-4?
Subscription renewed	Can they generate images?
Credits purchased	How many credits are available?
Invoice paid	Should API access be enabled?
Refund processed	Should access be revoked?

The payment tells your system what happened financially.

Authorization determines what the customer is allowed to do next.

Confusing these two responsibilities often leads to increasingly complex application logic.

What actually happens after a payment?

Let's follow a simple example.

A customer purchases your Pro AI Plan.

From the user's perspective, the process feels complete.

Behind the scenes, however, several systems still need to work together.

A modern AI product might execute a flow like this:

Payment Succeeded
        ↓
Create or Update Entitlements
        ↓
Assign AI Credits
        ↓
Enable Premium Features
        ↓
Authorize API Access
        ↓
Track Usage
        ↓
Consume Credits
        ↓
Apply Top-Ups
        ↓
Update Remaining Balance
        ↓
Authorize the Next Request

Notice something interesting.

The payment itself only appears once.

Everything that follows is part of the monetization infrastructure.

This is why many founders discover that accepting payments is actually the easy part.

The difficult part is making sure every customer receives exactly the access they purchased, every usage event is tracked correctly, and every future request is evaluated against the current state of their account.

As products grow, this workflow becomes increasingly dynamic.

Customers upgrade plans.

They purchase additional credits.

Subscriptions expire.

Promotional access is granted.

Usage limits change.

The monetization layer has to keep all of this synchronized in real time.

Why AI products make this much harder

Traditional SaaS products often have relatively simple rules.

A customer purchases a plan.

The plan unlocks a few features.

That's usually enough.

AI products introduce a different level of complexity.

Usage is rarely constant.

Infrastructure costs are variable.

Customers consume resources in very different ways.

A single customer might generate:

thousands of API requests
millions of LLM tokens
hundreds of images
dozens of videos
long-running AI agent workflows

Meanwhile, another customer on exactly the same subscription may barely use the product.

This creates a new challenge.

The system must continuously answer questions such as:

Does this customer still have credits?
Are they allowed to access this model?
Has their monthly limit been reached?
Did they purchase additional usage?
Has their subscription expired?
Should this request still be authorized?

None of these questions are answered by the payment processor.

They belong to the application's monetization layer.

Why AI products make monetization more difficult

Not every AI product faces the same monetization challenges.

Some products have relatively predictable usage patterns.

Others execute dozens of billable operations from a single user action.

The more dynamic the product becomes, the more important your monetization infrastructure becomes.

Here's a simplified view.

Product Type	Monetization Complexity
AI Image Generation	Medium
AI Video Generation	Medium
AI Chat Applications	High
AI APIs	Very High
AI Voice Applications	Very High
AI Agents	Extremely High

The reason isn't the payment model.

It's what happens after the payment.

Why AI Agents are especially challenging

Imagine a user asks an AI agent to:

"Analyze this PDF, summarize it, search the web for related information, and send me a report."

From the user's perspective, that's a single request.

From your infrastructure's perspective, it might trigger:

Multiple LLM calls
Web searches
Vector database queries
Background jobs
File processing
External APIs

One user action can easily generate dozens of internal operations.

Now imagine trying to answer questions like:

How many credits should this consume?
Should every step be tracked?
What happens if one tool fails?
What if the workflow retries halfway through?
Should partially completed work still be billed?

These aren't payment questions.

They're monetization questions.

AI Voice products introduce similar challenges

Voice applications follow a similar pattern.

A single conversation may include:

Speech-to-text
One or more LLM requests
External tool execution
Text-to-speech generation

Each step has its own infrastructure cost.

Each step may need to be tracked.

Each step may contribute to the customer's remaining balance.

As voice applications become more sophisticated, usage tracking becomes increasingly important.

API products scale faster than billing systems

API-first products face another challenge.

Usage grows much faster than billing complexity.

One customer may send:

500 requests per month.

Another may send:

5 million requests.

The payment might be exactly the same.

The infrastructure cost certainly isn't.

This is why many API products eventually introduce:

Usage limits
Credits
Metered billing
Rate limits
Real-time authorization

The payment defines the commercial agreement.

The monetization layer determines whether each individual request should be allowed.

Why image and video products are often easier to model

Image and video generation products can still become expensive.

But their billing logic is often more straightforward.

A generation request usually maps directly to a predictable unit of consumption.

For example:

Generate Image
        ↓
Consume 10 Credits
        ↓
Return Result

Or:

Generate Video
        ↓
Consume 100 Credits
        ↓
Return Result

The relationship between user action and infrastructure cost is much easier to understand.

That doesn't eliminate monetization challenges.

It simply reduces the number of moving parts compared to agents or API workflows.

Common implementation mistakes

As AI products evolve, many teams run into the same architectural problems.

Not because they're inexperienced.

Because these problems rarely exist during the MVP stage.

Treating payment as authorization

A successful payment doesn't automatically define what a customer can do.

It only confirms that a financial transaction occurred.

Your application still needs to determine:

Which features are available
Which AI models can be used
Whether API access should be enabled
Whether credits are available
Whether limits have been reached

Payment and authorization should remain separate concerns.

Checking the payment provider on every request

A common pattern looks something like this:

if (subscription.active) {
    allowRequest();
}

It works at first.

But over time, questions become more complicated.

What if the customer has purchased additional credits?

What if they have temporary promotional access?

What if they have consumed their monthly allowance?

What if an administrator manually granted access?

Very quickly, a simple subscription check becomes difficult to maintain.

No usage tracking

If you don't know exactly what customers are consuming, you can't reliably answer questions like:

How many credits remain?
Which requests generated costs?
Why was a balance reduced?
Where did infrastructure costs come from?

Usage tracking becomes the operational foundation of AI monetization.

No audit trail

Eventually every growing product receives support requests like:

"Why can't I access GPT-4 anymore?"

Or:

"Where did my credits go?"

Without an audit trail, those questions become difficult to answer.

With one, every permission change, credit assignment and usage event can be traced back to its source.

As products grow, auditability becomes just as important as billing itself.

The monetization layer

As AI products grow, an interesting pattern starts to emerge.

Teams often realize they're maintaining two completely different systems.

The first handles money.

The second handles everything that happens after money.

You can think about it like this:

Payments Infrastructure
────────────────────────
• Checkout
• Invoices
• Subscriptions
• Payment Processing

                ↓

Monetization Infrastructure
────────────────────────
• Credits
• Entitlements
• Usage Tracking
• Usage Ledger
• Access Control
• Real-Time Authorization

Both layers are equally important.

The first answers questions like:

Did the customer pay?
Was the subscription renewed?
Was the invoice successful?

The second answers questions like:

Can this customer use GPT-4?
Do they still have credits available?
Has their monthly limit been reached?
Should this API request be allowed?
Should access expire today?

These are completely different responsibilities.

And as products become more sophisticated, keeping them separate makes systems easier to evolve, easier to debug, and easier to scale.

Building a reliable monetization layer

There isn't a single architecture that works for every AI product.

An AI image generator has different requirements than an AI agent platform.

An API business has different constraints than a voice application.

But across many successful products, the same building blocks appear repeatedly.

Component	Responsibility
Payments	Collect money
Credits	Allocate usage
Entitlements	Define permissions
Usage Tracking	Record consumption
Usage Ledger	Maintain an auditable history
Access Control	Decide what users can do
Real-Time Authorization	Evaluate every request

Each component solves one specific problem.

Together, they create a monetization system that remains reliable as the product grows.

The goal isn't to make billing more complicated.

It's to ensure that every payment results in the correct customer experience, every usage event is accounted for, and every request is evaluated against the customer's current state.

That's what allows AI companies to scale confidently without gradually accumulating billing inconsistencies or revenue leakage.

Final thoughts

For years, online payments were one of the hardest problems software companies had to solve.

Today, that's no longer true.

Modern payment providers have made accepting payments remarkably simple.

The difficult part now begins after the transaction succeeds.

AI products need to decide:

what customers can access
how much they can consume
how usage is tracked
when access changes
when credits should be deducted
when additional usage should be allowed

Those decisions happen long after the payment has been processed.

That's why modern AI monetization isn't just about charging customers.

It's about building the infrastructure that connects payments, permissions, usage, and authorization into a single reliable system.

Payment processing is no longer the hard part.

Building everything that happens after payment is.

Learn More

As AI products become more sophisticated, many teams eventually need infrastructure for:

Credits
Usage Tracking
Entitlements
Access Control
Real-Time Authorization

Some teams build these systems internally.

Others adopt dedicated infrastructure platforms that provide these capabilities out of the box.

Platforms such as Licenzy focus on these operational layers, helping product teams manage credits, usage tracking, entitlements, and authorization while allowing developers to spend more time building customer-facing features instead of rebuilding monetization infrastructure.

Why Most AI Startups Don't Use Subscriptions Alone

Ciroandrea — Mon, 22 Jun 2026 08:05:55 +0000

When founders launch an AI product, the first pricing model is usually obvious.

A monthly subscription.

$19/month.

$49/month.

$99/month.

Simple.

Predictable.

Easy for customers to understand.

And for many products, it works.

At least initially.

But after looking at dozens of AI startups, a pattern starts to emerge.

Many companies begin with subscriptions.

Very few rely on subscriptions alone forever.

Instead, a different model increasingly appears:

Subscription
      +
Credits
      +
Top-Ups

This isn't a universal rule.

But it's a pattern that shows up repeatedly across AI products.

The reason is simple.

AI costs behave differently than traditional software costs.

Why subscriptions are attractive at the beginning

Subscriptions solve several important problems.

They create predictable recurring revenue.

Customers understand them immediately.

Billing is straightforward.

Forecasting becomes easier.

A founder launching an AI product can usually implement a subscription model quickly and start validating demand.

For early-stage startups, simplicity is often more important than perfect monetization.

That's why many products start here.

The challenge appears when usage grows

The problem is that AI products often have highly uneven usage patterns.

Consider two customers paying the same monthly fee.

Customer	Monthly Fee	Usage
Customer A	$49	Occasional
Customer B	$49	Heavy Daily Usage

Revenue is identical.

Cost is not.

The second customer may consume dramatically more infrastructure resources.

As usage grows, margins become harder to predict.

This is especially true when products rely on external AI providers.

Every request has a cost.

Every token has a cost.

Every generation has a cost.

Subscriptions alone don't always reflect that reality.

Why AI costs are often variable

Traditional SaaS products often have relatively stable operating costs.

AI products don't.

A single customer might:

Generate thousands of images
Run an AI agent continuously
Process large volumes of voice data
Send millions of API requests

Another customer on the same plan might barely use the product.

This creates a mismatch between revenue and consumption.

The larger the gap becomes, the harder pricing becomes.

Why credits solve part of the problem

This is where credits often enter the picture.

Credits allow companies to connect usage with value.

Instead of offering unlimited consumption, a product can allocate a specific amount of usage.

For example:

Plan	Included Credits
Starter	1,000
Pro	10,000
Growth	50,000

Customers still enjoy the simplicity of a subscription.

At the same time, usage becomes measurable.

This creates a healthier relationship between revenue and infrastructure costs.

Why top-ups eventually become necessary

Credits solve part of the monetization challenge.

But another problem quickly appears.

Some customers use more than expected.

Imagine a customer on a Pro plan receiving 10,000 credits per month.

What happens when they consume all 10,000 credits after two weeks?

Several options exist:

Block usage
Force an upgrade
Sell additional credits

Many AI startups choose the third option.

This is where top-ups appear.

Customers purchase additional credits without changing plans.

The result is a model that combines:

Predictable subscription revenue
Usage-based flexibility
Additional monetization opportunities

Why AI Agents are difficult to monetize

AI Agents introduce another layer of complexity.

A single user action may trigger:

Multiple model calls
External APIs
Background jobs
Tool execution

One action can generate dozens of billable events.

The relationship between user actions and costs becomes less obvious.

As a result, unlimited subscriptions often become difficult to sustain.

Credits help create boundaries around consumption.

Why AI Voice products face similar challenges

Voice applications often combine multiple expensive services.

A conversation may include:

Speech-to-text
LLM processing
Tool execution
Text-to-speech

Each component contributes to cost.

Heavy users can quickly consume significantly more resources than average customers.

This makes usage-aware pricing increasingly attractive.

Why AI APIs often adopt usage-based models

API businesses are naturally usage-driven.

Customers may generate:

Thousands of requests
Millions of requests
Billions of tokens

The gap between customers can be enormous.

This is one reason why many API businesses eventually introduce:

Usage limits
Credits
Metered billing
Consumption-based pricing

Subscriptions alone often struggle to capture that variability.

Why AI Image and AI Video products often have simpler economics

Image and video products can still be expensive.

However, their billing models are often easier to understand.

A generation usually maps directly to a cost.

For example:

1 Image
     ↓
10 Credits

Or:

1 Video
     ↓
100 Credits

The relationship between action and consumption is more transparent.

This makes monetization easier to communicate to customers.

The challenge still exists.

It's simply easier to model.

The pattern emerging across AI startups

Looking across AI startups, a recurring pattern appears.

Many products start with subscriptions.

As usage grows, credits are introduced.

As power users emerge, top-ups follow.

The resulting model often looks like this:

Component	Purpose
Subscription	Predictable recurring revenue
Credits	Usage allocation
Top-Ups	Additional consumption

This approach allows companies to balance:

Customer simplicity
Revenue predictability
Variable infrastructure costs

It's not the only model.

But it's one that appears increasingly often across AI products.

Why infrastructure eventually becomes necessary

As monetization becomes more sophisticated, new requirements emerge.

Teams eventually need systems for:

Credits
Usage tracking
Usage limits
Entitlements
Access control

The pricing model becomes only one part of the equation.

The infrastructure required to enforce that pricing becomes equally important.

Final thoughts

Many AI startups begin with subscriptions because subscriptions are simple.

Customers understand them.

Founders can launch quickly.

But AI products introduce a challenge that traditional SaaS products often don't face:

Usage can vary dramatically between customers.

As a result, subscriptions alone frequently become insufficient.

That's why an increasing number of AI companies are adopting a hybrid model:

Subscription
      +
Credits
      +
Top-Ups

Not because subscriptions are broken.

But because balancing predictable revenue and variable costs becomes increasingly important as products grow.

Learn More

As products evolve beyond simple subscriptions, many teams eventually need infrastructure for:

Credits
Usage tracking
Entitlements
Access control
Usage-based billing

Platforms such as Licenzy focus on these operational layers so teams can concentrate on building products rather than rebuilding monetization infrastructure from scratch.

How is your AI product handling the gap between predictable revenue and unpredictable usage? Have you stayed subscription-only, or introduced credits and top-ups?

How AI Products Lose Revenue Without Realizing It

Ciroandrea — Mon, 15 Jun 2026 08:55:09 +0000

Your pricing model can be perfect.

Your subscription plans can be perfectly designed.

Your checkout flow can convert beautifully.

And you can still lose money.

Not because customers aren't paying.

Because your product is tracking usage incorrectly.

This problem is called revenue leakage.

And it's surprisingly common in AI products.

Most founders spend months thinking about pricing.

Far fewer spend the same amount of time thinking about what happens after a customer starts using the product.

Yet that's often where margins quietly disappear.

Why this matters

Imagine a simple AI product.

Metric	Expected
Monthly Revenue	$20,000
AI Costs	$12,000
Expected Profit	$8,000

Everything looks healthy.

Now imagine:

3% of usage is never recorded
2% of requests are processed twice
1% of expired customers continue using premium features

The product still generates revenue.

Customers are still paying.

But profit starts shrinking.

Metric	Actual
Monthly Revenue	$20,000
AI Costs	$12,500
Revenue Leakage	-$500
Real Profit	$7,000

Nothing looks broken.

Yet the business is earning less than it should.

That's what makes revenue leakage dangerous.

It usually doesn't arrive as a catastrophic failure.

It arrives as hundreds of tiny mistakes that slowly compress margins.

What is revenue leakage?

Revenue leakage happens when a product delivers value without correctly tracking, billing, limiting, or authorizing that usage.

In simple terms:

The customer receives something, but the business fails to capture the corresponding revenue.

Common examples include:

Issue	Revenue Impact
Duplicate requests	Usage recorded incorrectly
Retry processing	Credits deducted multiple times
Missing usage events	Unbilled consumption
Billing mismatches	Usage exceeds billing records
Access not revoked	Continued free usage
Webhook duplication	Inconsistent balances

Most companies don't notice these issues immediately.

They become visible only after usage grows.

Why AI products are especially vulnerable

Traditional SaaS products often have relatively predictable economics.

AI products don't.

Every request has a cost.

Every token has a cost.

Every image generation has a cost.

Every video generation has a cost.

Every agent execution has a cost.

This means usage tracking is no longer an analytics problem.

It's a revenue problem.

If usage tracking becomes inaccurate, your business economics become inaccurate.

That's why revenue leakage tends to be far more common in AI products than in traditional SaaS applications.

Which AI products are most exposed?

Not all AI products face the same level of risk.

Some business models are naturally more vulnerable than others.

Product Type	Revenue Leakage Risk
AI Image Generation	Medium
AI Video Generation	Medium
AI Chatbots	High
AI APIs	Very High
AI Agents	Extremely High
AI Voice Agents	Extremely High

Let's look at why.

Why AI Agents are especially vulnerable

An AI agent rarely performs a single operation.

A single user request can trigger:

Multiple LLM calls
External API requests
Database operations
Tool executions
Background jobs

One action from the user may generate dozens of billable events.

If even a small percentage of those events are not tracked correctly, margins begin to drift.

The complexity grows exponentially as workflows become more sophisticated.

Why AI Voice products are difficult to monetize correctly

Voice applications often combine multiple systems.

A single conversation may include:

Speech-to-text
LLM processing
Tool execution
Text-to-speech

Each stage has its own cost.

Each stage may generate separate usage events.

Missing just one event can create a mismatch between delivered value and captured revenue.

Why AI APIs are particularly sensitive

API businesses are often usage-driven by nature.

Customers can generate thousands or millions of requests.

At that scale, small inaccuracies become expensive.

A tracking error affecting 0.1% of requests may seem insignificant.

At millions of requests per month, it becomes a real financial problem.

For API-first products:

Usage tracking is revenue infrastructure.

Why AI Image and AI Video products are usually safer

Image and video products are not immune to revenue leakage.

However, their workflows are often easier to model.

A generation request typically follows a simple flow:

Request
    ↓
Generation
    ↓
Credit Deduction

The relationship between user action and billing is more direct.

That doesn't eliminate the risk.

It simply makes inconsistencies easier to detect.

How revenue leakage silently destroys margins

The dangerous part about revenue leakage is that it rarely creates obvious failures.

The product continues working.

Customers remain happy.

Revenue continues arriving.

Yet profitability slowly declines.

Many teams spend months optimizing pricing while unknowingly losing more money through poor tracking than they would ever recover through pricing experiments.

This is why monetization is not only about pricing.

It's also about operational accuracy.

Common implementation mistakes

Most revenue leakage originates from a small number of architectural decisions.

Treating credits as a balance only

Many systems start with:

user_id
credit_balance

This works initially.

But eventually someone asks:

Why do I have fewer credits than expected?

At that point, the balance alone is not enough.

You need history.

No usage ledger

Without a usage ledger, there is no reliable audit trail.

Questions become difficult to answer:

Which action consumed credits?
When?
Why?
Was it processed twice?

Modern systems typically record every movement.

No idempotency

Retries happen.

Clients reconnect.

Network failures occur.

Without idempotency:

1 request
2 executions
2 deductions

Small errors accumulate quickly.

Using Stripe as access control

Many products repeatedly ask:

Is this subscription active?

Instead of asking:

Does this user have access?

Payments and access are different concerns.

Mixing them often creates fragile systems.

No entitlement model

Many products manage:

Users
Plans
Payments

But never explicitly model permissions. Entitlements are often the missing layer between payments and access.

Eventually feature access becomes difficult to maintain.

How modern AI products prevent revenue leakage

Successful AI products usually separate responsibilities.

A common architecture looks like this:

Payments
    ↓
Entitlements
    ↓
Access Control
    ↓
Product Usage
    ↓
Usage Tracking
    ↓
Usage Ledger

Each layer solves a specific problem.

This separation dramatically reduces revenue leakage.

The role of idempotency

Idempotency ensures that the same event cannot be processed twice.

For example:

{
  "usage_id": "req_12345"
}

If the request is received again, the system recognizes it and ignores duplicates.

This single concept prevents many revenue leakage scenarios.

Why audit trails matter

Eventually every product receives support tickets like:

Why was I charged for this?

Or:

Where did my credits go?

Without an audit trail, answers become guesses.

With a proper usage ledger, every movement can be explained.

Auditability becomes increasingly important as products scale.

Why entitlements and access control matter

Revenue leakage isn't only about usage tracking.

It's also about ensuring customers only receive what they purchased.

A customer should only access:

Features they purchased
Models they purchased
Limits they purchased
Credits they purchased

Entitlements define permissions.

Access control enforces them.

Together they reduce unauthorized usage and billing inconsistencies.

Final thoughts

Most AI companies spend enormous effort optimizing pricing.

Far fewer spend the same effort protecting revenue.

Yet pricing is only one side of the equation.

The other side is ensuring every unit of value delivered is:

Tracked
Accounted for
Authorized
Auditable

Revenue leakage often starts with small mistakes.

Duplicate requests.

Retries.

Missing usage events.

Access control gaps.

Over time those small issues compound.

And that's why many AI products lose revenue without realizing it.

Learn More

As AI products scale, many teams eventually build internal systems for:

Others choose specialized platforms that provide these capabilities out of the box.

The important part is not the implementation itself.

It's ensuring that usage, access, and revenue remain aligned as the product grows.

If you're interested in the technical side of these systems, documentation covering usage tracking, entitlements, access control, and usage-based billing can be a useful next step.