If You Can Write Acceptance Criteria, You Can Write an AI Routing Policy

TL;DR: The AI Routing Policy

You moved your routine AI work to a cheaper model, so you think the cost question is handled; however, often, that is not the case. The decision lives in one person’s head and produces nothing that the person accountable for the invoices can read. Worse, it is an architectural choice nobody documented. 

The AI Routing Policy is the missing artifact of Stage 2 of the Delegation Lifecycle: it records which execution path, from a cheaper model to a frontier model to plain code, handles each class of work, what counts as good enough output to meet the AI Definition of Done, and who owns the call. The skill it needs to work is one you already have: You write acceptance criteria.

Thesis: An AI routing policy is not about picking a cheaper model at the moment an AI task is executed

The Question Nobody Can Answer

Not every company has a board, but every company has a person in the chief financial officer seat: a controller, a chief accountant, or the owner who signs the invoices. At some point, that person looks at the AI line on the budget and asks a simple question: What does this spend buy, and how would we know it creates a return on investment?

In most teams, the answer is a shrug. Someone switched the weekly status draft to a cheaper model last spring. Someone else left the customer-facing summaries on the frontier model because it “felt safer.” Nobody wrote either decision down. While the AI token expenditure is real, the rationale is folklore.

Why a Cheaper Model Is Not a Policy

The fallacy worth naming first is that switching to the cheaper model solves your cost problem. Most likely, it won’t: a model choice that lives only in habit disappears the day the person who made it changes teams. You may have lowered the bill, but you did not create cost control. You made an undocumented architecture decision with financial consequences, and left no one able to explain it.

What Stage 2 of the AI Delegation Lifecycle Is

In the Delegation Lifecycle, Stage 1 (Decide) uses the A3 Framework to answer whether AI should touch a piece of work at all: Assist, Automate, or Avoid. Stage 2 (Route) answers the next question: which execution path runs the work, and what is good enough for that class of work.

AI routing is not the act of selecting a model while you work. That habit matters, and I covered it for the individual practitioner in an earlier piece on token economics (see Related Articles below). This is the level above the habit: the team standard that survives the individual. A written policy says status drafts run on the mid tier, contract review runs on the frontier tier with human review, and recurring calculations run on plain code, each with a one-line reason.

An AI model tier bundle is more than price. It is a capability, risk, data-handling, and accountability class, and the cheapest option that clears the bar is not always a model. A route is wider than a menu of models: a frontier model, a cheaper model, deterministic code, human-only work, a model plus human review, or no automation at all.

It is the difference between a developer who happens to write good code and a team that has a Definition of Done. One depends on the person. The other depends on the agreement.

The Sufficiency Criterion Is Acceptance Criteria

The load-bearing idea in an AI routing decision is sufficiency: what does good enough mean for this class of work? Paying for a frontier model on a task that only needs a decent first draft is a waste. A cheap model on a task that goes to a regulator is a different kind of waste, the kind that appears in an incident review.

You write this standard the same way you write acceptance criteria for a Product Backlog item. The standard is not “the best the model can do.” It is whether the output meets the stated conditions that a named person can check:

• For a weekly internal update: traceable to the source board, under 300 words, no invented status.
• For an external compliance summary: every claim sourced, reviewed by a human before it leaves, zero tolerance for a feature that does not exist.

It is the same discipline you apply when you refuse a story without testable acceptance criteria.

The friction appears in three predictable places:

1. Teams argue quality in the abstract and never write the criterion, so every task defaults to the most capable model, and the bill climbs.
2. Or they name the route but skip the escalation trigger, so nobody knows when a task is allowed to move up to a more expensive one.
3. Or they write the whole policy and name no owner, so nobody maintains it, the same way nobody maintains an unowned automation.

An AI routing policy without an owner is a suggestion.

The Route Most Teams Forget: No Model at All

Routing to a cheaper model is the first lever everyone reaches for. It is also the smallest one. The smarter move is to ask whether the task needs a model every time, or only once.

Packy McCormick and Markie Wagner make the case in their June 2026 essay: “Thinking is expensive but happens rarely. Doing is cheap and happens forever.” Their punchline is shorter: “Because you know what’s cheaper than Chinese models? Code.” (Not Boring, June 10, 2026.) A recurring calculation, a format conversion, or a status roll-up with fixed rules does not need probabilistic judgment on every run. It needs professional judgment once, to design the deterministic path, and then plain code that produces the same output every time.

For a non-coding practitioner, this is still a routing decision you can make, even if you hand the build to a developer or have a model write the script one time. The leadership question is not “which model is cheapest.” It is: does this task need probabilistic judgment every time, or only once to design the path? An AI routing policy that offers only cheap, mid, and frontier models stays trapped in the model vendors’ cost logic. Add two more routes, deterministic code, and no automation at all, and the policy becomes an operating-model decision.

AI Routing Is Where a Team Makes Its Trade-Offs Explicit

Finance is the pressure that makes routing visible, but cost is not the only variable a route balances. Optimize for one alone, and another gives way:

• Cheapest model everywhere: the bill drops, and quality can collapse on the work that mattered.
• Frontier model everywhere: quality holds, and cost discipline collapses.
• Human review everywhere: risk falls, and throughput collapses.
• Agentic workflow everywhere: autonomy rises, and repeatability collapses.
• Deterministic code everywhere: cost falls, and adaptability collapses the moment the rules change.

A route is where a team makes those trade-offs deliberately rather than by accident. That is the difference between using AI and governing it.

Return on Tokens, and Why Task-Class Attribution Matters

Once the routes exist, you need a way to determine whether each route covers its cost. McCormick and Wagner gave that discipline a name: Return on Tokens (ROT), with a plain formula:

Return on Tokens = (Value of Output − Cost of Tokens) / Cost of Tokens × 100.

The formula is the easy part. The operational implication is the hard part: you cannot improve Return on Tokens if you do not know which task class consumed them. The same essay reports the pattern behind the urgency: Fortune 500 leaders admitting they had committed to enormous token spend with no idea what they were getting back.

That is the issue for most readers. On a Claude Pro or Max subscription, you cannot see per-task token cost; the meter moves, and you cannot trace it to a workflow. The discipline still matters because you build it before the subsidy ends, so you are not the one scrambling when flat-rate access narrows further.

If your work runs through the API, you already pay per token, and Return on Tokens is a number you can compute today for each task class against your AI routing policy. The subscriber is rehearsing for metered reality, while the API user already lives in it.

What the Numbers Make Finance Ask

The Ramp Economics Lab publishes U.S. companies’ AI spending per employee, based on aggregated card and bill-pay data from more than 70,000 businesses. In June 2026, the median firm spent $11.38 per employee per month, about one enterprise subscription seat. The top 10% spent $611. The top 1% spent $7,449. (Ramp Economics Lab, June 10, 2026.) That data is spend-side only: it shows what companies pay, not what the spend returns, which is the gap an AI routing policy and a log are meant to close.

Finance rarely worries about one subscription seat. Finance starts asking harder questions when flat-rate experimentation turns into metered API usage, agentic workflows, departmental duplication, and invoices no team can trace back to work. At that point, CFOs want to learn: what runs on frontier models versus cheaper alternatives, by task class, and why. That demand is the AI routing policy, written from the outside in.

A Routing Policy You Can Copy

Here is what three lines look like. Take one task class per row and fill the five columns.

• Weekly internal status draft
  • Default route: mid-tier model
  • Sufficiency criterion: traceable to the board, under 300 words, no invented status
  • Escalation trigger: missing data, any customer-facing claim, unresolved risk
  • Owner: workflow owner
• Customer-facing roadmap summary
  • Default route: frontier model plus human review
  • Sufficiency criterion: every claim sourced, no uncommitted feature shown as committed
  • Escalation trigger: enterprise customer, legal or security claim
  • Owner: Product Owner
• Recurring metrics calculation
  • Default route: deterministic script, no model
  • Sufficiency criterion: same input produces same output, test cases pass
  • Escalation trigger: metric definition changes
  • Owner: Product Analyst

That is the structure of the record finance wants. It is not the record itself yet.

The Record Finance Can Finally Read

An AI routing policy defines the record’s structure; minimal routing logs turn that structure into evidence:

• Without the log, the policy explains intent.
• With the log, it explains expenditures.

The log adds a few fields to each entry: the actual route used, the escalation reason when a task is moved up, a token or cost estimate, the reviewer, and an outcome signal so the policy optimizes for value, not just the lowest bill.

Skip the log, and the policy is governance theater: well written, and accountable to no invoice. Keep the log, and the same meeting that routes the work leaves the trail that finance and procurement ask for later, with no separate report. That is the real economy of the Delegation Lifecycle: the operational artifacts answer the governance questions, once you spend the small effort to record what they decide.

What to Do Before Your Next Planning Session

Do not write a company-wide AI routing policy this week. Take one recurring AI task, the one whose cost or risk you understand least, and fill one row of the table above: the route it runs now, what good enough means in testable terms, the escalation trigger, and the owner. Add one more column, the actual route used last time, and you have started the log. You will probably find the route was never decided, and the standard was never written. That single gap is the case for the policy.

Conclusion

Acceptance criteria keep a team honest about what “done” means before work starts. An AI Routing Policy extends that habit to how the work gets done: which path, against what standard, with what escalation trigger, and where it is recorded. The skill is not new, only the object is.

When someone in your organization asks what your AI spend buys, will you have a policy and a log to point to, or will you just shrug?

Key Questions This Article Answers

What Is an AI Routing Policy?

A Routing Policy is a written, repeatable team decision that assigns each class of AI-assisted work to the cheapest sufficient execution path, against a stated sufficiency standard, with a named owner. It is the artifact of Stage 2 (Route) of the AI Delegation Lifecycle. The skill it needs is the one you already use to write acceptance criteria.

What Are the Routing Options?

A route is wider than a menu of models. The options are a frontier model, a cheaper model, deterministic code, human-only work, a model plus human review, or no automation at all. A policy that routes only among model tiers stays trapped in the model vendors’ cost logic. The smarter question is whether the task needs probabilistic judgment every time, or only once to design a deterministic path.

Does an AI Routing Policy Give Finance a Spend Record?

Not on its own. A Routing Policy defines the record structure: task class, route, sufficiency reason, escalation trigger, and owner. A minimal routing log turns that structure into evidence by capturing the actual route used, the escalation reason, a cost estimate, the reviewer, and an outcome signal. Without the log, the policy explains intent. With the log, it explains the spend.

What Is Return on Tokens?

Return on Tokens is a measure proposed by Packy McCormick and Markie Wagner in June 2026: (Value of Output − Cost of Tokens) / Cost of Tokens × 100. The formula is the easy part. The operational implication is more difficult: you cannot improve Return on Tokens without knowing which task class consumed them, which is what an AI routing policy and its log make possible.