After my cloud-ops-for-a-week experiment, several people in the comments asked the obvious next question: what happens if you point an agent at the bill instead of the ops queue?
So I ran it. One agent, read access to our AWS and GCP accounts plus billing data, MCP tools for querying resources and metrics, and exactly one prompt:
"Cut our cloud bill by 20% without breaking anything. Show me your plan before you touch anything."
Two ground rules from the start: the agent got read-only credentials (plans only, no execution — I applied approved changes myself), and it had to justify every line item with actual metrics, not vibes. Here's what a week of that produced, sorted into the good, the scary, and the genuinely surprising.
The good: it found the boring waste instantly
Within the first hour, the agent produced a list a human FinOps review would have taken days to assemble:
- 11 unattached EBS volumes (oldest one: 9 months, from an instance terminated last year)
-
A dev RDS instance at 3% average CPU over 30 days — provisioned as
db.r5.xlarge"temporarily" for a load test - Two NAT gateways in a region we'd migrated out of, faithfully billing ~$32/month each for zero traffic
- 4 load balancers with zero healthy targets — the targets were deprovisioned, the LBs weren't
- Staging running 24/7 with request counts flatlining to zero from 8pm to 8am every single day
Projected savings from just this list: ~14% of the monthly bill. None of it required cleverness. All of it required looking, which nobody had done because looking is tedious. This is the strongest case for agents in FinOps: the discovery layer, where wrong answers are cheap because a human verifies before anything executes.
The scary: the plans that would have caused incidents
This is the section people actually asked for. Three plans I rejected:
1. It wanted to delete "unused" snapshots that were our DR baseline. The snapshots had no recent restore activity and no tags (our fault), so the agent classified them as orphaned. The metrics genuinely supported the conclusion. The context — "these are the disaster-recovery baseline, they're supposed to sit untouched" — lived in a Confluence page and two engineers' heads. Metrics-driven reasoning with no access to intent will confidently propose deleting your safety net.
2. It proposed downsizing a "3% CPU" instance that was memory-bound. Classic. CloudWatch doesn't report memory by default; the agent saw idle CPU and recommended halving the instance. The box was running an in-memory cache at 85% RAM. Downsizing = OOM-killer roulette. Lesson: an agent reasoning from an incomplete metrics surface doesn't know the surface is incomplete.
3. It wanted to buy reserved instances during a migration. Mathematically correct on 30 days of data — those instances had run flat-out all month. What the data didn't show: we were migrating that workload to GKE within the quarter. A human with calendar context kills that plan in five seconds; the agent would have locked in a year of commitment.
The common thread: every dangerous plan was locally rational. The agent was never wrong on the data it had. It was wrong on the data that isn't data — intent, plans, tribal knowledge.
The surprising: it negotiated with itself
The genuinely unexpected part. Told that "without breaking anything" was a hard constraint, the agent started attaching confidence levels and rollback plans to its own suggestions, unprompted, and split its output into "safe to automate" vs "needs human review." Its taxonomy was roughly:
- Reversible in seconds, zero user impact (stop idle dev instance) → high confidence
- Reversible with effort (downsize, snapshot-then-delete) → medium, human approves
- Irreversible or commitment (delete data, buy RIs) → flagged, refuses to recommend without confirmation
That's... the correct architecture. The agent independently converged on the plan/approve/execute split that we'd already learned the hard way building scheduling and one-click remediation into ZopNight — where every remediation ships with its undo, because the undo is the product. Watching a model reinvent that boundary from a one-line constraint was the most interesting result of the week.
Final scorecard
| Result | |
|---|---|
| Savings identified | ~19% of monthly bill |
| Savings I actually applied | ~12% (the rest needed refactors or timing) |
| Plans that would have caused incidents | 3 |
| Incidents caused | 0 — because plans ≠ execution |
| Time I spent reviewing plans | ~4 hours across the week |
12% of the bill for four hours of review is a spectacular trade. But read the table again: the zero in row four exists only because of the read-only rule. Same experiment with write credentials is a different article, probably titled "post-incident review."
The one-line takeaway: agents are already excellent at finding the money and terrible at knowing which findings are traps. Structure the work so those two skills stay separated — agent proposes, human (or hard policy) disposes.
Would you give an agent write access to your infra for this? Genuinely curious where people's lines are — the comments on my last experiment convinced me nobody agrees yet.
Top comments (0)