Control that makes AI adoption faster

Picture a company where AI spend doubles in one quarter. Finance sets a monthly cap for the whole company, and on the 20th of the next month the support team's agent stops working at noon. That agent was resolving more tickets each week, for less per ticket than anyone expected. Nobody wanted that result, but a single cap had no way to tell the agent that was paying for itself from the experiment that was not.

A blanket cap is a sudden cut in another form. The cut is decided before the bill arrives instead of after it, but it falls in the same place: on the AI that works along with the AI that does not. And because the teams that use AI most reach a cap first, it often slows the teams that use AI best.

Limits are useful, so we suggest keeping them and changing how they are earned: one step at a time, and known to each team before it reaches them.

Teams move faster when they know the limit before they reach it.

Why a blanket cap slows the best teams

A cap on the whole company, or on one vendor, sees one number. It cannot see who spent the money, what the spend produced, or whether one resolved ticket cost more or less than expected, so when the number is reached, every team stops together.

The teams that feel it first are the ones that adopted AI early and use it every day. Once they learn that a good month can end on any afternoon, they plan around the cap, ask for exceptions, or wait before they start the next workload. Each of those choices is reasonable, and each one slows adoption down.

The tension is common. In the State of FinOps 2026 report (FinOps Foundation, February 2026, 1,192 respondents), 98% of respondents said they now manage AI spend. In the same report, one technology company explained that it keeps its limits few for now, because time to market comes first and it does not want to slow innovation. Leaders in that position seem to feel they must choose between control and speed.

What vendor and gateway limits do well

The limits you already have are worth keeping. Many model providers let an admin set a spend limit on an organization or a project, and an AI gateway can cap each key or team. A gateway's cap rejects the next call the moment the limit is reached, which no report that arrives the next day can match.

The FinOps Foundation's paper on managing AI value (February 23, 2026) suggests hard spend caps for fast, experimental workloads, and adds that the people who use them should be able to see the caps clearly. We agree with both points.

The harder questions are who decides where a limit sits, what it applies to, and when it starts to stop work.

Enforcement is earned

Control can climb four steps, and a limit moves up one step only after the step below has worked as expected on your own spending.

Observe. A new limit records what it would have done, and nobody is told. This is how you learn whether the number is right, before it touches anyone's work.

Warn. When spend comes near the limit, the person who owns the workload hears it first, before finance does. The owner knows why the spend grew and can explain it, fix it, or ask for more.

Require approval. Past the limit, new spend waits for a yes from a named person, who decides on evidence: what the workload costs per successful outcome, against what was expected.

Enforce. A limit reaches the top only after it has worked on every step below. The system that sees each call does the stopping, usually the gateway or the vendor's own limit, and by then the owner already knows the limit and has agreed to it.

Most limits never need the top step. Warning the owner and asking before spend grows are often enough, because they put the decision with the person who can judge it.

Set limits on the work

A limit on a vendor mixes everything that vendor serves. The support agent, a coding tool and three experiments can share one model provider, so one team's growth uses up another team's room, and nobody knows whose limit it was.

A limit on a team, a workflow or an agent has an owner from the first day. You can set it from the workload's own history instead of from a guess, so a support agent that spent between $2,000 and $2,600 a month gets a limit near that range, rather than a share of a company total. (That is an example, not a customer.)

Often the most useful limit is on the cost of one outcome rather than on total spend. If one resolved ticket should cost $1.50, a limit on that figure lets the agent resolve twice as many tickets next month, as long as each one still costs what you expected. An agent that keeps paying for itself can keep growing, and one that stops doing so waits for a yes.

Try every limit on past spending first

Before a limit switches on, run it on the last month of spending to see how many days it would have fired, which runs would have waited, and how much spend that was. A limit that would have stopped your best workload on its best day is wrong, and it is better to learn that from last month than from next month.

In Valistry, every new rule starts at the first step, watching, and before you switch it on, it shows what it would have done on your past spending.

Approvals that are written down

An approval is only useful later if someone can read it. Each one should record who said yes, on what evidence, and what value the team expected from the extra spend, so that next month's review can check whether that value arrived.

It should also be possible to take an approval back. When the expected value does not arrive, the person who approved it withdraws the yes, and the record keeps both decisions. Because nothing is lost, people approve with more confidence, and finance gets a predictable month without having to approve every request itself.

Four questions before you set a limit

1. 1Who owns the spend this limit covers?
2. 2Is the limit on a team, a workflow or an agent, or only on a vendor?
3. 3What would it have done to last month's spending?
4. 4When it is reached, who says yes, and how quickly?

If you can answer all four, the limit is ready to start at the first step. If the first question has no answer yet, give the spend an owner first, because a limit nobody owns turns back into a blanket cap.

How a limit keeps a saving

A review can find a saving once, but without a limit, usage tends to grow back into it, and the next large bill brings the same pressure to cut.

Limits that earn their way up work the other way. Teams know the limit, and who decides, before they reach it, so they can start the next workload without waiting. Every limit, approval and exception is kept on the same record as the spend and the outcome, so next month's review can see what was approved, what it delivered and where to set each limit next. Used this way, control can help a company adopt AI faster, while finance stays confident about where the spend is going.