AI usage and cost analytics: FinOps for models and agents

Cloud infrastructure cost grew up with tagging, budgets and a FinOps practice. Model spend has arrived without most of that. It is metered in tokens, priced differently by model, and driven by behaviour that nobody on the finance side can see: a prompt that grew, an agent that loops, a workflow that calls a large model where a small one would do.

The result is a familiar pattern. Spend rises, someone notices a bill, and a manual hunt begins for the cause. By then the cause is several weeks old. A better position is one where usage is visible by model, agent and workflow as it happens, limits exist before the bill does, and a deviation reaches the person who can do something about it.

That last step is the one most tools stop short of, and the one the Intelligence Platform is designed to address.

Honesty is part of cost analytics, so here are the gaps we know about. Attribution is by workspace, agent, model and workflow. We do not have a per-team view, and a team is an organisational concept that depends on knowing who is on it. That is exactly what the graph is for, and it is designed for rather than available.

Per-step cost on every worker trace is not yet joined to the trace itself. Natural-language questions about spend, such as why did costs rise in the support workflows last week, are not available. The assistant that turns questions into queries works over datasets and not over usage and cost telemetry.

Detected anomalies are computed on demand and not retained, and alert acknowledgement is available only in the administrative console. We list these here rather than let a design intent read as a feature.

A cost finding has three parts. What changed is the part every tool shows. Who owns it and who can approve a response are the parts that decide how fast anything happens, and those are questions about the organisation.

The graph already resolves people, groups and reporting lines from Active Directory and LDAP, Microsoft Entra ID, Okta and Google Workspace. That is enough to find a group and an approver from a manager chain. Cost-centre and service ownership depend on collectors for cloud and business systems, which are on the roadmap.

From there the design is a FinOps agent. It reads usage for the teams in scope, compares them with the previous period, resolves the owner and the approver, and drafts a report and a proposed cap. It proposes and does not apply. Applying a cap or a routing change requires approval, and every step is recorded: the data it read, the owner it resolved and that fact’s evidence status, the model it used, the proposal, the approver and the result. The worked example below sets it out in full.

We state no savings figure and no benchmark, because we have none we can source here. The named Intelligence Platform dashboards are <named dashboards - founder to fill>. Availability is <availability - founder to fill> and pricing is <pricing - founder to fill>.