Who in the Room Is Paid to Tell You to Stop Cutting?

Your cost tools, and some of your advisers, are paid to push the bill down. The call to stop, or to spend more, belongs to the executive who carries the outcome. Before you let an agent act, get three answers in writing: what it is optimising for, what must not get worse, and who owns the setting.

In June, AWS put its FinOps Agent into preview. It answers questions about your AWS bill, investigates odd spikes, and pulls savings recommendations from AWS Cost Optimization Hub and Compute Optimizer. It can open a Jira ticket or drop a note in Slack. For now it is free, within a monthly limit, though the other AWS services you point it at still cost what they cost.

It is not alone: a third-party agent will propose each AWS commitment, wait for your approval, buy it, and take 5 per cent of the saving. A commitment manager skips the approval: it buys on its own inside limits you set, for a share of what it saves. Both, like the AWS agent, have moved from telling you what they found to acting on it.

Automation that acts on the bill, rather than reporting on it, is worth having for the dull, repetitive work. It also raises a question the launch posts leave out: who decided what the agent is allowed to do? Before you let one act on your bill, three answers belong in writing. What outcome is it optimising for? What must not be allowed to get worse while it does? And who owns the setting that turns those two answers into a rule? The first two, the outcome and what must not get worse, come easily. In my experience the third, who owns the setting, is the one that is not written down anywhere.

The right bill is not the lowest one

The uncontroversial part first: the lowest bill you can reach and the right bill for your business are not the same number. The FinOps Foundation’s own principles say as much: make conscious trade-offs among cost, quality and speed. Sometimes the trade-off is to spend more. The interesting question sits above the number: in a room where the tools and some of the advisers are paid to keep cutting, who is placed to say stop? What shapes the advice they hear when they have to make that call?

Two forces bend the advice

Whoever holds that call decides on what the tools and the advisers tell them, so the fee model and the data behind that advice matter as much as the advice itself. The first is how a product earns: the third-party agent and the commitment manager both take a share of the savings they generate on the commitments they run. That suits them well when the aim is getting your rate down, which is real value when your usage is steady. It also means neither product earns anything by telling you to hold a commitment or spend more. A tool paid on savings has no reason to recommend the decision that raises your bill, even when that is the right one. AWS does not sit here, because it takes no cut of your savings.

AWS has a different limit, one of information rather than incentive. The AWS agent reads AWS data and offers AWS recommendations, and the documented boundary is enough on its own: it is not built to weigh whether a workload should be on AWS at all, or whether someone else would run it cheaper. Ask it to optimise your AWS bill and it will. Ask it whether you should be on AWS, and you have asked the wrong adviser. Three products, two kinds of limit, and none of them is acting in bad faith.

The rule sits above the tool, and a person above the rule

Both limits live at the bottom of a short hierarchy: the tool acts, but only inside the rule you give it. AWS lets you set how much performance headroom to keep, the commitment manager works inside the risk and budget limits you set, and the third-party agent proposes a purchase, then waits for you to approve or adjust it. Above the rule sits whoever wrote it, and above them the executive who carries the outcome if the rule is wrong. Nothing a vendor ships changes that order, and the order is the point: you cannot hold a tool to account for a bad rule, only the people above it.

That is the third answer in full: who sets those rules, who signs off the trade-off each rule encodes, between cost and performance or cost and the risk of being wrong, and who can stop the agent or overrule it when the situation changes. You cannot hand that authority to the thing you are authorising, so someone accountable has to hold it.

Open whatever automation you already run and find the setting that encodes the trade-off: the utilisation headroom in Compute Optimizer, the coverage target on your commitment tool, the approval step on a purchase. Then ask who last changed it, and whether the executive accountable for that workload’s outcome would recognise the name. If nobody can answer both inside a day, you have rules without an owner.

The decisions a savings engine is worst at

Some of the decisions that matter most are the ones a savings engine is least equipped to make. Take capacity before a launch. If you expect a surge and the cost of failing to serve it is higher than the cost of the spare capacity, you buy the capacity, and you buy it with the right instrument. Savings Plans and regional Reserved Instances lower your rate but do not hold capacity for you, and a capacity reservation is the instrument that does. Whoever makes this call has to know the difference, and a bill-reduction tool will not draw it for them.

Resilience has the same shape: you keep a workload in two regions because your tested recovery target cannot be met by a cheaper single-region design. The obligation is the recovery outcome, not the architecture. The call is a judgement about what a failure would cost you, weighed against the second region’s monthly bill, and it is yours to make.

A more expensive managed service is the cleanest case: incidents and release time both drop, and that is worth more than the higher infrastructure line, so you move off the self-managed setup. The bill goes up. The right decision still took it up.

AI brings this into daily view through model routing. You send routine requests to a cheaper model and reserve a stronger, dearer one for the requests that carry real risk. The complication for my own argument: a routing tool can pick the more expensive model, and that is what it is for. It does not decide which requests are too costly to get wrong, or what error rate is acceptable on them. Someone has to set that line for the tool to hold.

Who holds the decision

Who holds it, then? Someone inside the business. The FinOps Foundation’s framework spreads these calls across executives, product, finance, engineering and the practitioners, which is right, because the person accountable for the outcome usually sits there. A tool cannot hold it, and an outside adviser feeds analysis into the decision without taking it over.

Each fee model pulls somewhere. A share of the savings pulls toward the cut, because the adviser earns nothing on the decision that raises your bill. A fixed project fee pulls toward the next engagement and the method the adviser already knows. Time and materials pulls toward more hours. None of them makes an adviser a saint, and none removes the need for someone inside the business to hold the decision. Know which way your adviser is being pulled before you weigh what they tell you, and discount accordingly.

A mid-market financial services firm in NSW was about to route all of its AI traffic to a cheaper model to cut the bill. We advised keeping the stronger, dearer model on a defined slice of high-stakes requests, the customer-facing financial decisions. Holding it there cost $5,000 to $10,000 a month more than routing everything to the cheap model. The reason was the cost of being wrong, which here meant a wrong financial decision delivered to a customer in the firm’s name. An evaluation, an expert sample review and a red-team all put the cheaper model’s error rate on those requests at about one in twelve. A single wrong customer-facing decision carried reputational damage and regulatory penalties that would have dwarfed the saving. That is the Token Price Trap in practice: the model that was cheapest per token was the dearest per outcome once the cost of a wrong answer was counted. The call sat with the Chief Risk Officer, and the CFO signed off on the extra spend once we had walked him through the rationale and the risk. It is early: the stronger model is in place there and being watched, with no incident so far.

The routing could have run on autopilot. A person set the rule for which requests were too costly to get wrong, and because the advice earned nothing from the cut, the CFO raised the bill on purpose rather than by accident.

When you do not need anyone outside

Most of this does not need outside advice. Your own people know your product and your customers better than anyone you can hire, and no adviser can stand in for engineering validation or for the executive who has to own the risk. Any adviser, me included, can get a call wrong if the outcome is never measured. When the problem is small and mechanical, advice costs more than the decision is worth. For narrow commitment management a savings-share tool can be the sensible choice, simpler to approve and reasonable on the economics. That holds provided your product margins are strong, your FinOps function works and the limits on your automation are already set.

Before you turn it loose

If the three answers do not exist in writing yet, that is the work to do first, and the third is the one to start with. Let the agents have the dull, repetitive work, and keep the accountability for what they produce. The tools and the savings-share advisers in most rooms are paid to keep cutting, so make sure one person in yours is placed to say stop. Start this week with the one automation you already run: find the setting that encodes its trade-off, write the owner’s name beside it, and get the executive who carries the outcome to sign the page.

A focused FinOps maturity review shows where those decision rights sit in your own setup. I run one on the Optimize Usage & Cost domain of the FinOps Framework, with the accountability side pulled in from Manage the FinOps Practice. It covers how your rate and commitment decisions get made, what your automation is allowed to do on its own, and who signs off the trade-offs and owns the call when cutting the bill is the wrong move. It answers two things: whether anyone in your setup has the standing to say stop, and whether they have what they need to say it. If you cannot answer that today, it is work I would be glad to do with you.