Anyone who has managed a modern cloud environment knows the feeling of staring at a monthly billing dashboard with a sense of impending dread. As infrastructure scales, traditional FinOps methods, which typically rely on reactive, dashboard-heavy reporting, are hitting a wall. We call this phenomenon “action paralysis.” It’s easy enough to spot a sudden spike in your cloud spend on a chart, but manually digging through tens of thousands of rows of billing data to find the precise technical root cause is an almost impossible task for a human. By the time a financial analyst finds the leak, the money is already gone.
This is where Generative AI is driving a fundamental paradigm shift. We’re moving away from simple visibility and entering the era of Agentic FinOps. The conversation is shifting from a retrospective “what happened?” to a proactive “here’s how we fix it.”
Imagine an agent that doesn’t just alert you to a spend increase but actually does the digging for you. It analyzes utilization metrics, reasons through your corporate policies, and suggests specific, code-ready fixes. For example, it might recommend rightsizing a specific GKE workload that is running hot or automatically identify backups that can be safely moved to a cheaper storage tier based on access patterns.
This new FinOps model is built on an “Observe-Reason-Act” framework. This means that a FinOps agent observes an organization’s billing data, reasons through the context (like budget constraints and architecture policies), and then acts by proposing or executing remediation steps. Crucially, this model bridges a long-standing cultural gap in many organizations; it connects finance teams (who know the budget but lack engineering context) with engineers (who know the tech but often avoid complex finance tools). Therefore, the modern FinOps agent acts as a real-time translator and advisor for everyone.
The 5-layer Agentic FinOps architecture
To achieve this level of agentic autonomy, we utilize a robust architectural foundation designed on Google Cloud.
This architecture moves beyond simple prompt engineering; rather, it establishes a layered, multi-agentic system where specialized agents work together to solve financial problems.
As illustrated in Figure 1.1 (see below), Agentic FinOps has five distinct layers, going from user interaction at the top to data foundations for the agent.
Layer 1: The Interaction Layer
At the top of this architecture sits the “Interaction” layer, which is Gemini Enterprise. The design philosophy here is to lower the barrier to entry for data analysis by providing a natural language interface. This allows users to ask complex, nuanced questions about cloud spend without needing to learn specialized query languages or navigate dense dashboards. Crucially, this layer transcends a simple chat interface by establishing workflow continuity with existing enterprise tools. By integrating directly with platforms like Slack and Gmail, and project management tools like Jira and GitHub, the FinOps agent embeds itself into the team’s daily operations. This means insights and actions are delivered where decisions are made, rather than in an isolated tool that must be checked manually.
Layer 2: The Multi-Agent Core Layer
Directly below interaction is the “Multi-Agent Core” layer, which functions as the central reasoning engine of the agent. When a query is processed, it is passed to a central orchestrator that employs a divide-and-conquer strategy. Rather than relying on a single agent to solve a multifaceted financial problem, the Orchestrator delegates specific tasks to a team of subagents. These are categorized as Base Layer Agents, which handle broader, more generalized analyses and architectural reviews, and Specialized Agents, which are invoked for highly targeted tasks such as dynamic SQL generation against BigQuery, anomaly detection, or predictive forecasting. This modular approach significantly reduces hallucination risk and ensures that the multi-agentic system scales with the complexity of user queries.
Layer 3: The Action & Execution Engine via MCP
To bridge the gap between analysis and execution, we have the “Action & Execution Engine” layer. Powered by Google Cloud MCP, and specifically leveraging the managed BigQuery MCP server in our repository below, this layer provides a structured, managed way to interact directly with cloud services. In our implementation, this means that an agent can securely query and analyze massive billing datasets in BigQuery without having to navigate the complexities of making direct REST API calls to BigQuery. This isolation prevents the agent from hallucinating invalid API calls and allows it to generate safe, structured execution plans and suggest precise code fixes with high confidence. Always operating under a human-in-the-loop for safety, this layer translates reasoning into direct, measurable cost reduction strategies.
Layer 4: The Context, Governance, and Data Foundations Layer
Every financial decision must be aligned with corporate guardrails, which is the responsibility of the “Context & Governance” layer. LLMs, while powerful, have a knowledge cutoff and don’t inherently know a customer’s company-specific, evolving policies. This layer overcomes that limitation by utilizing RAG to pull in active corporate policies, business drivers (such as planned product launches that explain spend spikes), and existing FinOps recommendations. By grounding the agent’s reasoning in these documents, we ensure that every recommendation generated not only reduces cost but also maintains compliance with internal standards.
This layer is anchored by FOCUS billing and pricing data stored in BigQuery, which offers a standardized view of cost data and provides the empirical baseline for all upper-layer operations. By adhering to the FOCUS standard, the agent can analyze spend across GCP (or any other hyperscaler!) without needing to learn different cloud billing dialects. Crucially, this layer also ingests real-time observability metrics and logs. This multi-dimensional view ensures that when the agent recommends, for example, rightsizing a resource, it validates the decision against actual performance data, which ensures that cost savings don’t come at the expense of application health.
Figure 1.1 - Agentic FinOps Architecture
The layers typically include: 1. Interaction Layer (Gemini Enterprise), 2. Multi-Agent Core (Orchestrator), 3. Action & Execution Engine (MCP), 4. Context and Governance (Policies/RAG), and Data Foundations (Billing/BigQuery)
Use case: The billing agent MVP
To demonstrate the power of this architecture, we developed a FinOps Agent MVP (try it here!). This agent is built using the Agent Development Kit (ADK) framework and showcases how the layers we described above come together in a real agentic use case.
This specific implementation connects Layer 3 (Action & Execution Engine) to a managed BigQuery Model Context Protocol (MCP) server, which allows the agent to interact directly with Layer 5 (Data Foundation) containing your BigQuery billing and pricing export.
Key features tied to the architecture:
-
Natural Language to SQL (NL2SQL): This feature, handled by the Specialized Agents in Layer 2, allows stakeholders to ask questions like “Why did my storage bill spike last Tuesday?” in plain English. The agent handles the complex translation and queries the Data Foundation (Layer 5) automatically.
-
Secure Data Access: By leveraging the managed MCP server in Layer 3, the agent is restricted to read-only access on specific billing and pricing datasets. This ensures that the agent can find answers without any risk of modifying your actual cloud resources.
-
Budget Management: The agent can automate and manage budget limits and alerts, acting as a proactive guardrail in Layer 4 (Context & Governance).
-
Automated Insights: By combining the data analysis from Layer 5 with the reasoning capabilities of Layer 2, the agent automatically identifies cost patterns, trends, and top drivers by service.
Step-by-step deployment guide
Here is how to replicate this setup using the codebase we provided:
Step 1: Enable BigQuery Billing Export (establishing layer 5)
Before building the agent, your cloud billing data must be available in BigQuery, forming your Data Foundation Layer. In the Google Cloud Console, go to the Billing page, select Billing export, and enable the Detailed usage cost export to a BigQuery dataset.
Step 2: Build the agent using ADK (implementing layer 2)
ADK provides the scaffolding needed to bootstrap production-grade agents. In the repo, you can see how we initialized the project in agent/agent.py using FinOpsOrchestrator to define the brain of the system. You’ll also find how we defined the specific “Forensic Data Researcher” persona in agent/sub_agents/struct_data/prompt.py, providing specific heuristics to look for anomalies and waste.
Step 3: Connect the managed BigQuery MCP server (implementing Layer 3)
The managed BigQuery MCP server acts as the connector between the FinOps agent and your data. In the prompt file (agent/sub_agents/struct_data/prompt.py), we established strict SQL grounding rules to ensure that the agent generates valid SQL that the MCP server can execute safely without hallucinating column names. This connects the reasoning of Layer 2 directly to the execution of Layer 3.
Step 4: Deploy to agent platform runtime (surfacing layer 1)
Agent Engine provides a managed, serverless environment for the agent’s logic. The file main.py in the repository demonstrates how to package the ADK-based agent as a FastAPI application. This makes it easy to deploy to serverless runtime platforms on GCP like Cloud Run or Agent Engine, eventually making the agent able to be surfaced on Gemini Enterprise (Layer 1) for an organization’s business users.
Step 5: Testing and “Golden Dataset” evaluation
Finally, validate the FinOps agent’s performance by testing it against a “Golden Dataset” of common billing questions, such as:
-
“Show me a month-over-month spend comparison for GKE.”
-
“What are the top 3 cost drivers for our production project?”
By following these steps, you transition from manual data analysis to an automated, intelligent workforce that empowers every stakeholder to take responsibility for their cloud spend.
Best,
Pathik Sharma, Aakansha Mehrotra, and David Dinh, with expert opinions and code contributions from Mandeep Singh Bawa and Shlok Karpathak