Part I · The Argument

A Science and Its Discipline

Opening case

The discipline that changed its mission

Dated: February 2026. Figures and the quotation checked against the Foundation’s report and announcement, October 2026.

In February 2026, the FinOps Foundation changed its mission statement. For years, it had described its purpose as “advancing the people who manage the value of cloud.” The new statement replaced one word: “advancing the people who manage the value of technology.”⁠¹1 FinOps Foundation, “A One Word Change: How the FinOps Community Made Our Mission Evolution Inevitable,” February 19, 2026, accessed October 17, 2026. The mission statement before and after the change.

The change accompanied the Foundation’s annual survey of its practitioners, the people inside companies who manage cloud spending for a living. The 2026 survey reached 1,192 respondents responsible for more than $83 billion in annual cloud spending.⁠²2 FinOps Foundation, “State of FinOps 2026,” February 19, 2026, accessed October 17, 2026. Survey size and the cloud spending its respondents manage. Its central finding was how far FinOps had expanded into AI spending: 98 percent of respondents now managed it, up from 31 percent two years earlier.⁠³3 FinOps Foundation, “State of FinOps 2026,” February 19, 2026, accessed October 17, 2026. Share of respondents managing AI spend, 2026 survey against 2024 survey.

FinOps was built to address a specific problem: cloud bills varied with use and arrived after capacity had been consumed.⁠⁴4 FinOps Foundation, “2024 Changes to the Definition of Cloud FinOps,” accessed October 17, 2026. Cloud consumption as variable and tracked after the fact. The discipline developed to make engineering, finance, and business teams jointly accountable for that spending.⁠⁵5 FinOps Foundation, “What is FinOps?,” accessed October 17, 2026. The Foundation’s definition. Its practitioners later took on AI spending, and by 2026 nearly all respondents to the Foundation’s survey were managing it.

Asked whether AI was providing value, one practitioner acknowledged the uncertainty. The report quoted the answer: “No one can answer that question yet.”⁠⁶6 FinOps Foundation, “State of FinOps 2026,” February 19, 2026, accessed October 17, 2026. Practitioner quotation as reproduced in the report.

The quotation expresses the gap Chapters 1 and 2 described, in the words of someone asked to close it. When an organization pays for a metered resource, costs accrue with use, but someone must build a way to measure the value that use returns. FinOps is a capable neighboring discipline that has expanded into work it was not built to govern: the economics of an organization’s AI consumption.

That work requires both a body of knowledge about what is true and a practice that turns that knowledge into action. This book sets out both. Chapter 14 explains how FinOps and that practice divide the work. Until both exist, the practitioner’s question about whether AI is providing value remains unanswered.

3.1The science and the practice

Managers act on claims about how their businesses work. A budget assumes that costs follow usage. A pricing negotiation assumes that the provider has a reason to accept a lower price. A dashboard assumes that the information it displays will change someone’s decisions. When those claims are wrong, careful execution cannot repair the decisions built on them.

Claims like these can remain informal, drawn from experience, rules of thumb, or the last presentation’s slides. That knowledge is useful, but leaving it unstated has a cost: two managers can hold opposing beliefs about the same deployment without being able to identify where they disagree. One might treat Chapter 1’s Cursor licenses as a fixed software expense and the other as metered consumption. Unless they state their claims, neither can identify the fact that would settle the disagreement, so the argument turns on confidence rather than evidence.

Chapters 1 and 2 each ended with an explicit result rather than an opinion. Chapter 1 stated the conditions under which deployed AI is a resource the organization consumes. Chapter 2 stated the conditions under which a scaled deployment cannot be controlled without a governing apparatus.

AI Business Economics is that body of knowledge. It is a science in a specific, limited sense: a set of claims about the business economics of consuming AI, each stated precisely enough to be checked. Here, science does not imply laboratory experiments or certainty. It means that every claim states when it applies, what it concludes, and which other claims it rests on.

Stating when a claim applies makes it useful to a manager. Chapter 1’s result does not say that every use of AI is consumption. It identifies the conditions under which deployed AI behaves as a resource the organization consumes, so a manager can check a deployment against those conditions before relying on the result. Stating those conditions also makes it possible to show when the claim does not apply. Two managers who disagree can then identify the fact that would settle the question.

Chapter 1’s Cursor licenses show this check in practice. Two of the result’s conditions are that the buyer’s cost extends beyond the access price and that measurement makes resource use visible. From June 16, 2025, the individual Pro plan included twenty dollars a month of frontier-model use at the model provider’s rates, and further use was priced at the same rates. For a developer whose frontier-model use ran past that credit, both conditions held.⁠⁷7 Michael Truell, “Clarifying Our Pricing,” Cursor, July 4, 2025, accessed October 17, 2026. The Cursor post describing the plan change of June 16, 2025, as cited in Chapter 1. A manager who still budgeted the licenses as a fixed software expense was treating the access price as the full cost, even though the conditions showed otherwise. Checking those conditions could settle what confidence alone could not.

The book presents the results of this science in numbered panels, as Chapters 1 and 2 did. Each panel states a result in its exact form and carries an identifier, followed by an explanation in plain business language. The panel and its explanation give a manager enough to use the result. Readers who want to examine it further can use the identifier to find its full statement and supporting claims in Appendix A.

Chapter 2’s panel, THM-004, shows what such a result settles and what it leaves open. It formalizes the economic consequence of the third flow’s asymmetry. Once a deployment reaches scale, economic control requires a governing apparatus. Diligence from the people running the deployment is no longer enough. The theorem does not establish the three flows themselves. They are this book’s way of examining a deployment, and the theorem’s conditions do not mention them.

3.2The five functions

A manager can know that consumption drives cost and still have no forecast of next month’s use, no owner for the bill, and no record of which team used what. Knowledge alone does not change what an organization does. A practice connects knowledge to results through methods, roles, and standards, as clinical practice does for physiology and engineering codes do for physics.

Chapter 1 described the problem as a category error. Wherever that chapter’s conditions hold, AI Operations Management addresses the error by managing AI as a resource the organization consumes. The discipline has five functions that follow AI capacity through the organization: buying it, planning its use, recording and assigning consumption, routing it to work, and judging the value it returns. Each function is a capability an organization either has or lacks. Without one, the organization continues consuming but cannot answer the question that function addresses.

The first function, sourcing, matches the AI capacity an organization buys to the requirements of its work. It determines which models and providers serve which work, and on what terms, so the organization neither pays for capability it does not need nor deprives work of capability it requires. A company that sends every request to its most capable model, including requests a smaller model would answer just as well, is paying for capability that work does not need.

Sourcing involves more than choosing a provider. Requirements may include accuracy, speed, cost per request, and ease of connection to the systems that feed a model. Different kinds of work place different weight on each requirement: customer messages may need a fast, inexpensive model, while a contract review may need the most capable one available. An organization that buys one model for all its work has still made a sourcing decision, whether or not anyone made it deliberately.

The second function is planning and budgeting, whose absence proved costly in Chapter 2’s opening case. The organization must state how much AI it expects to consume in the coming period and detect when actual consumption departs from that expectation. A budget is a commitment made in advance. Comparing it with recorded consumption throughout the period makes deviations visible before the money runs out.

An AI budget differs from a license budget because the quantity consumed is not fixed when the budget is set. The plan must therefore state its assumptions about what drives consumption, including how many people or workflows will use the system and how heavily. Managers can then trace a change in spending to a change in one of those drivers while there is still time to act.

The third function, metering and attribution, builds what Chapter 2 called the record flow. The organization must record what was consumed and assign each unit of consumption to the team, product, or purpose it served. Without that assignment, managers can see a cost but cannot trace it to the work that caused it.

The record has two parts: metering counts what was consumed, request by request, while attribution assigns that consumption to the work that caused it. An invoice priced by use can supply an aggregate count; an invoice that reports only seats and charges supplies neither consumption counts nor attribution. Only the organization can attribute consumption, because only it knows which team, product, or customer a request served. Without that record, no one can say whose work caused a cost, and responsibility can remain divided among several groups.

The fourth function is allocation and routing. When capacity is limited, the organization must decide what runs first and send each piece of work to suitable capacity. These choices occur even when no one makes them deliberately. Consider a constructed example: two workflows share a provider account with a fixed rate limit. When their combined demand exceeds the limit, one must wait, even though no one has decided which should take priority. Allocation and routing make that choice deliberate by applying a rule.

Routing and allocation are two sides of one decision. Routing sends each piece of work to suitable capacity, such as a smaller model for routine requests and a larger one for difficult cases. Allocation decides who goes first when capacity is insufficient for everyone. Both require a stated rule that managers can check against the results and change.

The fifth function is holding value to account. Consider a constructed example in which a support team adds an AI assistant to its help desk. At the end of a quarter, the organization should be able to say whether the assistant paid for itself, identifying its costs and returns, the months covered, and the outcome used to judge it. That requires a boundary specifying the costs and value the evaluation counts, the period it covers, and the outcomes against which it measures performance. The organization sets this value boundary for each deployment before spending begins and names one person responsible for knowing the answer.

The boundary matters because the choice of what to count changes the reported return. An evaluation that counts the assistant’s subscription but excludes staff time spent checking its answers reports a higher return than one that counts both. An evaluation that measures only the assistant’s best month rather than the whole quarter can also report a higher return. Setting the boundary in advance prevents those conducting the evaluation from choosing the version they prefer.

Figure 3.1 shows the relationship between the two layers: the science provides the foundation for the discipline’s five functions.

A result about governance changes nothing until an organization builds the apparatus it describes. The science therefore depends on the discipline to put its findings into practice. The discipline depends on the science because careful practice cannot repair a decision built on an incorrect claim.

3.3Where the discipline ends

Chapter 1 set aside three related subjects: how models work, prompt engineering, and finding uses for AI. Each has its own purpose and literature, and each ends before AI Operations Management begins.

The first subject concerns how models work, including their architectures, training, and internal behavior. It belongs to computer science and machine learning engineering and ends where a model becomes a service an organization can call. AI Operations Management begins when the organization can buy and call that service.

The second is prompt engineering, the craft of writing inputs that produce better outputs. It improves individual uses of AI, while AI Operations Management governs their combined consumption, cost, and value. A better prompt can lower the cost of one request. Determining whether the organization’s requests, taken together, are worth what they cost requires the discipline.

The third subject is finding uses for AI: deciding which business problems it might solve. That work belongs to strategy and innovation and ends when a use is chosen. AI Operations Management begins with buying capacity for the chosen use and manages its consumption from then on.

Four established disciplines overlap more directly with AI Operations Management. Each manages an aspect of work related to AI consumption, but each lacks something needed to govern its economics. Table 3.1 compares them.

Table 3.1. The four neighboring disciplines. Each manages work related to AI consumption, but none was built to govern its economics.

FinOps is the closest neighboring discipline, making its boundary with AI Operations Management the hardest to define. It already manages spending, has expanded into AI, and defines its purpose in terms of maximizing the business value of technology.⁠²¹21 FinOps Foundation, “What is FinOps?,” accessed October 17, 2026. The Foundation’s definition, which names business value. Chapter 14 explains how the two divide the work. The distinction rests on what each was built to do, rather than what it intends to achieve. FinOps was built to make cloud spending accountable when bills arrived after capacity had been used.⁠²²22 FinOps Foundation, “2024 Changes to the Definition of Cloud FinOps,” accessed October 17, 2026. Cloud consumption as variable and tracked after the fact. AI Operations Management manages consumption metered by the request and judges it against a value boundary set before spending begins.

Until Chapter 14 defines the full boundary, a provisional rule assigns activities to the two disciplines. An activity belongs to FinOps when it answers a question about the bill, and to AI Operations Management when it answers a Founding Question about the work the consumption served. Consider a constructed case in which a company’s monthly AI invoice is three times the forecast. Reconciling the invoice against the contract and charging it to cost centers answers a question about the bill, so it belongs to FinOps. Tracing the increase to the workflow whose requests grew and deciding whether that workflow’s output justifies its new cost answers the third and fifth Founding Questions, so it belongs to AI Operations Management. Both activities draw on the same record. Evidence that the FinOps team already traces consumption to work would move the second activity across the boundary.

Regulatory governance determines whether an organization may use AI in a particular way. This book takes that determination as given and asks how the permitted use is managed.

3.4Five questions the discipline exists to answer

Each of the five questions corresponds to one of the discipline’s functions and is answered in the chapter that teaches it. Part III covers the functions in a different order, for reasons explained there.

An organization that manages its AI consumption can answer five questions from its own records:

Question 1. “Are you paying for capability you do not need, or starving work that needs more?” This is the sourcing question, answered in Chapter 7.

Question 2. “What do you expect the AI flow to consume next period, and how will you know when it deviates?” This is the planning and budgeting question, answered in Chapter 10.

Question 3. “Who consumed what last month, in service of which work?” This is the metering and attribution question, answered across Chapters 8 and 9.

Question 4. “When capacity is constrained, who decides what runs first, and by what rule?” This is the allocation question, answered in Chapter 11.

Question 5. “Where, exactly, does this AI flow pay for itself, and who is on the hook for knowing?” This is the value boundary question, answered in Chapter 12.

These are the Founding Questions, which an organization must answer “from its own records.” It can always produce an answer by asking the provider, estimating, or repeating the business case. But the answer counts only when the organization retains enough evidence to check it, such as a provider’s figures reconciled against its own or an estimate with its assumptions written down.

At the end of Part I, readers do not yet have a method for answering these questions from records. Parts II through IV provide it: Part II presents the science the functions rest on, Part III builds the five functions, and Part IV turns them into an institution.

Craft section

The function audit

The function audit identifies which of the five functions an organization performs for a deployment and which the available evidence does not show anyone performing. It builds on Part I’s two earlier methods: Chapter 1’s consumption-event inventory lists what a deployment consumes, and Chapter 2’s three-flow mapping shows which flows are managed. The audit asks who performs each job the discipline requires, using the following six steps.

Step 1. List the deployment’s AI activities: buying capacity, choosing models, forecasting spending, recording use, assigning costs, routing work, and judging the return. Start from the consumption-event inventory.

Step 2. For each activity, name the Founding Question it helps answer and assign it to that question’s function.

Step 3. Use Table 3.1 to assign any activity that answers a neighboring discipline’s question to that discipline.

Step 4. Mark each function as performed, partly performed, or not shown. A public record shows only what a company chose to report. If a function is missing from that record, the evidence does not show it; the omission does not prove the function absent. Only an organization’s own records can establish that no one performs a function.

Step 5. For each function performed or partly performed, name who performs it. Write “not named” where the evidence identifies no one.

Step 6. State the first gap to close and the record needed to close it. Begin with the gap where the largest cost goes unmonitored, using the records the organization already holds.

Steps 2 and 4 do most of the work. Step 2 turns a list of activities into a map of the discipline, while Step 4 identifies the gaps: functions in which costs can accrue without anyone monitoring them.

Two rules keep the assignments consistent. Choosing what capacity to buy is sourcing, even when one model serves all the work. The allocation and routing function begins only when a stated rule sends different work to different sources of capacity, decides what runs first, or decides which users receive capacity and which do not.

Applied to Lindy using the public record, the procedure works as follows.

Step 1. The record shows four activities: running the assistants that customers use; choosing a model provider; knowing the total cost of the models well enough to compare it with payroll; and moving most traffic to one model while keeping selected uses on another.

Step 2. Choosing a provider answers the sourcing question. Keeping selected uses on Sonnet while the rest moves to DeepSeek sends different work to different capacity, so allocation and routing is partly performed: the sources describe the split, not the rule behind it. Knowing the total cost answers part of the metering and attribution question, but the sources do not show that cost assigned to customers or products.

Step 3. No activity in the record belongs to a neighboring discipline. Whether a company may use a model from a particular developer or country is a question for regulatory governance, whose determination this book takes as given.

Step 4. Metering and attribution, and allocation and routing, are partly performed. Planning and budgeting and holding value to account are not shown. The cited sources contain no forecast of consumption and no measure of whether each customer’s use pays for itself.

Step 5. Crivello performs sourcing in public. The sources cited here name no one responsible for the other functions.

Step 6. The first gap is attribution. A company whose largest cost is AI consumption needs to record that consumption by customer account so it can compare each customer’s use with what that customer pays. The same record provides the basis for a budget and a value boundary.

Using six steps and a few public facts, the audit examined a company moving most of its AI work to a new model, a move its leader explained by cost. The public record provided no answer to two of the five Founding Questions and only part of an answer to two others. Whether the sourcing decision was sound depends on the new model’s quality and the cost of the move, which the record does not show. The audit also identifies what the switch alone could not establish: which customers account for the company’s new costs.