Rank candidate AI workflows on two axes, value returned per dollar of run cost and governance friction, and start in the corner that is labor-heavy and low-friction. The showcase candidates are usually in the wrong corner.
The first workflows an organization automates are rarely chosen. They are inherited from whoever had the most compelling demo or the most senior sponsor, and the selection gets rationalized afterward with a value number. I have come to prefer a duller method. Put every candidate on two axes: value returned per dollar of run cost, which is knowable before anything is built, and the governance friction standing between a prototype and production. In my experience the showcase candidates usually land in the wrong corner: high friction, modest ratio, and a sponsor who will not want to hear it.
The cloud migrations I watched sent the first workloads to whichever team was loudest about data center pain, not to the systems cheapest to move. The first seat licenses went to the department that asked and became shelfware there. Each time the portfolio was sorted by enthusiasm and re-sorted by invoice.
The first axis comes straight from the regime map in the working paper. Two quantities decide it: how many human hours a unit of work takes today, and how many units of consumption the model needs per run. A step where a person spent roughly forty minutes and the model now consumes about eight thousand tokens returns more than a hundred dollars for every dollar of run cost at frontier list prices. A one-minute classification step run half a million times a month on a big-context frontier model returns roughly 1.5 dollars per dollar, and the high end of a 0.75x to 1.6x consumption band takes the case negative.
I use 3x as the working threshold, a threshold and not a law. Below it, the costs the model does not capture, review burden, error handling, platform fees, reliably eat what is left. Above it, run cost is a budgeting question and the decision turns on adoption.
This axis needs no prototype. Hours per unit come from a time study or the ticketing system. Consumption per run comes from a rough count of what the step has to read and write. The ratio is knowable on paper. Most teams I have worked with never compute it.
The second axis is harder to quantify and easier to observe: the distance between a working prototype and a system someone will put their name on. Four things set it.
Data class. Which data the step touches, and whether an approved path already exists for that class to reach a model. Public product documentation sits low. Customer financial records sit high until the data boundary is settled once.
Regulator sign-off. Whether a supervisor, auditor, or external body has to approve the change, and on what cycle. A step inside an audited control is not slow because of engineering. It is slow because the sign-off calendar is not yours.
Reversibility of the action. Whether the step produces a draft a person reviews or an action that lands in the world. Drafting a response is reversible. Sending a payment is not. Irreversible steps carry the full weight of the accountability architecture.
The name on it. Whether a named owner exists with the authority to change or stop the system in production. Where that role is unfilled, friction is effectively infinite. The system should not ship no matter how good the ratio looks, and when one ships anyway, the incident finds the owner the plan did not.
None of this is a reason to avoid high-friction work. It is a reason to know, before the demo, how long the road to production is.
High ratio, low friction: start here. Labor-heavy steps on data that already has a paved road, with a reversible output and a willing owner. They are rarely exciting. They are the ones that reach production and generate the telemetry everything else depends on.
High ratio, high friction: instrument first. The value is real, but the road to production runs through a regulator or a data class with no approved path. Do not build the agent. Build the measurement. Tag the human work and capture the hours per unit, so that when the governance work lands the business case is empirical rather than asserted.
Low ratio, low friction: redesign the step before building. Easy to ship, hard to justify. The levers are model tier, context length, and runs per unit. If a smaller model or a shorter context pushes the step over 3x, it moves to the first corner. If nothing does, it waits until prices move.
Low ratio, high friction: do not build. This is where the showcase candidates most often sit, and nobody says so, because the sponsor is senior and the demo was good. The result is a project that consumes a year and ships a slide.
The paper’s worked example is a help desk handling 4,000 requests a month, broken into six steps. Intake, triage, and closure notes are automated. First-line resolution and specialist investigation are assisted. Approval stays human. At full maturity the value returned ramps to about 400 thousand dollars a month and the run cost settles near 850 dollars a month inside its band. That is deep in the first corner: the assisted steps are labor-heavy, the output is a draft a person sees, and the data is the organization’s own tickets.
Place the classification step from the regime map beside it. Half a million items, a minute each, a frontier model with a large context, roughly 1.5 dollars back per dollar. It is the weaker candidate, and the one a vendor demo tends to lead with, because volume looks like scale. The honest move is the third corner: shrink the model and the context until the ratio clears the threshold, or wait.
These are two public examples at list prices with placeholder bands, and I will not claim more precision than the paper does. Your steps will land elsewhere. The point is that they land somewhere before a line of code is written.
For each step the model asks for a disposition: an agent runs it, a copilot assists, a human keeps it with a brief, or the step is eliminated. The removal fractions, roughly 0.85, 0.45, and 0.15, are priors and will be calibrated by data. The choice of disposition will not. It comes from knowing which steps the regulator will let you automate, which actions the business can afford to have wrong, and whose signature the output needs.
That knowledge is not modeling. It is the memory of what a supervisor said in the last exam, what legal already approved for a neighboring team, which approval step exists for a reason and which from habit. In engagements I have led, the friction axis was almost always known inside the organization before anyone drew it, and almost never written down. Writing it down once stops every new candidate from relitigating the same questions.
A ranking is a forecast, and a forecast ages. Re-rank quarterly as telemetry replaces assumptions. The first corner’s workflows produce measured hours and measured consumption within a month of shipping, provided every model call is tagged with its step and unit, and those measurements sharpen every other candidate’s position. The band narrows. Candidates move.
Some move the wrong way, and the hygiene is to retire them. A candidate whose ratio did not survive measurement is not a failure of the method. It is the method working. Keeping it on the list because a sponsor remembers the demo is how portfolios fill with projects that are neither built nor killed.
What I am still learning is how far the friction axis transfers. The ratio axis is arithmetic and moves cleanly between organizations. The friction axis is local: the same step on the same data class sits low in one firm and high in the next, depending on what has already been approved and who will own it. I do not yet have a way to score it that does not reduce to asking the people who know. That may be the honest answer rather than a gap.
The method is dull on purpose. It gives the sponsor a corner instead of a verdict, and finance two numbers instead of one. The exciting method demos. The dull method ships.
Related: The business case for AI has two numbers and Scope before you build.
