From Token Spend to Workflow Economics: What BCG’s Return-on-AI Framework Requires

A token bill can tell you what inference cost. It cannot tell you whether the work was accepted, whether a human had to redo it, or whether the business outcome arrived two weeks later. Managing AI economics requires a new unit of control: the workflow run, joined to its eventual outcome.

BCG makes a useful move: stop treating the token as the unit of management and start measuring the cost of a successful outcome. Its return-on-AI framing puts economic return over the combined cost of human intelligence and tokens. It also argues for a workflow-level operating model that can see spend, shape cost, and prove value—or stop the activity.

The idea is sound. The hard part is implementation.

Model gateways observe requests. Agent runtimes observe turns, tools, retries, and pauses. Finance sees invoices. Business systems observe whether a case closed, a payment settled, a pull request shipped, or an escalation reopened. None of those records, alone, is return on AI.

1. The token is a billing unit, not a business unit

Tokens remain essential telemetry. They explain input size, output size, cache behavior, and part of the cost of a model call. But they do not have stable business meaning across models or providers. Tokenizers differ. Input, output, cached input, cache creation, reasoning, audio, and other modalities can carry different billing rules. A million units in one product is not automatically equivalent to a million units in another.

Even within one pricing category, where billed cost may scale linearly with token volume, workflow economics need not. A larger context can change model behavior. A cheaper model can trigger more retries. A concise answer can increase human review. A cache hit can remove an inference call but return an answer that is stale for the user’s current state. An agent can enter a tool loop that spends little per call and a great deal per resolved case.

BCG identifies four interacting cost forces: adoption breadth and depth, task intensity, context and loops, and model mix. That framing matters because each force exists above the individual request. A single request is often too small to show the work; a monthly provider invoice is too large to assign responsibility or value.

2. Define two contracts before building the dashboard

A credible workflow-economics system begins with two explicit contracts: a cost envelope and an outcome contract. The first says which resources count. The second says what success means. If either remains implicit, cost-per-outcome becomes a number with an unstable denominator or a negotiable numerator.

The cost envelope

For each workflow run, capture the costs that materially change the decision. That usually includes model inference, tool and infrastructure usage, human oversight, and failure or rework. The categories should be mutually exclusive or governed by an allocation rule so the same correction time is not counted twice. The goal is not false precision. Human time, for example, may be sampled by workflow and role instead of metered for every click. The requirement is consistency: use the same inclusion rules when comparing policies.

‍