AI FinOps, both ways: from agent spend to an IaC change

Inside Cloudgeni's Azure-first cost workflow, what AI agents themselves cost, and how Microsoft and Infracost approach the same problems.

AI FinOps, both ways: understand agent spend and turn cloud evidence into a code change. Light-blue editorial artwork links usage receipts, a cloud and an infrastructure-code proposal.

A database is running at low CPU. There is a cheaper size available. An agent can write the change.

That sounds like an easy saving. It is not enough information to approve it.

Is that number from the bill or a price estimate? Does the database need the current memory or IOPS? Which repository owns it? Will the saving survive the next invoice?

This is where we have been taking Cloudgeni's Cost workspace. Billing evidence connects to the resource and its IaC. You can inspect the candidate, then hand the selected context to the DevOps agent to investigate and prepare a code change. The cost preview itself is read-only. A recommendation does not get permission to resize production.

There is another bill in this workflow: the agent's own work. We run that on Opengeni.

AI FinOps is two different problems. What do agents cost us? And can agents help us reduce cloud spend? Putting them under one label should not hide the difference.

Two distinct FinOps workflows: attribute AI usage and charges before changing the runtime setup; gather cloud billing, usage and IaC ownership before proposing a PR, human review and a later invoice check.
Two workflows, with different evidence and different approval boundaries.

Start with the number you actually have

Cloud cost dashboards often make different kinds of numbers look equally certain. We keep their basis separate.

In Cloudgeni's Cost workspace, the effective monthly amount prefers a complete previous billing period. If that is unavailable, it can use a month-to-date forecast. Next comes a linked IaC estimate. If none is available, the cost stays unknown.

A forecast is not a closed invoice. An estimate is not what the provider charged. Unknown is not zero.

Cloudgeni's effective monthly cost fallback order: complete previous-period invoice actual, month-to-date forecast, linked IaC estimate, then unknown. Utilization remains separate from price evidence.
The fallback order changes the basis of the number, not its certainty.

Utilization is a separate evidence lane. Low CPU can suggest a rightsizing candidate. It does not establish what you paid, and it does not rule out memory, storage or IOPS pressure.

For a PostgreSQL Flexible Server, for example, I would want the observation window, pressure checks, current SKU and proposed SKU in the review. This is an illustrative case, not a customer result or a savings benchmark.

What the released Cloudgeni workflow covers

The Cost workspace brings together spending, coverage, reconciliation and recommendations. Coverage matters before optimization: inventory freshness, billing access, utilization and the IaC match can each be incomplete.

Reconciliation makes a useful distinction. There can be deployed spend with no linked code, and code describing resources that are not deployed. The second is not part of your current provider invoice just because an estimator can price it.

From a recommendation, you can hand selected resource and stack context to the agent. The agent still needs to establish ownership, investigate the proposed change and prepare a PR. If the resource is unmanaged, linking or importing it into the code workflow may be the first job.

The cost-billing integration described here is Azure-first. Do not read Cloudgeni's wider cloud-infrastructure support as billing-feature parity across AWS, Azure and GCP.

The Azure underutilization rules in this release cover eight resource families:

  • PostgreSQL Flexible Server, MySQL Flexible Server and SQL Database
  • Virtual machines and virtual machine scale sets
  • App Service plans, Container Apps and Redis Cache

That is a defined set, not “every Azure resource”. A recommendation may have utilization evidence without a reliable monetary estimate, depending on coverage and the configured cost gate. Kubernetes cost allocation is also distinct from provider invoice actuals.

We described the wider agent-to-PR workflow in our September platform release. The point here is the cost evidence feeding that workflow, not another promise that an agent can find waste.

The PR is a proposal, not the saving

For an IaC-managed resource, a proposed code change keeps the decision in the team's engineering workflow. It can show the reason, validation and estimated cost impact where pricing is supported.

It has not been reviewed just because an agent opened it. And merging it does not prove it was deployed.

The reviewer needs the assumptions behind the estimate, performance risks, a rollback path and a way to check the result. Our Terraform PR evidence guide goes into that review package.

After deployment, compare actual usage and billing against a sensible baseline. Discounts, commitments, workload changes and overlapping recommendations can change the outcome. Do not add two savings estimates for the same resource and call that a result.

We previously wrote about the engineering work between finding waste and fixing it. This is the concrete workflow behind that argument.

Then account for the agent

I wrote earlier that model flexibility matters more than choosing one model forever. The same applies to cost optimization. You need to see what the work costs before deciding to route it differently.

Opengeni provides the runtime behind our agents, with model selection and session cost visibility. But a platform charge, a provider-price estimate and an external provider invoice are not interchangeable.

Bring-your-own-key usage can put the charge on a separate provider bill. Missing usage telemetry cannot become a free call. A reported token cost also does not include every possible cost of sandbox compute or an external service.

So the useful questions are specific: which work consumed the charge, which part was estimated, and what evidence is missing? Then consider a smaller model for suitable work, shorter context, caching or a change to how the job runs. Check quality after the change. Cheapest per token is not necessarily cheapest per completed job.

I am not claiming every upstream invoice can be reconstructed from the runtime, or that a budget setting is a universal hard cap. Controls have to be checked against the funding path and the version actually enabled.

What Microsoft already does

Microsoft has capabilities on both sides. They are not one product with one billing model.

Azure Copilot's Optimization Agent is in preview and currently documents VM and VM scale set recommendations, impact charts, and generated Azure CLI or PowerShell scripts. It is a reasonable fit for teams investigating Azure compute from the portal. Current Azure Copilot pricing says capabilities are included at no extra cost except the separately metered Observability Agent.

That specific Optimization Agent documentation does not establish an IaC PR workflow. It also cannot automatically create or update budgets and alerts. Microsoft's broader agent framework does document actions with approval. Calling Microsoft “only advice” would be misleading.

For AI spend, Foundry documents agent and model cost monitoring, with exclusions and estimate limitations. Project-level chargeback attribution is in preview and covers Models sold by Azure, not every Marketplace model. Azure OpenAI budgets are alerts rather than native hard spending limits.

Separately, Copilot Studio offers per-agent monthly credit limits with a hard stop. Its standard-harness credit rates exclude bring-your-own-model configurations, which are billed separately. Credits are not how all Microsoft model usage is priced.

Infracost already puts cost changes in PRs

This is an important comparison for an IaC team.

Infracost's GitHub App provides pre-merge estimates, cost differences and policy feedback. Its AutoFix workflows can generate remediation PRs for engineers to review and merge. Static validation is not a production-performance guarantee, and required-check protection still needs to be configured.

If your main problem is catching expensive IaC changes before deployment, that is a strong fit. PR-based remediation is not unique to Cloudgeni.

Our comparison is about where the work starts: observed billing and utilization, the resource's connection to code, and an agent investigating a selected candidate. It is not a claim that no one else can generate a PR.

As checked on October 13, Infracost lists AutoFix workflows in its $1,000/month Cloud tier; developer seats are extra. This is a published tier price, not a like-for-like total cost comparison.

For cross-provider AI cost allocation, Vantage's LLM Enrichment is another relevant option. It documents joining request telemetry to provider costs and attributing spend to teams or features. Enablement requires sales contact. That is a different capability from pre-merge IaC estimation, and worth considering when financial attribution is the main gap.

Choose the workflow that matches the missing evidence

If the question is “what will this Terraform PR cost?”, start with pre-merge estimation. If it is “why did our Azure bill grow?”, start with billing and resource evidence. If it is “which agent work is costing us?”, start with the runtime and its funding path.

I am writing about our own product here. Cloudgeni's fit is connecting a cloud-cost candidate to the code and review process needed to act on it. It is not a replacement for every financial reporting tool.

Pick one candidate. Establish what its cost number means. Check who owns the code. Review the proposed change. Then check what happened to the bill.

The recommendation is where the work starts.


Scope checked October 13, 2026. Microsoft Optimization Agent documentation: August 10, 2026; Foundry cost documentation: August 27, 2026, with September metadata updates; Copilot Studio capacity controls: October 2, 2026. Infracost and Vantage pages above were checked on October 13 and do not provide publication dates. Product documentation establishes published scope, not a customer savings benchmark.