For those following along with these issues regarding the work I’m doing for a large client, you know we’re in the middle of updating tags while also starting to identify waste to clean up.

That parallel work is moving forward, even after the exec sponsor suggested we find significant savings this calendar year. I didn’t say it wasn’t possible. I think the amount is possible. The timing is the problem. So I’ve been thinking about how we get there sooner rather than later, and whether finding the waste can speed up the rest of the process. Good question. Some potential answers below.

We started adding the new tags with scripts, and Azure Policy is doing the enforcement. Same principle as before: we are only adding new tags right now. Existing tags stay exactly as they are. And while we started to implement the policies, we are in Audit mode to start, before Deny. Otherwise, it could get ugly, quickly.

The new tags also provide something else. Every team needs a tag that points to a distribution list. That's the part that is missing, and now more than ever I wish it was in place because the client went through a reorg.

People moved teams, teams were reallocated under different leadership and responsibility, and a few of the lists we were about to rely on now point at groups that no longer exist. But the people on the DLs will still get notification. Try tracking down an owner for a resource where there was no clear owner and comms channel. Good luck!

The waste identification has been done with the help of AI agents. Because AI hype with no implementation behind it bothers me, I’ll be specific about what that means. There are no agents running loose in the environment.

The setup splits the work in two. My main session does all the measuring, read-only, through (in this case) Azure’s own tools: Resource Graph for finding the resources and Cost Management for what they cost. Then it hands a brief to the reasoning agents. The agents can’t touch the cloud and can’t write files. They read the brief, tell me what they think it means, and send back the queries they want run. I review those and run them. It’s slower than letting an agent loose, but I can validate every answer.

The output is a line item report: the resource, its owner (if we have one), annual cost, and why it was flagged, plus a bunch of other metadata we find handy. Each report is a single Resource Graph query. Paste it into the portal (or run it from the CLI) and download the results as a CSV.

I think the following will be the most useful part to share.

When originally looking for orphaned disks there was a mistake that needed to be corrected. An empty managedBy field is not the same as unused. About 40% of my first orphan-disk number was not waste. Some were disaster recovery replicas, some were backup artifacts, and one was a production Kubernetes volume. Delete those and you have an outage, along with savings. (JK!)

Stopped VMs had the same problem. A deallocated VM stops billing compute but keeps billing its disks. A VM stopped from inside the OS bills compute in full. An earlier version of the agent priced the deallocated ones at full compute and reported about 4.5 times the real number. No good.

And I removed one finding outright. Two reservations looked underused until I realized my view was filtered to one slice of a shared reservation. The lesson: never judge utilization from a filtered view.

These mistakes led me to change my approach. The agents now have a rule I like and added as I learned the best way to implement them: every figure carries a label for how it was obtained. Measured, derived, or unknown. If it's a benchmark with no source, it doesn't get a dollar range next to the measured numbers.

Ironically, someone just posted in the FinOps Foundation Slack about using agents, and I joined the conversation. I wanted to hear how people are using agents to do real work inside their companies. The use cases were specific and unique, and super interesting to learn about. Most had moved past finding waste. They were using agents to improve their workflows.

Building one isn't the hard part anymore. And sharing one isn't technically hard either. Skills and plugins can be generic. Mine are. The agents don't know anything about my client. The client specifics (scope, tags, thresholds, who to contact) are context you provide, so someone else could install the same agents and fill in their own.

So what's left? That's the question I keep coming back to. Knowing what to look for is nuanced (like the examples above of what the agents got wrong), and every client and business is unique and always changing. I think a shared agent that finds waste is only as good as the checks behind it.

Separate the measuring from the thinking. Let one session pull the data through your cloud's own tools, read-only. Give the agents a brief, not access. If you can't check an answer in the portal, don't trust it.

Make every number say where it came from. Measured, derived, or unknown. An agent will happily hand you a confident dollar figure with nothing behind it, and "unknown" is a better answer than a guess.

Keep a corrections log. Re-derive each number from live data before it goes to the client. Mine moved, some by more than double, and one finding got retracted. Keep the client specifics in one file per estate so the agents stay reusable.

Remember - an agent can find the waste. It still can't tell you who owns it.

If you've shared an agent or skill with another team or another company, I'd like to hear how that went. How did they find it, and what did they have to change? Feel free to send to me at [email protected]. I’ll respond to every inbound that I receive.

Oh, and if you would like me to publish my agents in an open source repo, I would love to hear that feedback as well.

Written with the help of AI. All the ideas expressed are mine and mine alone.

If you would like your company included in the Spotlight, contact the CloudXray AI Team

Company: CloudXray AI

Category: Managed Services & Consulting

What They Do: FinOps Consulting & Advisory Services; Owners & maintainers of the single largest FinOps company directory (finops.cloudxray.ai)

Why It Matters: Companies still need guidance on implementing FinOps and understanding the landscape of companies that exist