AI agents may finally solve the part of FinOps nobody wants to do

We have been looking quite closely at FinOps lately, and the more I look at the market, the more I think the main problem is not that companies do not understand where their cloud money goes. Most larger companies already have several tools telling them exactly that.

They know which resources are underutilised. They know where spend increased. They know which teams are responsible for the largest part of the bill. In many cases, they also have a long list of recommendations showing where they could save money.

And then very little happens. Or at least not that often, like maybe once in 6 months.

This is the part of FinOps that I think is broken. The industry has become very good at identifying potential savings, but not particularly good at converting those savings into actual changes in the infrastructure.

A tool finds an oversized instance and creates a recommendation. Someone in FinOps reviews it, tries to understand whether it is real, finds the engineering team responsible and sends them a ticket. The engineers then need to investigate why the resource exists, whether it can safely be changed, whether it is managed through code, what depends on it and whether saving a few hundred dollars per month is worth prioritising over everything else they are already doing.

Quite often, the answer is no.

Not because the recommendation is wrong, but because the cost of investigating and implementing it is too high compared with the saving. Companies can therefore have millions in “identified savings” while continuing to pay almost the same cloud bill. In the end most FinOps tool are a cost item in the balance sheet that rarely pays off.

This is where I think AI agents could make a real difference in FinOps, and it is probably a much bigger opportunity than adding another chat interface on top of cloud billing data.

The value is not in finding one more saving

Cloud providers and FinOps tools are already quite good at detecting obvious waste. They can find unused disks, idle environments, strange cost increases and workloads that appear oversized.

The missing part is everything that has to happen after the recommendation is created.

An agent can investigate the resource across several systems, look at usage over time, check how it was provisioned, find the relevant repository, identify recent changes and work out who most likely owns it. It can then prepare the next step, whether that is a message to the owner, a Jira ticket with proper context or an actual proposed change to the infrastructure code.

That changes the economics of FinOps.

Today, it may not make sense for an engineer to spend one or two hours investigating an opportunity that saves $150 per month. Across a large cloud estate, however, there may be thousands of these opportunities. If an agent can do most of the investigation and preparation work, many savings that were previously too small to prioritise suddenly become worth implementing.

I think this is much more important than making cost recommendations slightly more accurate. The real value will be in making more of them actionable.

FinOps will probably move much closer to engineering

FinOps is still often organised as a separate layer between finance and engineering. It produces reports, identifies opportunities and then tries to influence engineering teams to act.

That model makes sense when every opportunity requires manual analysis and coordination. It makes less sense when agents can turn a cost signal directly into a technical workflow.

For example, an agent could identify that a resource appears oversized, inspect the historical utilisation, understand how it is configured in Terraform, estimate the impact of changing it and prepare a pull request. The engineer would still review and approve the change, but most of the repetitive work would already be done.

At that point, FinOps is no longer mainly a reporting activity. It becomes part of the infrastructure delivery process.

I do not think the FinOps function disappears, but its role probably changes. Instead of manually chasing individual recommendations, FinOps teams will define the policies and boundaries under which agents can operate: which environments can be optimised aggressively, which changes always require approval, what evidence is needed before a resource is removed and how much risk the company is willing to accept for a particular saving.

That is a much more scalable model than sending more spreadsheets and tickets to engineering.

Fully autonomous FinOps is probably a bad idea

There is, of course, an obvious way to get this wrong.

An agent should not be given broad access to production and a simple instruction to reduce cloud costs. Cloud infrastructure contains too much context that is not visible in the billing data, and a resource that looks unnecessary may exist for a perfectly valid reason.

So I do not believe the future is an agent randomly shutting things down in production.

The more realistic model is that the agent investigates, prepares the change and sends it through the engineering controls that already exist. For companies managing infrastructure through code, that normally means a pull request with the expected impact, validation results and a clear explanation of why the change is being proposed.

The agent removes the manual work, but the company keeps control.

The metric that matters is realised savings

FinOps vendors often talk about identified savings because it is an impressive number and relatively easy to produce.

But identified savings are not the same as value delivered.

If a platform finds $2 million in potential savings and the company implements $100,000, then the relevant number is much closer to $100,000 than $2 million.

As agents become part of FinOps workflows, I think customers will start paying much more attention to what actually happened after the recommendation was generated. How many opportunities were investigated? How many became approved changes? How long did it take? How much engineering time was required? Did the saving reach the bill, and did any of the changes create operational problems?

This will be uncomfortable for parts of the market, because it is much easier to sell visibility than execution.

At Cloudgeni, this is the direction we are exploring: agents that connect cost data with the actual infrastructure and engineering context, and then prepare safe, reviewable changes rather than producing another list of recommendations.

I do not think FinOps needs many more dashboards. It needs a better way to get the work done.