A five-field telemetry schema, decided before the first workflow ships, serves finance, compliance, and quality at once. It is the cheapest architectural decision an AI program will make and the most expensive to retrofit.
There is a question I ask on the first day of every engagement, and the answer tells me most of what I need to know about the next six months. What did the last thousand units of work cost, and for any one of them, why did the system say what it said. In a mature program the answer is a query. In most programs it is a research project, and the reason is not tooling. It is that nobody decided, before the first workflow shipped, what every model call should carry with it. The decision fits on an index card. Skipping it is the cheapest default an AI program can take and, in my experience, the most expensive one to undo.
Every model call leaving the organization should carry five fields: the tenant it served, the workflow it belonged to, the step within that workflow, the unit of work it was part of, and the model plus the prompt version that produced the output. Unit of work ties the call to a ticket, a claim, a document, the thing the business counts. Model and prompt version say which pair of weights and instructions was in force.
These are dimensions, not measures. The gateway already records what each call consumed, how long it took, and what went in and came out. The five tags are what make those records attributable to something the business recognizes.
The temptation is to add more. I resist it, and the reason is adoption rather than purity. Fifteen required fields is a schema few teams fill in correctly, and a schema filled in badly is worse than none, because it produces confident reports from dirty data. Five fields survive a platform team’s objections and answer most of the questions I have seen asked with money or liability attached. The five are load-bearing. Everything else rides along as optional context.
The step tag is the one most teams I have worked with skip, and the one the economics turn on. A workflow total says the program is expensive. A step breakdown says which disposition to change.
The reason to decide this once, centrally, is that three groups who do not normally share tooling all need the same five fields.
Finance gets cost per outcome as a query. Sum consumption times price, group by workflow, divide by distinct units of work, and cost per resolved ticket appears. In my work leading enterprise AI delivery, the absence of that query is the most common reason I have seen a program that engineering considered a success get frozen. The bill was visible. The cost was not.
Compliance gets a decision path it can reconstruct. Unit of work plus step plus prompt version, joined to the stored request and response, recovers what the system was asked, under which instructions, by which model, in what order. When someone affected by an output asks why, the answer comes from the record, not from a guess about which prompt was live that week.
Quality gets drift by step and by version. Model behavior shifts with upgrades, prompt revisions, and the shape of incoming data, and those shifts rarely trip a traditional alert. With step and version on every call, a change in output length or refusal rate can be pinned to where it started. Without them, the only signal is a complaint.
Traditional monitoring trained most teams to watch an average and alert on a threshold, and both habits fail here. Per-run consumption in agentic systems is right-skewed. Loops, retries, long contexts, and tool chains push individual runs far above the typical one, and nothing pulls them below by the same amount. An average hides the tail that is spending the money. The operating view is P50 and P90 per step, watched over time, and the gap between them is the loop guard and prompt hygiene backlog, already ranked.
This is where the forecasting band earns its keep. In the two-number business case I use 0.75x on the low side and 1.6x on the high side as placeholders until telemetry provides the real P10 and P90. Those placeholders are priors, and I would rather replace them than defend them. With step and unit of work on every call, the band becomes empirical within a month of production traffic. Without those tags it stays a guess, and the finance review proceeds on the guess.
Where the tags are enforced decides whether they exist. Asked to add them in application code, teams will comply slightly differently, a few will forget, and the reporting layer will spend its life reconciling shapes. The enforcement point is the one place every call can be made to pass through: the gateway that holds the provider credentials. If no such gateway exists yet, building one comes before the tags, and the case for it is in One paved road, many workflows.
In production, an untagged call fails closed. The gateway rejects it before it reaches a provider, the same way it would reject a call without credentials. In lower environments it passes with a warning, so experimentation is not taxed. Cloud cost management learned this slowly: untagged resources were a large share of the attribution problem, after-the-fact tagging campaigns rarely closed the gap, and policies that refused to provision an untagged resource mostly did. The gateway is the provisioning step for a model call.
This is the whole specification I would hand a platform team. It is short on purpose.
Tenant. The business unit, customer, or cost center the call served. It is drawn from the identity already attached to the request, never typed by hand.
Workflow. A stable identifier for the business process, from a registry the platform team owns. New workflows register before they ship.
Step. The position within the workflow, using the same step names the business case used to estimate hours. If the forecast and the telemetry disagree on step names, the measurement cannot replace the assumption without a mapping table nobody will maintain.
Unit of work. The identifier of the ticket, claim, document, or case this call helped complete. Every call in a unit shares it, and sub-tasks carry a parent reference.
Model and prompt version. The model identifier as the provider reports it, pinned to a dated version where the provider offers one, since an alias can change underneath a workflow without anyone deciding it should. Alongside it, a version hash of the prompt template actually sent. They travel together because an output is a product of the pair.
Enforcement. Required in production at the gateway. A missing or malformed tag rejects the call. Lower environments warn.
Retention. Long enough to answer a regulator, decided with compliance before the first workflow ships, not after the first request arrives.
The five fields are a prior from workflows shaped like pipelines: a unit enters, passes through named steps, and exits resolved. Not everything looks like that. Multi-agent systems where one unit spawns many sub-units stretch the unit-of-work field, and I have not settled on how deep the parent tree should go before cost roll-up stops meaning anything. Conversational products have no natural unit of work, and a session is a weak substitute. Prompts assembled from retrieved fragments do not have a version in the ordinary sense. Each of these is open in my practice, not solved. The schema still holds. The definitions of two of its fields get harder.
Every program I have seen without these tags had a plan to add them later. The plan is sincere. It rarely happens. By the time attribution becomes urgent there are several workflows in production, each with its own logging shape, built by teams that have since moved on. The retrofit is a project. The original decision was a paragraph.
Five fields, decided once and enforced at one choke point, turn a program that can be billed into a program that can be explained. Tagged, a model call is evidence. Untagged, it is an invoice.
Related: The unit economics problem in enterprise AI and Silent failures.
