A Software Factory for FinOps: How AI Agents Find Cloud Waste, Ship the Fix as Code, and Prove the Savings on AWS

Cloud costs grow around the clock. The people responsible for them work nine to five.

That sentence is the whole problem, and no dashboard has ever solved it. Your environment changes at 2am on a Sunday. Someone's autoscaling group does something expensive during a traffic spike. A test cluster outlives the test. By Monday it is background noise, and by the time it surfaces in a report it has been quietly billing you for three weeks.

The industry response has been to get very good at finding this. We now have excellent detection. What we do not have is completion.

A software factory for FinOps is a repeatable production line for cloud cost work. Savings opportunities are detected in your AWS environment, enriched with the context an engineer needs, routed to the person who owns that service, fixed as code by AI agents, and verified against actual billing data. Automated checkpoints sit between every stage, and a human approves every change that reaches production. That is the whole idea, and the rest of this piece is how we built one and where it broke.

Why most cloud cost recommendations never get implemented

Our industry measures detection obsessively and completion almost not at all. No one publishes a straight answer to the only question that matters: of the savings you find, how many actually ship? The closest thing to a benchmark is Google Cloud's own FinOps guidance, which sets a target of just over fifty percent of automated recommendations implemented, and frames that as what good looks like once your tooling matures. That guidance is from 2021. Five years later nobody has published a better one, which tells you how seriously our industry takes completion as something to actually measure. McKinsey, reviewing more than three billion dollars in cloud spend, found ten to twenty percent untapped savings sitting in plain sight, stalled because engineers have neither the incentive nor the access to act. And the FinOps Foundation's own survey has kept workload optimization as the top unsolved priority for five years running. If detection were the problem, it would have moved off that list by now.

Glassity ships eighty percent of discoveries as merged pull requests. The other twenty percent we decline on purpose, because they are not technically feasible or the tradeoff is not worth it. We count a finding as done when the PR merges, not when a dashboard lights up.

I want to describe how we closed that gap. But first I have to take a phrase back from two other industries.

What I mean by "software factory", and what I don't

If you have worked in defence or large enterprise, "software factory" probably means a paved road: a repeatable, governed path that lets development teams build and ship software without reinventing the pipeline every time.

If you have spent 2026 watching your feeds, it probably means something newer: an agentic pipeline where AI agents take a specification, break it down, write the code, review it, test it and open the pull request. Factory.ai, Spotify's fifteen hundred agent-generated PRs, the BCG write-ups.

And if you are in certain markets, it just means an outsourced development shop.

All of those produce software. Ours does not. Our factory produces fixes to infrastructure that already exists, and its output is measured in money rather than features. Call it agentic FinOps if you want a label: agents that do the cost work rather than agents that write your features.

That distinction sounds pedantic until you think about failure. The worst case for a feature factory is a bad feature. The worst case for a cost factory is an outage in production. Same architecture, completely different blast radius, and therefore completely different rules about what a machine is allowed to do unsupervised.

Which brings me to the part of the manufacturing analogy people usually get wrong. The assembly line's real invention was never speed. It was interchangeable parts and inspection at every station. Ford's line is famous for output, but the thing that made the output usable was that a part which failed inspection did not move forward. Speed was a consequence. Quality control was the mechanism.

Cost optimization needs that mechanism far more than software delivery does.

So here is the line, end to end. Station one, intake: the factory reads your AWS environment and turns raw signal into a work order carrying enough context that an engineer can act on it without an hour of archaeology first. Station two, routing: every work order gets a named owner, because a finding addressed to nobody is a finding that never ships. Station three, the fix: an agent writes the change as code and opens a pull request against the repository that defines your infrastructure. Station four, proof: the saving counts only once it appears in the invoice. Between every station sits a checkpoint, and at the end of the line sits a human who approves or rejects. What follows walks each station in order, including the places where ours broke.

Why cost optimization is a factory problem in the first place

Look at the shape of the work. It is high volume. Each individual item is worth relatively little. It is repetitive, but not identical, so it resists naive scripting. It requires context that lives in three different people's heads. And critically, it is never urgent enough to win against feature work in a sprint planning meeting.

That is not a tooling problem. That is a manufacturing problem, and it was solved a century ago for physical goods.

Craft production says a skilled person handles each item end to end. That is how most FinOps work happens today: a practitioner picks up a finding, chases the owner, negotiates the change, follows up, verifies. It works, and it does not scale, and it stops the moment that person goes on holiday or gets pulled into an incident.

We lived this ourselves. When we first published our numbers, we identified four hundred thousand dollars of savings against one point nine million in cloud spend. Every one of those figures was a projection. We had a discovery system that found the waste, sorted it, and surfaced it as an opportunity, and then the same thing happened that happens everywhere. The findings sat there. No one owned them. They bounced between finance and engineering, waited on approvals, and lost to product deadlines. Discovery was solved. Completion was not.

That gap is exactly what the factory closed. The discovery step that once produced a projection now feeds straight into automated cloud cost remediation. Fixes route to an owner, ship as pull requests, and get verified in billing data. The four hundred thousand stopped being a number on a slide. Eighty percent of it became real savings on the invoice, and the remaining twenty percent we consciously declined.

Station one: turning noise into a work order. How AI agents find cloud waste on AWS

A finding is not "this instance looks oversized." That is an observation, and observations are cheap. A work order is something an engineer can act on without doing an hour of archaeology first.

The difference is context. What is this resource, what is it actually doing, what breaks if we change it, how much effort is the change, what does waiting cost us, and what is the value once it is done.

Here is what that looks like in practice. A single-service dashboard would have seen three unrelated blips. The factory saw one problem with a root cause. It started with a CloudWatch log group that had no retention policy, so logs accumulated forever and ran up storage cost nobody was watching. That was the symptom. Tracing it back, the factory found the cause was not the log group at all. A load balancer was throwing errors, and a misconfigured set of application variables in Kubernetes was amplifying them, spraying error logs into CloudWatch at volume. Three services, three teams, three dashboards, and the waste lived in the connection between them.

That is the difference between a tool that reports metrics and a system that reasons across them. Fixing the retention policy alone would have capped the bleeding and left the wound. The factory surfaced all three linked opportunities from one investigation: the load balancer errors, the Kubernetes misconfiguration, and the unbounded log retention.

Station two: routing. How to make engineers accountable for cloud cost

Here is the unglamorous truth. Most cloud savings are not lost because nobody found them. They are lost because the finding arrived in an inbox belonging to someone who could not act on it, or belonging to nobody at all.

A finding without an owner is a ticket that ages. And the traditional fix, which is to auto-generate tickets from tool recommendations, makes things worse. Engineers learn within a week that the queue is full of things that are not actionable, and after that they stop reading it. You have not created accountability, you have created spam with a Jira logo on it.

We did not solve routing with a smarter ticket queue. We solved it at the data layer. Glassity's virtual tagging guarantees one hundred percent allocation: every resource maps to a service, and accounts without explicit structure get default services generated from the AWS account itself. Nothing is orphaned, so no finding can arrive addressed to nobody. Default services are not a parking lot either. On day one of connecting Glassity, each one is assigned to a real owner, so even resources with no tagging history start life with a human name attached. And when a service is created, our AI interviews the owner -- what the service does, who runs it, how they work. That context travels with every work order the factory produces.

This is the quiet engine underneath everything else in this article: the factory does not only route work, it remembers. Every service carries its interview. The system knows what the thing does, who owns it, how that person works, and what normal looks like for it. Most cloud tooling discards exactly this context at the moment it matters most, which is why so much automated advice reads as technically correct and practically useless. Context is what turns a correct suggestion into one an engineer will actually merge.

What we did not expect was how much the system would build beyond fixes. Budgets turned out to be the revealing case, because every team understands a budget differently. The backend team wanted a straight AWS budget. Data science wanted budgets per experiment. The platform team built theirs from scratch. All of them shipped as Terraform. Then the factory suggested something we never designed: for the finance service, it proposed a PowerBI dashboard to monitor the budget, because the onboarding interview had captured that this owner lives in PowerBI, not in the AWS console. The routing layer was not just delivering work to the right person. It was shaping the work to fit them.

Station three: the fix, written as code. Why cloud cost remediation belongs in a pull request, not the AWS console

This is the station that made everything else possible, and it is also where we made our most consequential design decision.

The fix ships as a pull request into the repository that defines the infrastructure. Not as a change applied to the AWS console.

The reason is not stylistic. In any environment managed with Terraform or similar, the code is the source of truth. A change made directly in the console is drift. It survives right up until the next apply, at which point the infrastructure gets reconciled back to what the code says and your optimization quietly evaporates. Nobody gets alerted. The savings just stop, and if you are only reading projected numbers rather than realised ones, you may never notice.

This is the single clearest technical argument for why cloud provider native automation, however good it gets, cannot be the whole answer for an IaC-managed shop. It acts on state. The fix has to live in the code.

The second reason is trust, and it matters just as much. Engineers already have a mechanism for evaluating changes written by someone they do not know: they review the diff. Everything about a pull request is familiar. It can be read, questioned, rejected, rolled back. We did not need to invent a trust model for agent-written changes, because the industry built one years ago and everyone already uses it.

Station four: proof. How to verify cloud savings in actual billing data

Every station has a checkpoint, and the last one is the one that matters commercially: did this actually save money.

Projected savings and realised savings are different things, and the gap between them is where a lot of the industry's credibility has gone to die. A projection is a model output. A realised saving is a smaller number on an invoice. Only one of those is real, and only one of them should be allowed to count.

A merged PR is not a saving. It is a claim. The proof arrives in the next month-over-month billing data, where the change either shows up as a smaller number or it does not. And we do not let the claim close itself quietly: at closure, the factory creates a reminder ticket, so a human confirms the saving landed in the actual invoice before it counts. Projected numbers never graduate to realized ones without that check.

A smaller invoice is treated as a question, not an answer: was it our change, or did the workload simply shrink? The factory can tell the difference because it is not guessing from raw numbers -- it carries context from the service's onboarding interview. It knows whether this service's cost moves with traffic, whether a seasonal drop is normal, whether usage swings are expected. A drop that fits the service's known profile gets filed as what it is, usually an autoscaling gap, and never touches the realized number. Intelligence without context would just be confident guessing; the interview is what makes the classification trustworthy.

What we refuse to automate. Human-in-the-loop guardrails for agentic FinOps

I want to be direct about this, because every vendor talking about autonomous operations right now is quietly hoping nobody asks.

Autonomy is not a confidence score. It is a governance model. The real question is never "is the agent 90 percent sure", it is who signs off, who owns the blast radius, and who gets paged at 3am when something that looked safe was not.

Let me volunteer a failure. The agent proposed a textbook fix: an instance showed no usage, so it opened a PR adding a scheduler to shut it down outside working hours. The diff was clean, the reasoning was sound, and the savings math checked out. The reviewer rejected it. The instance was not idle. Its CloudWatch agent had a broken IAM role, so it had silently stopped reporting metrics, and the agent had done correct arithmetic on an empty dataset. The proposal would have scheduled downtime for a machine doing real work.

That failure taught us more than any success. No confidence score catches it, because the confidence was justified given the data -- the flaw was upstream, in telemetry the agent had no reason to distrust. Only a human who knew what the instance should be doing saw the absence of data as the anomaly. This is why the review gate is not a formality we tolerate; it is a sensor the machine does not have. The agent expects rejection as a normal outcome and iterates -- in this case, the real fix was repairing the IAM role, and the "idle instance" vanished from the findings.

So what is on our never-automate list? We never wrote one, and that is deliberate. Category lists give false comfort: they imply everything outside the list is safe to ship unsupervised, and nothing is. Our boundary is not drawn around types of change. It is drawn around accountability. Every opportunity is assessed on the board inside Glassity before it becomes work. Once assessed and assigned, responsibility sits with a named human owner, and the final gate is always the same: a person approves the PR artifact at delivery. The agent can propose anything. It can ship nothing. There is no confidence threshold above which the human disappears, because the question was never how sure the machine is -- it is who answers for the blast radius, and the answer is always a person with a name.

The gate is not just a safety mechanism either. It is the handover point where the work stops belonging to the machine and returns to people -- and what follows it is deliberately human: the win gets celebrated between the people who own it. A factory that ships savings nobody notices builds no culture. The approval moment is where the saving becomes theirs.

Prevention: turning fixes into guardrails and shifting cost left

The other half of this is prevention, which is the part of a factory nobody photographs. Once you have fixed a class of problem, the interesting question is how to stop it recurring, because otherwise you have built a very sophisticated machine for cleaning up the same mess forever.

Fixes that recur are failures on a delay, so the control center turns fixes into guardrails. Define a policy, say no RDS without Graviton, and any PR that plans to break it gets a warning before merge, not a finding after deployment. And every PR gets accountability built in: the factory comments with the total cost change of the planned Terraform, so the engineer sees exactly what the change costs while they can still change their mind.

The principle behind this is shift-left. Optimizing after deployment is the expensive path: the resource is live, the workload depends on it, and unwinding it takes discovery, routing, a fix, a review, and a billing cycle to verify. Catching the same problem in the pull request costs one comment. So we moved the optimization process to the earliest point in the development cycle where it can act, and we inform engineers in the place they already live -- GitHub -- not in a dashboard they have to remember to visit. Cost review happens where code review happens. The cheapest waste to eliminate is the waste that never reaches an invoice.

FinOps for AI: the question nobody is asking in 2026

Here is where I think this goes next, and I would rather be wrong in public than quiet.

Right now a large number of engineering organisations are building their own software factories, in the newer sense. Agents writing code, opening PRs, shipping features at a rate no human review process was designed to absorb. The productivity numbers coming out of that are real and they are impressive.

Every one of those generated lines eventually becomes infrastructure. Every piece of infrastructure becomes a bill. And the agents themselves consume tokens, which is a second bill that most organisations are not tracking with anything like the rigour they apply to compute.

Look at what the biggest players shipped this year. In April, Google Cloud announced its next generation FinOps suite for the AI era: an Explainability Agent that investigates what is driving your AI costs, and Spend Caps that pause API traffic once a project hits its budget. Both are genuinely useful. Neither is a fix. One tells you why the number is large. The other stops the work when the number gets too large, which lowers spend by halting the business rather than by making the business cheaper to run.

Google's own success metrics say the quiet part out loud. They report cost reporting adoption up seventy five percent and time spent on cost analysis down eighteen percent. Both of those measure looking. Neither measures fixing.

So we are collectively industrialising the production of software, at speed, without industrialising anything on the other side. We spent fifteen years learning that unmanaged cloud growth produces waste, poor accountability, and no unit economics. We are now making exactly the same mistakes with AI, faster, and with less visibility.

A factory that produces needs a factory that maintains. That is the argument I would make to anyone standing up an agentic pipeline this year: you are about to generate infrastructure faster than your cost practice can absorb it, and if you do not build the other half, you will be having a very uncomfortable conversation with your CFO in about eighteen months.

What came out the other side

The numbers we stand behind are the ones that survived the whole line. Nothing in our realized figure comes from a projection, and every dollar of it traces from finding, to work order, to pull request, to invoice. That traceability is the product. The savings are the by-product.

The honest closing thought is that this goes beyond FinOps. Building the line forced us to rewrite how discovery works. It no longer runs on brittle SQL that has to stay compatible with three different billing formats. Agents execute workflows described in natural language, which means what the system can investigate is bounded by what we can articulate, not by what somebody remembered to write a query for. That is a different kind of ceiling, and it is a much higher one.

The same architecture has obvious neighbours, SecOps and CloudOps among them, but we have not run it there yet and I would rather show you what we have actually built than what we could imagine.

Which brings me to the part I think matters most here, and it is not the savings. Glassity delivers a FOCUS dataset, and I sit on the FOCUS team working on the spec, with a bottom-up analysis of every token consumed. The agents doing the work are metered in the same open standard as the infrastructure they fix.

Here is the hook for what comes next. Everyone already knows the cost of AI, because everyone pays the bill. Google will now break that bill down for you by model, by API key, by input and output tokens. The cost side of the ledger is nearly solved. What nobody can see is the other side of the ledger. Our dataset carries both: every token consumed, and the value each action generated -- the verified saving that landed in the invoice. That is the actual ROI of an agent's work, measured per action, and it is the real challenge of Tokenomics and our achievement here. If you know your ROI, you can decide about your AI investment. Until then, you are just paying a bill and hoping. Welcome to the world of Tokenomics.

Come hear the whole thing in person, or get the recording

I am giving this talk in full at AWS Meetup Estonia vol.3, on Thursday 13 August 2026, 17:30 to 19:30, at Lift99, Telliskivi 60a/5, B-building, Tallinn. It is hosted by Glassity and Revolgy, and I am sharing insights alongside Nicolai Antiferov from Bolt on AWS quota monitoring without CloudWatch, and Andoni Alonso Fernández on security and auto-remediation in AWS. My session is the one this article came from: building a FinOps software factory, the stations, the failures, and the numbers that survived. There will be a live audience poll at the start and I will show you the results at the end, so you will find out where the room actually sits on letting agents touch production. Entry is free, capacity is limited, and it runs in English. Register on Meetup.

Not in Tallinn? The session is being recorded. Leave your email below and I will send you the link as soon as it is edited, along with the slides. No newsletter, no sequence, just the recording.