The AI Unit-Economics Ledger — Free Executive Playbook

Free executive playbook.

Your AI got cheaper. Much cheaper. And your bill did not go down. That is not a billing error, and it is not a cost problem either — it is a forecasting problem, which is worse. A cost problem can be budgeted; you can decide to spend more. A forecasting problem cannot, because there is no number to put in the budget. Frontier model prices really have fallen roughly eighty percent from their March 2023 base — BenchLM Token Price Index, frontier sub-index, data from BenchLM.ai — and Gartner still forecasts inference cost per agentic workflow rising more than fivefold through 2028 — the mechanism it named in August 2026 and called the Inference Paradox: better unit economics subsidise more complex workflows, so the total climbs even as each unit gets cheaper. The reason the two numbers came apart is architectural rather than commercial. A price per token describes an input; a bank buys outputs — a reconciliation finished, a case resolved, a document checked, an exception cleared — and an agent produces those by planning, calling tools, checking its own work and retrying, re-reading everything it has already done on every turn of that loop. The AI Unit-Economics Ledger puts the four lines a bank has to forecast on one page, ordered by when a bank finds out about them — approval, integration, production, audit — each with what it is, why it under-reads, and an accountable owner. One refusal rule holds it together: approve nothing that forecasts only line one. It is the author's proposed decomposition, not a ratified standard.

What's inside

• The reframe — a single-shot assistant against an agent with tool use, compared across the five rows that decide a forecast: work per user request (one model call · against many — planning, tools, retries, self-checks) · what drives the cost (output tokens, what it writes · against input tokens, the context it re-reads each turn) · scaling behaviour (roughly linear in usage · against superlinear in task complexity) · forecastability (a price times a volume · against a distribution, up to thirty-times spread on the identical task) · and where the business case looks (exactly at the first column, almost never at the second). The measured consequence, stated with its scope: agentic workloads consumed roughly one thousand times more tokens than a code-chat or code-reasoning task, with input rather than output driving the cost — Bai et al., arXiv:2604.22750, measured on eight frontier models against a software-engineering benchmark. The agent is not expensive because of what it writes; it is expensive because of what it keeps re-reading · plus why this hides so well: two of the four lines do not scale with users at all. Retrieval scales with the size and churn of the corpus; orchestration scales with task complexity. Both are therefore invisible in exactly the arithmetic a per-user case was built on, so the bank does not overspend — it mis-forecasts, and finds out from the invoice
• The ledger — all four lines, with what each is, why it under-reads, the gate a bank finds it at, and its accountable owner. Four, not six, because a chief financial officer can hold four lines in their head and a template nobody completes is not a control. L1 · Inference (the model call: input, output, cached input, reasoning tokens where they are billed separately, list against committed against negotiated — the only line most cases contain and the line whose unit price has fallen furthest, which is exactly why it flatters the forecast; found at approval, owner platform and architecture) · L2 · Retrieval and context (embedding and re-embedding on change, vector storage and query cost, re-ranking, the context resent on every call — it scales with corpus size and churn, not user count, so it appears nowhere in a per-user case; found at integration, owner data and knowledge) · L3 · Orchestration (the multiplier: planning steps, tool calls, retries, self-checks, multi-agent handoffs — where non-linearity actually lives and the least modelled line in the ledger; found in production, which is the worst possible place to find it, owner engineering) · L4 · Run, assure and review (Run: observability, tracing, drift · Assure: judge models and the regression and red-team suites re-run on every release · Review: exception handling, escalation, disputes, appeals — all three routinely treated as build costs when all three recur, assurance per release and review per exception; found at audit, owner operations and risk) · plus the reason Review is named deliberately, and is the limb most often deleted: review is where the headcount saving a business case promised either survives or quietly disappears, and a line called "run and assure" reads as infrastructure and gets delegated to engineering, where a line called "run, assure and review" cannot be · and where the compliance load lands: Vietnam's AI Law 134/2025/QH15 — passed 10 December 2025, in force 1 March 2026 — carries duties of transparency and of incident detection and remediation, and, for systems classified high-risk, duties of human oversight and human intervention. Article 35(1)(a) gives an eighteen-month transition, to 1 September 2027, only to AI systems already in operation before 1 March 2026 in finance, healthcare and education — a new deployment does not inherit it, and what the transition defers is compliance obligations on systems already running rather than the cost of building the capability. The impact-assessment duty a bank actually carries is the personal-data regime's, not the AI Law's: PDPL Article 21(1) requires a personal-data processing impact assessment filed within sixty days of first processing, unconditionally, and updated every six months on change. All of these are recurring operating costs rather than a one-off compliance project, and human oversight is simultaneously a legal duty and the Review limb. Separately, PDPL 91/2025/QH15 cross-border provisions are the clearest driver of topology cost we can identify — they can force a more expensive deployment than a public API, which is an L1 and L2 architecture cost, and that cost reading is the playbook's assessment rather than a sourced finding
• Variance, and the missing denominator — the multiplier is not the worst finding. In the same measurement study the researchers ran the identical task more than once, not variations of it, and token consumption varied by up to thirty times: the same reconciliation, run on Tuesday and again on Thursday, can differ by a factor of thirty, and nothing in the change log will explain why. So an invoice for a piece of work is a distribution rather than a figure · and the obvious workaround is closed, because the same researchers tested whether frontier models can predict their own token usage and the correlations were weak to moderate — up to zero point three nine — with the models systematically underestimating their real costs. The model does not know what it is about to spend either, which is why negotiating a better rate does not fix it: the rate was never the issue, the collapse in the rate already happened, and what a bank currently cannot do is predict the quantity · plus what the FinOps standard does and does not define. The FinOps Open Cost and Usage Specification — FOCUS — standardises billing and usage dataset schemas across AI, cloud, SaaS and data-centre providers. It defines columns, not key performance indicators: AI consumption travels through generic consumed-quantity and consumed-unit fields, so a token, a request and a seat all become comparable line items whoever billed them. What it does not define is cost per completed task, and it never claimed to — unit-cost analysis is explicitly a practitioner exercise built on top of the normalised data, and an open issue on the specification's own repository records that practitioners still lack worked examples for mapping token consumption into those columns: a documented gap inside the standard rather than an absence of evidence. FOCUS makes the numerator comparable; the denominator is yours, which is the entire reason a ledger is necessary
• The headcount question — what the public record supports, and what it does not. The widely-cited cases about replacing hundreds of service agents trace back to the deploying companies' own announcements and to their technology suppliers, presented as forward-looking projections rather than audited results. Where those projections have later been revisited, the revision has run downward, and none has been restated as an audited reduction in a regulated process's cost base. The public record does not support a sustained net reduction in the cost base of a regulated banking process through headcount substitution. The mechanism explains why, and it is more useful than any single case: automating the straightforward path leaves the hard residue — disputes, exceptions, appeals — and that work needs more expensive people than the entry-level triage it replaced. The cost did not vanish; it moved into line four, where nobody forecast it · no figure and no company is named here, deliberately, because the numbers in circulation are the announcing parties' own projections, and a projection is not a measurement
• The forecast audit — six questions, one afternoon, one approved business case, each paired with what a failing answer actually looks like, so the output is not a number but a list of the lines your institution cannot currently see. Where is L1, and is it list, committed or negotiated pricing (failing: it is there — this one always passes, which is the problem) · was L2 forecast against corpus growth and churn rather than user growth (failing: a per-user or per-seat number, because the case never modelled the corpus at all) · what is the L3 multiplier, model calls per user request, measured (failing: nobody can produce it, so the case has no denominator) · what does L4 cost per release and per exception, with the three limbs separated (failing: assurance booked as a build line item, and Review absent entirely) · what is the variance, not the average (failing: a single point estimate for a workload with a documented thirty-times spread) · and who is the named owner of each line's forecast (failing: "Technology" — a function is not a person) · then the refusal rule for the investment committee: when only line one is forecast, leaders should send the case back, not because the bill is too large but because it is not a forecast at all — it is an estimate wearing a forecast's clothes

Five pages · free with a member sign-in · PDF.

Two honest limits are carried in the downloadable edition as well as here, because they bound what the ledger can claim. Where this framework does not hold: a bank with genuine engineering maturity — disciplined inference tiering, cache-aware agent architecture — can make falling per-unit prices outrun orchestration bloat. The controls are real: prompt caching has measured support in the literature (arXiv:2601.06007), and model routing is Gartner's own recommended remedy, which makes routing a control rather than a refutation. So the binding constraint may be talent, not price — very few traditional commercial banks run those architectures in production today, and that is the strongest argument for the ledger rather than against it, because a bank that cannot yet engineer the optimisation must at minimum measure the exposure. And on scope: the strongest measurements available — the thousandfold multiplier, the review concentration, the thirty-times variance — were taken on agentic coding tasks. The mechanism generalises; the specific magnitudes should not be assumed to transfer unchanged to a credit file or a reconciliation.

What is deliberately not in this playbook. No bank technology-budget figure. No vector-database or observability unit pricing. No accounting treatment. No banking-circular transaction thresholds. No named bank. Each was offered by this week's research, each was checked against a primary source, and each was excluded because the source would not carry the claim. A figure that cannot carry its conditions does not appear.

Watch: youtu.be/lkfZWBZcUxI — Video 17: Why cheaper AI cost more, 8 minutes 0 seconds.

Want the weekly version? Subscribe to The AI Architect Letter · Read the full analysis · Read the latest insights.