- Why we ran this session
- 1. For the engineer, leaving the ticket alone is the safe choice
- 2. The bottleneck is often one engineer
- 3. GitOps makes repeated cost changes too much work by hand
- 4. Most cost-caused outages come from missing context
- 5. The agent should own the handoff, and people approve the change
- 6. One agent per job keeps the security scope small
- 7. The FinOps agent has its own bill
- Where to start
- FAQs
Speakers: Toshal Khawale, Managing Director, Cloud Transformation, PwC · Shiv Pratap Singh, Co-founder and CTO, NudgeBee · Rakesh Rajendran, Founder and CEO, NudgeBee (moderator)
Most identified cloud savings are never applied because of who carries the risk and how much work the change takes. The data is usually there already. For the engineer who owns the workload, leaving a cost ticket alone is the safe choice. Agents help when they take over the work between finding a saving and shipping it: sizing on the right time window and the right resources, opening a pull request that a senior engineer approves, and staying limited to one job. Decisions that need business context stay with people, and the agents' own model costs are tracked like any other workload.
The six areas we covered:
- Why cost recommendations die in the ticket queue
- Kubernetes rightsizing: who approves the change at 3 a.m.
- Cost anomalies that lead to action rather than another alert
- Scoping agents by task and persona
- Where automation stops in regulated and sovereign clouds
- Proving realised savings to finance
Why we ran this session
FinOps has come a long way in five years. Most teams now have tagging, showback and dashboards that show where the money goes. Even so, the figure people keep quoting is that only about 30% of identified savings get applied. Shiv asked where that number comes from, which is fair, but nobody on the panel thought the real figure was much higher.
We asked Toshal Khawale, who leads cloud transformation work at PwC, and Shiv Pratap Singh, our CTO, where the rest goes. Toshal put it in one sentence early on: the money is lost between knowing and doing. The seven points below are what we took from the hour.
1For the engineer, leaving the ticket alone is the safe choice
Rakesh said it plainly during the session: if a change causes a production issue, it's on me, and a cost issue is just a ticket.
From the engineer's side the maths is simple. A rightsizing that works saves the company money and earns them very little. One that causes an incident lands on them, in front of everyone, usually at a bad time. Nobody gets paged for an over-provisioned deployment. So teams make the easy, safe changes and leave the complex ones alone, which is a sensible reaction to the risk they carry.
Toshal half-joked that the answer is to tie engineers' appraisals to the cost they control. His more serious point came straight after: when cost is everyone's responsibility, in practice nobody owns it. Better dashboards won't change that. What changes it is making a cost change cheaper and safer to carry out, and that is the work an agent can take on.
2The bottleneck is often one engineer
Toshal described something most platform teams will recognise. Any Kubernetes change that touches cluster autoscaling, node affinity or a PodDisruptionBudget waits for the one person on the team who can say with confidence that it won't cause downtime.
Rakesh teased him that consultancies pushed everyone towards microservices and Kubernetes and are now finding thousands of services hard to optimise. Toshal took it well and pointed out that everyone on the call had played a part. The point holds either way: the more moving parts there are, the fewer people understand what a change will knock on to, and the slower cost work goes. A good cost agent captures that engineer's checks, such as PDB headroom, autoscaler behaviour and affinity rules, so changes stop waiting for one person's calendar.
Find the root cause faster
NudgeBee finds the root cause of an incident, with evidence, and suggests a fix. Runs self-hosted in your own environment.
3GitOps makes repeated cost changes too much work by hand
Shiv raised a point that is easy to miss. GitOps is the right way to run production, and it also makes recurring cost changes impractical for people to do manually.
His example was a recommendation to scale a workload up every morning and down every evening. With GitOps, that is a pull request twice a day, in the right repository, through the right approvers, every day. Nobody keeps that up, so the saving gets closed as "won't fix" even though it was correct.
Loosening the process to get the saving would be the wrong answer. The agent can do the work of following the process: write the pull request, attach the evidence, and leave the engineer with a review and a merge.
4Most cost-caused outages come from missing context
When the panel talked about rightsizing changes that went wrong, the same causes kept coming up.
The time window was too short. This was Shiv's most common case. Someone looks at 7 or 15 days of CPU and memory, sees headroom and cuts the requests. Then month-end or quarter-end reporting runs, the batch jobs need far more memory, and pods get OOM-killed and go into CrashLoopBackOff. The data was accurate, but it covered the wrong period.
The wrong resource was measured. A database shows low CPU and memory, so it is moved from 12 GB to 8 GB. The workload runs heavy queries and large joins, so it depends on IOPS, and the smaller instance has less I/O capacity. It doesn't crash. It just gets slow.
A setting outlived its reason. Toshal's example was a PodDisruptionBudget set when a service ran a handful of pods and never revisited after it grew to hundreds of replicas. Every setting had a reason when someone chose it, and the useful question is whether that reason still holds.
Each of these is a check an agent can run every time: size on p99 over a window that covers your business cycles, look at the resource that limits the workload, and find out why a setting exists before changing it. A person in a hurry tends to skip them.
How teams actually run it
Four AI assistants sharing one context across SRE, FinOps, Kubernetes and CloudOps, with every change gated on human approval.
5The agent should own the handoff, and people approve the change
Shiv was firm that he would never let an agent change production directly through the Kubernetes or cloud API. The agent raises a pull request, a senior engineer reviews it with the metrics, and the normal GitOps pipeline applies it.
Most savings are lost in the handoff between the FinOps team that finds them and the platform team that would have to raise the pull request. An agent that finds the saving, gathers the evidence, writes the change and opens the pull request removes that handoff, and the approval stays with the people accountable for the service.
Toshal covered the other side. Some decisions need business context the agent doesn't have. His example was an availability zone that went down after a recent geopolitical incident hit a cloud provider's data centre. Automation can redeploy across zones without trouble. Choosing which region to move to depends on where your customers are, which services that region offers and how much latency the business can accept, and an agent doesn't know where your customers are. The panel's view was to automate the simple, repeated changes heavily and keep people on the complex ones. In most estates the simple, repeated changes make up most of the savings that never get applied.
6One agent per job keeps the security scope small
Should you build one FinOps agent that can do everything? Shiv's experience says no. An agent that can change Kubernetes clusters, call AWS APIs and open pull requests across repositories has a very wide security scope, and nobody reads its audit logs until something goes wrong.
He prefers agents that work much like standard automation, with a fixed path and the model making decisions only at specific points. The FinOps agent updates infrastructure and raises a pull request. If it notices something odd in the logs, it leaves the debugging to a different agent with different permissions.
Toshal compared it to cricket in the 1990s. India relied heavily on Sachin Tendulkar, while Australia won with specialists in defined roles. He'd build FinOps automation the Australian way, with purpose-built agents and a person in the loop. Cloud IAM roles are broad, and a role that can resize an instance can often delete it too, so scope each agent by its task.
7The FinOps agent has its own bill
Rakesh pointed out the irony: agents are being sold as a fix for cloud waste while AI spend has become a cost line of its own.
Shiv's answer was about how the agent is built. An agent that watches logs, metrics and traces all day can easily spend more on investigating a spike than the spike cost. So he routes work by task. Summarising megabytes of logs doesn't need a frontier model such as Opus; a smaller model can parse metrics and write the report, and the expensive model handles planning. At large scale, open-weight models bring the cost down further.
The question there is trust. If a third party hosts the open-weight model, you need to be comfortable sending it your telemetry, in the way you already are with your cloud provider under an existing agreement. Shiv was open that the answer depends on the provider and on your data policy. Toshal added that the model should fit the use case, and that some decisions are better made by small purpose-built models at a fraction of the cost.
The practical step is to track each agent's cost per completed action next to the saving that action produced. Without that comparison, it is hard to show finance a realised saving at all.
Start free, any scale
Readable source, self-hosted, and free at any scale. 2 clusters or cloud accounts free on Cloud SaaS.
Where to start
Toshal's advice was the most practical of the session: start in non-production. The risk is low, the savings are real, and you can build a repeatable pattern with actual figures before anyone asks the agent to touch production. Shiv added that measurement should be in place before you scale up, covering recommendation quality, savings that were applied and what the agent costs to run.
If we had to put it in three lines:
- Treat the cost gap as an execution problem, and start with the safe, tedious backlog.
- Give each agent one job, have it open pull requests rather than call APIs, and keep a person approving.
- Track each agent's cost per completed action against the saving it made.
Watch the full webinar: YouTube · NudgeBee FinOps agents: nudgebee.com/ai-finops · NudgeBee OSS on GitHub: github.com/nudgebee/nudgebee
FAQs
Shiv writes about AI agents, SRE, CloudOps, Kubernetes, FinOps, platform engineering, and building reliable AI systems for cloud infrastructure. With 13+ years of experience in platform engineering, data platforms, distributed systems, and enterprise cloud infrastructure, he brings first-hand technical expertise to the challenges of AI-driven cloud operations.