Tags Are Not Unit Economics: Designing Cost Attribution for AI Workloads
Cloud cost management usually starts with resource metadata. Teams add tags for applications, environments, owners, projects, and cost centers, then use those dimensions to understand where infrastructure spending is going. This is a necessary foundation, but it is easy to mistake it for a complete cost-attribution system.
A tag can tell you that a resource belongs to support-agent or customer-platform. It does not necessarily tell you how much that resource contributed to a particular workflow, tenant, transaction, or successful operation. That distinction becomes much more important when the workload is an AI system.
An AI feature rarely consists of a single resource. A production workflow may involve model inference, application compute, retrieval, databases, object storage, network traffic, queues, external tools, and observability systems. Some of these resources may be dedicated to the application, while others are shared across many workloads. The result is a simple problem with a difficult implementation: Knowing who owns a resource is not the same as knowing what a unit of work actually costs.
What tags can tell you?
Tags are still one of the most useful mechanisms for organizing cloud costs. AWS cost allocation tags can be used to categorize resource costs around dimensions such as application, owner, and cost center. Azure similarly describes tags as business context that can be used to group and allocate costs.
For example, an organization might tag resources with:
application = support-agent
environment = production
team = customer-platform
cost-center = CC42
That metadata can make a large cloud bill considerably easier to understand. Instead of looking at infrastructure as one large pool of spending, the organization can group costs by application, team, environment, or other dimensions that matter to its internal reporting.
The problem appears when the application consumes resources that are not exclusively owned by it. A support agent might run inside a shared Kubernetes cluster. Several applications could use the same database. A centralized observability platform could ingest telemetry from hundreds of services. A model-serving system could handle requests from multiple products.
The resources can be tagged correctly and the organization can still lack a reliable answer to the question:
How much of this shared infrastructure did the support-agent workload consume?
That is where cost allocation ends and workload attribution begins.
AI workloads make attribution harder
The execution path of an AI workload can vary significantly between requests. A simple request might call a model once and return a response. A more complex request could retrieve documents, invoke several tools, make multiple model calls, perform database operations, retry a failed operation, and then persist the result.
From an API perspective, both may still appear as one request.
From an infrastructure perspective, they are very different workloads.
Consider an agent that processes a support case. One execution may require a single model call, while another may need retrieval, CRM access, additional reasoning, and a second model invocation. If the organization calculates only total AI spend / API requests, the resulting metric treats those executions as equivalent even though their resource consumption is not.
This is why AI cost attribution needs application context in addition to infrastructure metadata. The billing system can tell you what was charged. The application can tell you what happened. The attribution problem is connecting those two views.
The unit of work matters more than the dashboard
Before creating a cost-per-unit metric, the organization needs to decide what the unit actually represents. For some systems, a request may be an appropriate denominator. For others, it could be a processed document, completed transaction, resolved support case, or successfully completed agent workflow.
Consider a document-processing platform. If the system spends more money because it processes twice as many documents, an increase in total cost is not necessarily a sign of worsening efficiency. A more useful metric could be the cost per successfully processed document.
The same principle applies to AI agents. If the application is designed to complete workflows rather than simply generate responses, measuring cost per successful workflow can provide more useful information than measuring cost per model request.
This is the core idea behind unit economics: technology spending becomes more meaningful when it can be related to a meaningful unit of activity or output. The denominator therefore should not be chosen because it is the easiest field to collect. It should represent the work the system is actually expected to perform.
Shared infrastructure requires an explicit allocation model
Shared infrastructure is where many cost models become unreliable. Imagine a platform team operates a cluster used by ten engineering teams. The cluster generates a monthly infrastructure cost, but no single application owns all of that capacity. Assigning the entire cost to the platform team may be accurate from an ownership perspective but misleading from a consumption perspective.
The alternative is to define an allocation method. AWS Cost Categories, for example, support rules for grouping and splitting costs, including proportional, fixed, and even allocation methods. Azure provides cost-allocation rules that can distribute shared-service costs across subscriptions, resource groups, or tags.
These mechanisms solve an important organizational problem: shared infrastructure can be represented against the teams or groups that consume it instead of remaining entirely with the team that operates it. But allocation rules are still estimates unless they are based on meaningful consumption data.
An even split might be reasonable for a stable shared service where consumption is relatively balanced. It becomes difficult to defend when one workload generates substantially more traffic, compute, storage, or model usage than the others. A proportional allocation based on measured usage may better reflect reality, but it requires the platform to expose the right measurements. That is why cost attribution is partly a telemetry problem.
Runtime telemetry fills the gap
Suppose the cloud billing data contains the cost of a shared compute platform. That data can tell you how much the platform cost during a billing period, but it does not necessarily tell you how much of that cost should be attributed to an individual workflow.
Runtime telemetry can provide another part of the picture. An AI application might record information such as workflow identifiers, tenant identifiers, model usage, tool invocations, execution duration, retry counts, and completion status. The exact fields depend on the workload, but the objective is to preserve enough context to connect an application operation with the resources it consumes.
For example, a workflow might produce an identifier such as:
workflow_id = wf_82741
tenant_id = tenant_19
model = reasoning-model
tool_calls = 3
status = completed
The billing system may separately contain infrastructure and service usage records for the same period. A cost-attribution layer can then combine those datasets according to the architecture and available usage signals.
The important point is that the application does not need to become a billing system. It needs to expose enough operational context for the organization to understand how resources are being consumed.
Model cost is only one part of workload cost
AI cost discussions often focus heavily on model pricing because model inference is visible and easy to measure. Production workloads can have a much broader cost footprint. A workflow may invoke a model, retrieve information from a database, execute a tool, write data, send network traffic, generate logs and traces, and consume compute while the orchestration layer is running.
Reducing model calls can therefore lower one component of the workload while increasing another. For example, an optimization might move more processing into application compute to reduce inference usage. Another might introduce a cache that lowers model calls but increases storage and cache infrastructure. A retrieval optimization might reduce context sent to the model while increasing database work. If the organization measures only model spend, it can optimize the wrong layer.
The useful metric is the cost of the workload as a whole, with the allocation method making clear which costs are directly attributable and which are shared.
Cost attribution should expose architectural behavior
This is where cost data becomes particularly useful to engineers. Suppose the cost per successful workflow increases over several weeks. The next question should not simply be which cloud service became more expensive.
The engineering team should be able to investigate what changed in the execution path.
Perhaps the workflow started making additional model calls. Perhaps retries increased. Perhaps retrieval began returning larger datasets. Perhaps a new tool was introduced. Perhaps workload volume changed while the number of successful outcomes did not increase proportionally.
Without workload-level attribution, these changes can appear as unrelated movements across different billing reports. With attribution, they can be investigated as part of the same system.
For example, imagine a workflow that originally required one model call and one retrieval operation. A later version introduces a second model call for validation and three additional database queries.
The cloud bill may simply show higher model and database usage. A workload-aware cost model can show that the cost of completing one successful workflow increased because the execution path became more expensive. That is a much more useful signal for an engineering team deciding whether the architectural change is justified.
Start with the decision you need the metric to support
The mistake is often starting with the dashboard instead of the question. If the organization wants to know which team owns a resource, resource metadata and account structure may be sufficient.
If it wants to understand which workloads consume a shared platform, it needs usage information in addition to ownership metadata.
If it wants to know the cost of completing a business or operational workflow, it also needs application-level outcome data.
Those are different levels of attribution, and trying to force them into one tagging strategy usually produces a complicated metadata system without producing better answers.
A practical design starts by defining the decision.
For example:
Why did the cost of this AI workflow increase?
That question may require model usage, tool calls, retry behavior, compute consumption, and workflow volume.
Another question might be:
Which tenant is driving the highest workload cost?
That requires tenant-level correlation.
A third might be:
What does it cost to successfully complete one workflow?
That requires a reliable definition of completion in addition to cost and consumption data.
The telemetry should follow those questions.
A practical cost model
Consider a multi-tenant AI support application. The organization already has cloud billing data and resource tags. The application records workflow and tenant information, along with model usage and completion status.
Instead of stopping at:
monthly cloud cost
the organization can build toward:
total attributable workload cost
successful workflows
The numerator can include directly attributable infrastructure and service costs together with an explicit allocation of relevant shared infrastructure. The denominator represents completed workflows rather than raw API requests.
The result is not necessarily a perfect accounting number. It is a decision-making metric whose quality depends on the quality of the underlying allocation and workload data. That distinction matters. A cost-per-workflow metric should not create false precision. If shared database costs are allocated using an approximate rule, the metric should be understood as an allocation model rather than an exact measurement of every individual workflow.
The goal is consistency and usefulness, not mathematical certainty where the underlying data cannot support it.
What a production-ready model should preserve
A useful AI cost model should allow an engineer or FinOps practitioner to move from an infrastructure charge back to the workload responsible for the consumption. That does not mean every cloud charge must be attributed to a single request. Some costs are naturally direct. Others are shared. Some may be too difficult to allocate accurately and should remain in a shared pool until better consumption data exists.
The important thing is that those decisions are explicit.
A mature model can therefore distinguish between:
directly attributable workload costs,
usage-based shared costs,
fixed platform costs,
and costs that currently cannot be allocated with sufficient confidence.
That is more useful than pretending that every dollar can be traced perfectly. It also gives engineering teams a clear path for improving the model. If an important shared service currently cannot be attributed, the next step may be better telemetry rather than another round of tagging.
Tags are the beginning, not the unit economics
Tags remain essential because organizations need a consistent way to understand ownership, application boundaries, environments, and cost centers. AWS and Azure both provide increasingly capable cost-allocation mechanisms around resource metadata, account structures, cost categories, and shared-cost rules. But an AI workload cannot be understood financially through infrastructure metadata alone.
A production cost model needs to connect three different questions:
Who owns the infrastructure?
How is the workload consuming it?
What useful work is that consumption producing?
Tags are good at answering the first question.
Runtime and application telemetry help answer the second. Unit economics addresses the third. That distinction is important because the objective of FinOps is not simply to make the cloud bill easier to categorize. For engineering teams, the more valuable outcome is being able to connect infrastructure decisions with the behavior and economics of the systems they operate.
Tags tell you who owns the resource. Cost attribution tells you who consumed it. Unit economics tells you what that consumption costs per meaningful unit of work.
Top comments (0)