Part two of three. Buying AI gives an organization a component. Getting value from it requires a system designed around that component.
The argument in brief
Buying AI is the easy part. The hard part is designing the work around it. Suppliers have their own physical constraints and commercial incentives, and the price on the contract is not always the exposure you end up carrying. No model, platform, policy, or training program arrives with an operating model in the box.
Part one defined the buyer’s half of the exchange and showed where the return goes missing. Four of those ways are delivery shortfalls: the gain is never produced because nothing was redesigned to carry it to the enterprise. Buying better doesn’t fix them. They are fixed, if at all, by designing the system the purchase sits inside.
This part makes two connected points. First, a buyer needs a realistic picture of the supply side it is trading with. Second, the buyer, not the supplier, must design the system around the tool.
The other half of the exchange
When an organization signs with an AI vendor, it is not dealing only with the company named on the contract. Under that logo sit model providers, chip makers, cloud infrastructure, data centers, power, permits, and the financing that makes the whole stack possible.
That matters because the familiar story is incomplete: AI is getting cheaper, and switching suppliers will be easy.
An example
Imagine a retailer choosing one of three chatbot providers for customer support. Prices are falling and switching looks easy, so it builds its support workflows on the platform, trains its staff around it, and puts approval rules inside it.
A year later, demand for the compute behind the chatbots spikes. The provider replaces a flat monthly fee with a per-conversation charge. Switching now means retraining staff and rebuilding the workflows and rules embedded in the platform.
The retailer bought into a market that looked cheap and easy to leave. It was neither.
This does not require bad intent. Suppliers are responding to their own constraints. But a buyer that understands only its own half of the exchange is negotiating with a picture it drew itself.
1. Better software does not remove physical limits
Frontier AI is constrained not only by what can be designed, but also by what can be manufactured, powered, sited, cooled, and permitted. Better software cannot create more chips, data center capacity, electricity, or land.
Think of a restaurant. A better reservation app can fill tables more efficiently, but it cannot create more ovens, kitchen space, or chefs.
This is both a floor and a moat. It constrains every supplier when demand rises. It also excludes most would-be competitors, because operating at the frontier is increasingly heavy industry rather than software.
2. Supply is moving in two directions at once
The capability layer, which includes models and tools, is commoditizing downward. The physical layer underneath it, including compute, power, and data center capacity, is repricing upward.
Both can be true at once. “AI is getting cheaper” is not a useful summary unless it says which layer, and which commercial exposure, it means.
3. More sellers do not necessarily mean more independent choice
The number of genuinely independent suppliers can fall without the number of supplier logos falling. Financing, cloud capacity, and upstream model relationships can bind apparent competitors together without an acquisition ever taking place.
One provider may finance a rival’s facilities and rent the capacity back. Another may resell surplus capacity it can reclaim when its own demand rises. Several nominal competitors may depend on the same upstream party.
The buyer sees alternatives. The alternatives may never have been independent. This is one of the supplier-side facts a buyer is least equipped to see.
4. The exposure is to the commercial form, not just the price
A supplier chooses not only how much to charge, but how to charge: flat fee, per seat, per query, per conversation, or per token. It can also seek to change that form after the buyer has built on the product.
Flat-fee procurement makes consumption easy to ignore. Metering makes it visible and billable. But the meter normally runs on attempts, not outcomes. A workflow that takes three attempts and a human repair costs more than one that gets the work right first time, even if its unit price is lower.
The practical question is not “What does an AI call cost?” It is “What does it cost to produce a completed, acceptable outcome?”
5. Do not outsource authorship of how work gets done
Suppliers increasingly sell more than capability. They sell the management layer around it: orchestration, credentials, approvals, evaluations, and monitoring. Suppliers now use the word harness for that layer, the same word part one used. The overlap is real, and the difference is whose rules the layer carries.
Buying it is often sensible in the moment. Why build what the supplier can hand over already working?
But each reasonable adoption can move another business rule into a product the buyer does not control. What accumulates is not merely technical dependency. It is dependency on someone else’s authorship of how the business operates. The loss of leverage becomes visible precisely when the commercial terms change.
Sangeet Paul Choudary, in Reshuffle, describes a supplier-side winning move: reengineer the whole system around a component rather than merely build the best component. The mirror image matters for the buyer. The same discipline has to exist inside the buying organization, or it does not exist at all.
Components are not systems
This is where many enterprise AI programs quietly go wrong. They evaluate models or platforms, run a bake-off, negotiate, and sign. Then they wait for the operating model to assemble itself around the purchase.
It will not.
A model is a component. A workflow tool is a component. A governance policy is a component. A training program is a component. Useful components do not, separately or in a procurement folder, make a system.
The kitchen test
Imagine renovating a kitchen. You do not buy the best refrigerator, stove, and faucet, put them on the floor, and call it a kitchen. Someone still has to decide the layout, run the plumbing and wiring, resolve the conflict between the pipes and the island, and take responsibility for whether the whole room works.
The appliance manufacturers are responsible for appliances. They have no view of your kitchen.
The appliances are supply side. The kitchen is demand side.
No supplier can fully decide how work should flow in a particular organization, where people should make decisions, what good looks like, what must be checked, or what the business should measure. Those are the buyer’s design decisions.
What the design looks like
What follows is one answer rather than the answer. You can accept every word above and arrive at a different solution. I call it a work operating model, and it covers one region of the territory: how work is designed, run, measured, and improved. It does not cover what you keep or where that leaves you. Those stay on part one’s list and sit outside any operating model.
Its first move is to separate two questions that are often collapsed into one:
- What does the organization deliver, to whom, and what must be true at each step?
- How is that work actually done: by whom, in what order, and on what instructions?
The first is about the outcome. The second is about the method. A model that answers only the first is a diagram nobody operates against; one that answers only the second is a pile of procedures with no account of why they exist. The two meet at the phase.
The upper altitude: what gets delivered
The organizing unit is the value stream: the end-to-end work that delivers something valuable to a customer. It should be named from the customer’s point of view, not from the department’s. “Claim reported to claim settled” is a value stream. “Claims operations” is a function.
If you cannot name the customer and the value they receive, you do not have a value stream. You have a function with a new label.
One owner is accountable for the stream end to end. Their first task is to divide it into phases.
A phase is a contract, not a label
Each phase has three parts:
- Entrance criteria: the state that must hold before the phase can begin.
- Exit criteria: the state that marks it complete.
- Value item: the increment of value it owes, and to whom.
The third part is the test that matters most for AI investment. The increment must be something a named recipient outside the phase would recognize as worth having. If a phase merely passes work on unchanged, it is a candidate for removal, not a fixture to accelerate.
Take the claims firm from part one. AI makes drafting faster, but claim settlement time does not move. The question is not whether the draft is faster. It is what each stage after drafting hands on, and whether anyone recognizes that hand-off as more valuable. Faster drafting may simply feed the next queue sooner, giving the policyholder nothing more.
Phases do not have to run in a straight line
A phase begins when its entrance state holds, not merely because a previous box has finished. Phases can therefore overlap, run in parallel, or loop back. Sequence still exists, but it emerges from the dependencies each phase genuinely has.
That is more useful than a neat flowchart because it forces someone to name what the work is actually waiting for.
The lower altitude: how work gets done
Below each phase sit the workflows, instructions, and roles that produce the promised result.
Some work is a fixed recipe: the same steps in the same order. Some is judgment-based: the outcome is clear, but the path is worked out as the case unfolds. Both belong in the same model because the phase contract fixes the outcome, not every possible method.
A workflow should name the work and the role that performs it, not the particular person, team, or technology that fills it. The work can stay constant when the actor changes.
Changing the actor is a specification event
That is the claim most often quoted back at me, and it holds only if the new actor takes its objective from the phase contract. Where the new actor brings its own objective, the inputs and outputs can look identical at the boundary while the output is produced against a different standard. An AI product may be optimized for fast responses, low cost per call, or high user satisfaction. Your phase may require a fair, compliant, complete customer outcome.
The test is one sentence: Can we state what this work is optimizing for in the language of its phase contract, without referring to what the supplier says the product does?
If not, the objective is inherited. The workflow needs re-specifying, not simply re-staffing.
The instructions were never the whole instructions
This is the sharpest thing I have learned at this altitude, and it explains the review and rework tax better than anything else I have found.
Instructions written for people lean on things people supplied silently, and because nobody asked for them, nobody wrote them down. Nobody had to state when to stop: budget pressure, fatigue, professional norms, and plain confusion at something odd all halted the work without anyone designing a stopping condition. Nobody had to insist on testing, documentation, peer review, or staying in scope either. None of these register in the output by which performance is judged, so anything optimizing for that output will route around them.
A fast executor does not automatically supply those obligations. Where testing, documentation, peer review, staying in scope, or a stopping rule matters, the workflow must design it as a requirement or a check that blocks the work. It cannot remain an expectation. The instructions inherit every obligation the executor used to absorb silently, so changing who does the work is a specification event, not only a staffing one.
This produces a counterintuitive inversion. Human execution exposes bad specifications through friction: someone pauses, queries an ambiguity, or makes a visible error at small scale. Fast, faithful execution can realize the same vague instruction completely and at volume before anyone notices.
A specification defect costs more under fast, faithful execution than under slow, fallible execution.
Four questions across the whole stream
Four layers span every phase. None contains the work itself; each asks a different question of the stream.
| Layer | Question | Failure it reveals |
|---|---|---|
| Decision rights | Where does authority actually bite? | Approvals that approve everything |
| Governance | What are we running on that we did not write? | Business rules living in a supplier’s product |
| Measurement | Did the work deliver what it owed? | Savings per input, losses per outcome |
| Reporting | What account of the work reaches leadership? | Reports that describe the tool, not the work |
Decision rights: gates versus checkpoints
A real gate blocks, releases, or redirects what happens next. A point that does none of those things is a checkpoint, whatever the process map calls it.
A sign-off meeting that approves every draft is a gate that decides nothing. It can decline and never does. It still adds wait time, records that a control occurred, and may deliver none of the protection the control was meant to provide. In the claims firm, that is the sign-off stage after drafting, however senior the signature.
Governance: the rules somebody else wrote
Governance here does not mean board oversight. It means the rules your operation runs under that it didn’t write and cannot change on its own: a supplier’s product logic, its commercial terms, and the approval patterns and evaluation rules built into what you bought. Those rules still govern. They also set the boundary within which you can distribute decision rights at all.
The retailer from earlier shows it. Its approval rules lived inside the chatbot platform, and the supplier could change the form of the price. Neither was a decision the retailer took, and both governed how its support operation ran.
The question for this layer is not whether suppliers are good or bad. It is whether the organization knows which rules it authors and which it accepted by adopting the product, and whether it decided or drifted into each.
Measurement: measure delivered outcomes
Most useful measures come from the phase contracts: how long work spends in a phase, where it waits between phases, whether it is right the first time, and what it costs per completed outcome.
The unit is not cost per prompt, draft, call, or token. It is cost per delivered outcome. Where a supplier’s meter tracks its own costs rather than the value received, optimizing that unit optimizes the supplier’s variable.
Choosing the input and designing the workflow are therefore one decision, not two. A more expensive tool that resolves work first time can be cheaper per settled claim than a cheaper one that creates review, rework, or customer follow-up.
Reporting: report on the work, not the tool
Leadership needs to know whether the value stream delivered what it promised. Vendor dashboards can accurately report activity: usage, active users, satisfaction, and spend. Those are useful facts about a product.
They are not necessarily facts about the business outcome. In the claims example, high usage and good user satisfaction can coexist with flat claim settlement time. A report built from phase contracts shows whether the work delivered; a report assembled from supplier dashboards describes the products in use.
Of the four, governance does the most work for a board. Part three takes it up in full, including what leadership should require instead of what suppliers report, and who has to answer for it all.