GCP Infra Adviser Agent

Inspiration

Staying on top of cloud infrastructure takes a lot of work: proper VM sizing, IAM permissions, idle resources. It's easy to fall behind.

GCP provides usage recommendations and insights for free through the Recommender API: flagging oversized VMs, unused permissions - resources burning money for nothing. The data is there, ready and waiting.

But between these insights and a code change, there are many manual steps:

  1. Call the API or check a dashboard
  2. Read through JSON
  3. Cross-reference Terraform to figure out where the resource is created
  4. Open a ticket
  5. Assign it
  6. Create a merge request
  7. Review & Merge it

This causes friction and the waste compounds.

Built on top of GitLab's Duo platform, the GCP Infra Adviser agent closes that gap — in one prompt.


How It Works

Architecture Overview

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────────┐
│  Terraform Plan │────▶│  GCP Infra Agent │────▶│  MCP Server         │
│  (tfplan.json)  │     │  (GitLab Duo)    │     │  (Cloud Run)        │
└─────────────────┘     └────────┬─────────┘     └──────────┬──────────┘
                                 │                          │
                                 ▼                          ▼
                        ┌────────────────┐         ┌────────────────────┐
                        │ exclusion-     │         │ GCP Recommender    │
                        │ rules.yml      │         │ API                │
                        └────────────────┘         └────────────────────┘

This agent runs as a chat agent in your editor: VS Code, JetBrains, or wherever GitLab Duo is enabled.

Step 1: Scoped Resource Detection

The agent reads the Terraform plan and identifies exactly which resources are being touched — not the entire project, just what's about to change. No noise, no overwhelming the developer with every recommendation in the account.

Step 2: Policy Enforcement

Before calling the API, the agent checks the team's exclusion-rules.yml — a policy file the team defines. Certain resources should never be touched, due to for example:

  • Security boundaries
  • Team-owned machines
  • Production instances with headroom requirements

The agent respects those decisions before making a single API call.

Step 3: Smart API Calls

The agent is intelligent about when to call the Recommender API. If a resource is being created for the first time, the agent understands there will be no data in the Recommender API for 1–2 weeks — so it skips the MCP server call for that resource entirely. No wasted API calls, no confusing empty results.

Step 4: Live Recommendations

It calls the GCP Recommender API through a custom MCP server running on Cloud Run, GCP's serverless platform, scoped precisely to the resources the developer is changing. It fetches live rightsizing data for:

  • Compute Engine (VM sizing recommendations)
  • IAM (unused permission removal)

Step 5: Developer Control

Throughout, the developer stays in control. Once the findings are presented, they choose what happens next:

Action Description
📋 Create Issue Log recommendations as a GitLab issue to revisit later
✏️ Apply Changes Let the agent edit Terraform files directly
🔄 Both Create the issue and apply changes
⏸️ No Action Keep the report for reference

The agent can run terraform plan to generate the plan file, but it will never run terraform apply. That step stays with the developer: applying infrastructure changes is a risk the agent won't take on your behalf.

Bonus: Impact Metrics

For every rightsized VM, the agent calculates:

  • Estimated monthly cost savings ($)
  • CO₂e reduction (kg)

So the developer sees not just what to change, but what it's worth. And the environmental impact scales proportionally with compute reduction.

Challenges Faced

  1. Scoping recommendations precisely: Filtering a noisy API response to only what matters for the current change required careful Terraform plan parsing.

  2. Handling missing data gracefully: New resources have no recommendation history. Teaching the agent to recognize this and skip API calls was essential for a smooth UX.

  3. Balancing automation with control: The agent shouldn't act unilaterally. Designing the interaction to always give the developer final say was a core design constraint.

  4. Policy flexibility: Different teams have different rules. The exclusion-rules.yml pattern lets teams codify their constraints without modifying agent logic.


What's Next?

Since we built the agent on top of the Recommender API, the same pattern can be extended to idle disks, unused Cloud SQL instances, oversized GKE clusters, whatever the team needs most. In the future I would like to extend the tools, so the agent can handle all types of infra advice the Recommender API provides.

Built With

  • GitLab Duo — Agentic AI platform
  • GCP Recommender API — Cloud optimization insights
  • Cloud Run — Serverless MCP server hosting
  • Terraform — Infrastructure as code
  • Node.js — MCP server implementation

Built With

Share this project:

Updates