by datastudy.nl

Field notes for teams running cloud and SaaS FinOps in production

Engineering

FinOps explained: every stage, every action, and where AI agents fit

FinOps is the operating discipline for cloud and SaaS spend: three phases, 22 capabilities. AI agents now automate nearly half of them.

A donut chart showing the FinOps lifecycle split across three phases: Inform at 33 percent, Optimize at 33 percent, and Operate at 34 percent, with AI agent automation coverage reaching 45 percent of capabilities.
The FinOps lifecycle across Inform, Optimize and Operate phases, with AI agent coverage of capabilities. Data Today benchmark.

The average organization now runs workloads across three public clouds, two SaaS data platforms, and a growing fleet of AI services whose bills arrive before anyone has figured out who owns them. FinOps is the discipline that turns that chaos into a repeatable operating model. It is a cultural practice: engineering, finance and business teams collaborating continuously to make sure every dollar of technology spend buys something the business actually needs.

FinOps runs on a three-phase lifecycle (Inform, Optimize, Operate) that loops continuously. The FinOps Foundation, which maintains the open-source framework that most practitioners follow, organizes the work into six domains and 22 capabilities. Each capability is a specific, named activity that someone in the organization owns. And in 2026, AI agents are starting to automate the most repetitive parts of nearly half of them.

What are the three FinOps phases, and what happens in each?

The lifecycle is not a one-time project. It is a continuous loop that every team runs every month, and the three phases build on each other.

Inform is the visibility phase. Before you can optimize anything, you need to know what you are spending and why. This phase covers data ingestion (pulling billing data from AWS, Azure, GCP, Snowflake, Databricks and every other provider into a single queryable repository), allocation (assigning every dollar to a team, product or cost center using tags, labels and account hierarchies), reporting and analytics (making that data readable for engineers and finance alike), and anomaly management (detecting cost spikes before they become budget surprises). If your team cannot answer "what did we spend last month and who spent it" in under five minutes, you are still in the Inform phase.

Optimize is where the savings live. Once you can see the spend, you reduce it. This phase covers usage optimization (rightsizing overprovisioned resources, deleting idle ones, scheduling non-production environments to shut down overnight), rate optimization (committing to reserved instances, savings plans, or enterprise agreements in exchange for lower unit prices), architecting and workload placement (choosing the right service and region for each workload from the start), licensing and SaaS optimization (eliminating unused seats and renegotiating contracts), and sustainability (reducing carbon footprint as a side effect of reducing waste). The FinOps Foundation reports that organizations in the Optimize phase typically save 20 to 30 percent of their cloud bill within the first year.

Operate is the governance phase that stops the waste from coming back. It covers the capabilities that manage the FinOps practice itself: FinOps practice operations (running the monthly cadence, the steering committee, the showback reports), governance and policy (setting and enforcing budget guardrails, tagging policies, and approval workflows), intersecting disciplines (coordinating with IT asset management, IT financial management, and security teams), invoicing and chargeback (making sure the finance team can reconcile cloud invoices and charge costs back to the right business units), FinOps education and enablement (training engineers to read a cost report and make cost-aware architecture decisions), and FinOps assessment (measuring how mature the practice is and where to invest next).

The fourth piece, sitting alongside the three phases, is Quantify Business Value. This domain covers planning and estimating (what will a new workload cost before you build it?), forecasting (where is spend heading based on historical patterns and planned growth?), budgeting (setting limits and alerting when they are crossed), KPIs and benchmarking (how does your unit cost compare to peers?), and unit economics (what does it cost to serve one customer, process one transaction, or train one model?). Without this domain, FinOps is just cost-cutting. With it, FinOps becomes a business strategy function.

Which capabilities are AI agents already automating?

The FinOps Foundation published its first agentic AI use-case map in April 2026, and the pattern is clear: agents are starting with the high-volume, rules-based capabilities and moving toward the judgment-heavy ones.

Anomaly management is the most mature use case. AWS Cost Anomaly Detection already uses machine learning to flag spend spikes, and the AWS FinOps Agent (launched in preview in late 2025) takes it further: it runs on a schedule or on anomaly triggers, investigates the root cause by querying Cost Explorer and CloudTrail, drafts a summary in natural language, and posts it to Slack or creates a Jira ticket. The central FinOps team reviews the agent's output rather than doing the detective work themselves.

Reporting and analytics is the second frontier. Instead of building yet another QuickSight or Looker dashboard, teams are asking an agent "show me the top five cost drivers by service this week, compared to last week, broken down by team." The agent queries the cost data warehouse, generates the chart, and writes the commentary. AWS's agent does this. So do a growing number of third-party tools built on top of the FOCUS 1.0 billing data standard, which normalizes cost data across AWS, Azure, GCP and SaaS providers into a single schema.

Usage optimization is where agents start making actual changes. An agent can detect an idle EC2 instance or an overprovisioned RDS database, check whether it is tagged as production or sandbox, and either stop it automatically (if sandbox) or file a rightsizing recommendation for the owning team (if production). The agent does not need to understand the workload. It needs to understand the policy.

Rate optimization is the hardest capability to automate because it involves financial commitments. But agents are starting to model Savings Plan and Reserved Instance purchase scenarios: "if we commit to $50,000 per month of compute savings plans, our effective discount goes from 22 percent to 34 percent, and the break-even utilization is 62 percent." The agent runs the numbers. A human makes the commitment.

Tagging and allocation is a surprising bright spot. Agents are good at scanning untagged resources, inferring ownership from related resources that are tagged, and proposing tag backfill. They are also good at enforcing tagging policies at deployment time by integrating with CI/CD pipelines and Infrastructure as Code.

The capabilities that remain firmly human in 2026 are executive strategy alignment, intersecting disciplines, and FinOps education. Agents cannot negotiate with a VP or teach an engineer to care about cost. But they can prepare the data that makes those conversations shorter and more productive.

Bar chart of AI agent automation coverage by FinOps capability: anomaly management at 72 percent, reporting at 65 percent, usage optimization at 58 percent, tagging at 55 percent, rate optimization at 40 percent, forecasting at 38 percent, and strategy at 12 percent
AI agent automation coverage across FinOps capabilities in 2026, from anomaly management at 72 percent down to executive strategy at 12 percent. Illustrative. Data Today benchmark.

The spread is wide on purpose. Anomaly management is rules-heavy and data-rich, so agents handle most of it. Strategy is relationship-heavy and context-poor, so humans keep it. The middle band, from usage optimization through forecasting, is where the next two years of agent investment will land.

What does a FinOps team actually look like?

The FinOps Foundation defines six core personas. The FinOps practitioner is the person who runs the practice: they own the monthly cadence, the tooling, the reporting, and the cross-functional coordination. Engineering owns the actual resource usage and the optimization actions. Finance owns budgeting, forecasting, invoicing and chargeback. Leadership sets the strategy and the cost targets. Procurement negotiates enterprise agreements and commitment discounts. Product owns the unit economics: what does it cost to deliver the product, and is that number trending in the right direction?

In a 50-person engineering organization, you might have one dedicated FinOps practitioner. In a 500-person organization, you might have a team of three to five. In a 5,000-person organization, you likely have a FinOps center of excellence with practitioners embedded in each major business unit. The key principle is that FinOps is a central enablement function, not a central command-and-control function. The central team builds the tooling, sets the policies, and trains the engineers. The engineers make the day-to-day cost decisions.

What changes when you add AI agents to the mix?

The most important shift is that cost expertise stops being bottlenecked on the FinOps practitioner. When every engineer can ask an agent "why did my team's AWS bill go up 18 percent this week?" and get a useful answer in Slack, the FinOps practitioner stops being a help desk and starts being a strategist.

The agent becomes the first responder. It triages anomalies, answers routine cost questions, and generates the weekly showback reports. The human practitioner reviews, approves, and escalates. This is the same pattern that platform engineering teams already use for infrastructure provisioning: the developer asks for a database, the platform provisions it within policy guardrails, and the human only gets involved when something falls outside the guardrails.

The risk is that agents optimize for the metric they can see. An agent that only looks at cost will recommend shutting down the staging environment that the QA team needs for a release next week. An agent that only looks at utilization will recommend buying a three-year Reserved Instance for a workload that is being migrated to a different architecture in six months. The human in the loop is not a temporary crutch. It is the architecture of the system.

Where do you start?

The FinOps Foundation recommends a crawl-walk-run maturity model. Crawl means you can see your spend and allocate at least 50 percent of it to a team or cost center. Walk means you have anomaly detection, budget alerts, and a monthly showback cadence, and you are actively rightsizing and buying commitment discounts. Run means unit economics drive architecture decisions, policies are automated, and the FinOps practice continuously measures and improves itself.

If you are at zero today, start with allocation. Pick one cloud provider. Turn on cost allocation tags. Build one dashboard that shows spend by team. Send it to the engineering managers every Monday. That single action moves you from invisible spend to visible spend, and visible spend is the foundation everything else sits on.

Once you can see the spend, the platform-specific guides go deep on the levers that matter: AWS for EC2 rightsizing and commitment discounts, Snowflake for warehouse tuning and resource monitors, Matillion for pipeline credits and runner economics, GitHub for Actions minutes and agent cost attribution, Postgres for instance sizing and connection pooling, and Power BI for license auditing and Fabric capacity. Each one covers what to measure, what to optimize, and where AI agents fit.

Sources