From recommendation to work
A spreadsheet of cloud savings can identify waste, but it cannot change production. Finding waste and fixing it are different jobs, with human review and execution sitting between them.
In its Legit Security case study, OpenOps says 90% of identified cloud-cost opportunities were automated and overall cloud spend fell 30%. The first figure describes how extensively recommendations were turned into work rather than left as suggestions.
A dashboard does not inherit the pager.
Someone still has to decide whether a recommendation fits the service, authorize the change and account for what happened. A dashboard does not inherit the pager. OpenOps released an open-source engine designed to turn those recommendations into repeatable workflows, giving cost-saving proposals a defined route to execution.
The results are reported by the vendor, rather than independently established task by task. The figures do not show which changes produced the savings, who approved individual actions or how production risk was handled. A percentage can summarize an outcome without explaining the decisions behind it.
Put approval in the workflow
OpenOps combines workflow templates, AI-assisted drafting, human approval, logs and versioning. The division of labor is straightforward: AI can help assemble steps, while the workflow controls execution. Drafting a change and authorizing it are different jobs. A written plan does not approve itself.
Consider an illustrative walkthrough, rather than a reconstruction of Legit Security’s deployment. A team can turn a cost recommendation into a sequence of steps using a template and, potentially, AI assistance. Human approval controls whether the sequence proceeds. Logs record execution, while versioning makes changes to the workflow traceable over time.
Drafting a change and authorizing it are different jobs.
That puts approval directly on the route from recommendation to action instead of leaving it in a separate conversation that people have to remember. It also makes approval part of the defined process rather than a general instruction to keep a human involved.
That structure still depends on a competent owner. An approval step records a decision; it does not establish that the underlying judgment was correct or that executing the workflow was safe. Versioning can make workflow revisions traceable without making those revisions sound.
Approval is not proof
The useful questions are about ownership: who can approve a proposed change, what evidence that person inspects and who is accountable if the change damages the service. An approval step records a decision; it does not make the decision sound. The control creates a record, not proof of good judgment.
An approval step records a decision; it does not make the decision sound.
Savings require similar context. Interpreting a 30% reduction requires a measurement window, a comparison baseline and a calculation method. The headline figure does not provide those details on its own. Likewise, automating 90% of identified opportunities does not reveal whether the remaining 10% represented the largest savings, the highest risks or the least worthwhile work. Counting opportunities gives each item equal weight even when their financial significance differs substantially.
OpenOps also advertises a 2bcloud case study reporting 10% efficiency gains for that customer. That result should remain distinct from a cloud-spend reduction. Efficiency and expenditure are different measures, even when they appear alongside each other in company materials.
Measure completed AI work
OpenOps CEO Amit Saar has pointed to token-level calculations and GPU-capacity economics as the next FinOps problem. That suggests a possible use for the workflow engine beyond conventional cloud-cost cleanup. Measuring another category of consumption is one task; governing the decisions that create that consumption is another.
For AI workloads, a useful evaluation target would be cost per completed task, paired with an explicit standard for what counts as completed. A cheaper attempt is not necessarily a cheaper result. Lowering the cost of an individual attempt can look efficient while leaving the underlying work incomplete.
A cheaper attempt is not necessarily a cheaper result.
That is an evaluation criterion, not a claim about an OpenOps feature: an intervention should be judged against the work it actually finishes. The distinction matters when token or GPU costs are optimized independently of outcomes.
The Legit Security case does not isolate AI’s contribution to the reported savings. There is also no public customer result yet establishing savings from OpenOps’s token-economics work. What the company’s approach does separate on paper is suggestion, authorization and execution. Those are three distinct jobs, even when software moves rapidly between them.
Whether that machinery can govern cost per completed AI task remains an open question and a result worth publishing. Until then, lower costs for unfinished work do not establish lower costs for completed work.
