about the project
FinOps Autopilot — From Cloud Waste to Action
Cloud costs rarely explode because of one big mistake. They grow quietly through idle resources, oversized clusters, inefficient workloads, and infrastructure that no longer matches actual usage. Finding these opportunities is one problem; actually fixing them safely is another.
We built FinOps Autopilot to close that gap.
Inspiration
Traditional FinOps tools are excellent at telling teams where they are wasting money, but the final steps are still highly manual: investigate metrics, understand the infrastructure, decide what to change, edit Terraform, create a pull request, run validation, and communicate the expected savings.
We asked:
What if a FinOps system could do the engineering work instead of simply giving recommendations?
That became FinOps Autopilot — an autonomous cloud cost optimization agent designed to investigate waste, reason about safe optimizations, generate infrastructure changes, validate them, and prepare them for human approval.
What We Built
Our core workflow focuses on GKE cluster right-sizing.
For our deterministic demo scenario, the agent analyzes a cluster with:
- 12 nodes
- 21.4% CPU utilization
- 28.7% memory utilization
It identifies over-provisioning and calculates a recommended configuration of 5 nodes, producing a projected saving of $432/month, or $5,184/year.
The important part is that FinOps Autopilot does not stop at the recommendation.
It follows the complete workflow:
Analyze → Reason → Decide → Act → Validate → Remember → Report
The agent can generate the corresponding Terraform change, prepare a GitHub Pull Request, run validation, persist the execution, and present the result through an executive dashboard.
How We Built It
The system is built around Google Agent Development Kit (ADK) with Gemini 3.5+ as the reasoning layer.
The asynchronous architecture is designed around Google Cloud:
Cloud Scheduler
↓
Pub/Sub
↓
Cloud Run
↓
Google ADK
↓
Gemini 3.5+
↓
┌────┴───────────┐
↓ ↓
BigQuery Cloud Monitoring
↓ ↓
└───────┬────────┘
↓
Optimization Agent
↓
Safety Policy
↓
Terraform
↓
GitHub PR
↓
Cloud Build
↓
Firestore
↓
Dashboard
BigQuery provides the cost-analysis path, while Cloud Monitoring provides infrastructure utilization data. Specialized agent tools process this information before the optimization decision is made.
The optimization engine performs the right-sizing calculations programmatically rather than simply displaying a model-generated number.
The generated infrastructure change is then treated as an engineering artifact rather than an instruction. The system prepares a Terraform modification and routes it through a pull-request and validation workflow.
Safety First
We deliberately did not give the agent unrestricted production access.
FinOps Autopilot follows:
AI reasoning → Safety policy → Terraform change → Pull Request → Validation → Human merge
This means the agent can perform the repetitive engineering work while the final production change remains under human control.
We also designed the system with explicit execution states and idempotency safeguards so retries do not blindly repeat the same optimization.
What We Learned
One of our biggest lessons was that building an agent is not just about giving an LLM access to tools.
The valuable part is the workflow around the model.
Gemini provides reasoning, while deterministic tools handle calculations, infrastructure modifications, validation, persistence, and policy enforcement. This separation makes the system more predictable and auditable.
We also learned the importance of execution memory. An autonomous system needs to remember what it has already done, what evidence supported a decision, and whether an action succeeded or failed.
Finally, we learned that reliability matters as much as intelligence. For our demonstration, we created a deterministic demo mode so the complete workflow can be reproduced without depending on delayed billing exports or changing cloud telemetry.
Challenges
The biggest challenge was connecting reasoning with real engineering actions while maintaining safety.
It is easy to generate a recommendation such as "reduce the cluster size." It is much harder to turn that recommendation into a valid Terraform change, validate it, track its execution, calculate its financial impact, and ensure that a retry does not create duplicate actions.
We also had to design the system so that simulated demo operations are clearly distinguishable from live cloud operations. This led to a dual-mode architecture: deterministic seeded data for reproducible demonstrations and live Google Cloud integrations when the required credentials and services are configured.
What's Next
Today, FinOps Autopilot demonstrates GKE right-sizing as its core optimization workflow.
The same agent architecture can be extended to additional cloud cost problems such as idle compute, storage optimization, inefficient workloads, and other infrastructure waste patterns.
Our vision is to move FinOps from a passive reporting function toward an AI-powered engineering loop that continuously finds safe optimization opportunities, prepares the required changes, proves their impact, and keeps humans in control of production.
FinOps Autopilot doesn't just tell you where your cloud money is going. It does the engineering work required to safely bring that cost down.
### One important thing
I intentionally wrote **“projected savings”** and **“demo scenario”** rather than claiming that we've already saved a real company $5,184. That's safer and more credible for judging.
Also, don't mention **Veo** in this section unless we actually integrate it. If we do get it working later, we can add it naturally.
**Next field after this is “Built with.”** We can fill that one very quickly.
Log in or sign up for Devpost to join the conversation.