The economics of AI workflows belong in product strategy

AI product conversations often use the price of a model call as shorthand for economics. That number is easy to retrieve and easy to misunderstand.

A useful unit of cost needs a workflow, a customer and a period of time. It should include the pattern of calls around the model: retries, batch work, enrichment, recovery and the human review that remains.

FundRobin’s production telemetry made this concrete for me. The important insight did not come from finding the cheapest model. It came from separating two different cost regimes that had been mixed together.

A backfill can distort the story

At one point, historical usage included a substantial one-off matching backfill. Looking at that period without context made the product appear to have a higher ongoing inference cost than the current workflow actually carried.

The backfill was real spend. It was poor evidence for steady-state unit economics.

This distinction matters whenever an AI product performs setup work for a new customer or migrates an existing dataset. The first useful experience may require a burst of classification, matching or enrichment. Later maintenance may only process new or changed records.

Blending those phases into one average hides the decision the product team needs to make.

Cost should follow the customer lifecycle

For the FundRobin matching and onboarding path captured in the current profile evidence, recent telemetry showed roughly US$0.38 during an organisation’s first seven days and about US$0.25–0.30 per month in steady-state maintenance.

Those figures are deliberately narrow. They are not total cost to serve, and they should not be applied to every FundRobin feature. Their value comes from connecting a defined workflow to a defined stage in the customer lifecycle.

That let me frame better questions:

• Is the initial burst producing activation value?
• Does a longer trial materially change inference cost?
• Which maintenance tasks run because the customer benefits, and which run because the system lacks a better trigger?
• Are retries and fallbacks changing the apparent unit cost?
• Would a cheaper model path increase review or recovery work elsewhere?

The telemetry becomes a product input once it can answer questions like these.

Cheap inference does not make a weak workflow worthwhile

The recorded steady-state cost is small enough that model spend is not the main constraint on trial length. Activation design matters more. A customer needs enough time and guidance to reach a useful result.

That conclusion prevented the team from optimising the wrong variable. Cutting a few cents from a workflow would have little value if organisations failed to complete the profile, understand a match or take the next meaningful action.

The reverse can also be true. A workflow with low visible usage may create hidden cost through repeated polling, duplicate work or manual support. Cost needs to be read alongside lifecycle and outcome data.

Routing is an economic policy

Model selection is often described as a quality decision. In a production workflow it is also an allocation policy.

Some tasks deserve stronger reasoning because ambiguity is high and the decision is valuable. Some tasks can use a cheaper structured path. Some should be deterministic. Batch processing may reduce cost where latency is unimportant. Provider fallback may protect continuity while introducing a different quality or price profile.

The product team should decide those trade-offs. Leaving them to an implementation default makes cost policy accidental.

I prefer to start with the task:

1. What uncertainty requires model reasoning?
2. What is the consequence of a weak answer?
3. How quickly does the customer need the result?
4. Can the output be checked automatically?
5. What does recovery cost when the path fails?

The routing choice follows from the answers.

Financial modelling helped, but the unit changed

Earlier in my career at BT, I used product profitability and lifecycle analysis to support investment, continuation and closure decisions across a large portfolio. The discipline transfers well to AI products: define the economic unit, allocate the relevant costs and avoid treating an average as an explanation.

The unit itself is different. AI workflows can have variable inference cost, asynchronous work and a mix of deterministic and probabilistic stages. A product may spend more during onboarding, settle into a low maintenance pattern and then incur another burst when the underlying data changes.

This makes stage-based economics more useful than one blended “cost per user” number.

Telemetry should preserve the reason for the spend

A usage log is more valuable when it can be connected to the customer, workflow, job state, provider and outcome. Otherwise it becomes a bill with no decision attached.

I want to distinguish:

• expected first-run work from repeated failure;
• customer-triggered activity from scheduled maintenance;
• completed work from unfinished attempts;
• primary routing from fallback;
• useful output from output that was discarded or overridden.

This level of context supports cost control without turning the product into a finance dashboard. It tells the team where a design change could improve both economics and experience.

AI economics is product strategy in operational form

The strategic question is not “How cheap is the model?” It is “What work are we buying, for whom, at which point in the lifecycle, and what decision does that work improve?”

Once the cost is tied to a workflow, it can shape trial design, routing, prioritisation and pricing. It can also reveal when the team is solving an infrastructure problem that does not materially affect the customer.

That is where AI telemetry earns its place in product strategy: it turns variable technical consumption into a choice about value.

Related ideas

• AI workflow reliability — Why recovery and fallback costs belong in product decisions.
• AI product workflow design — Why model spend only makes sense inside a complete workflow.

Sources and further reading

1. Claude pricing — Anthropic
2. Generative AI pricing — Google Cloud
3. Amazon Bedrock pricing — Amazon Web Services