Ok, I’m going to sound like I’m talking out of both sides of my mouth in this week’s issue, but stick with me.

Tagging. One of the things I hate most about the FinOps domain. Not because it isn’t important, but because as soon as you are done, its outdated. Especially when teams argue about key names and the necessary values for months on end.

But there is value to be found in the exercise of building a proper tagging foundation. And why am I discussing now? Well, because I’m currently writing a tagging standard for a client. We identified the required keys, permitted values, and an enforcement model. It's currently in draft review right now, along with a companion plan for how it gets applied to an already existing infrastructure.

Its a love / hate relationship, but here is why I think its now more critical than ever and I hate it even more.

Tags help create the foundation while ensuring three the success of 3 things.

Firstly, by building the tagging foundation, we are creating a common language the organization can use when discussing the value of a product, tool, service that is using resources. Without it, the Tower of Babel comes to mind. (Remember to communicate and share, otherwise you have just created another language)

Tags tell you what something costs and for whom, with some additional metadata to help filter and sort. That's reporting, and it's where everybody starts and most people stop.

They tell you who to go ask, if done right. That's ownership, and on any given Tuesday it's worth more than reporting. The reason orphaned resources survive for years isn't that nobody found them. It's that nobody signs off on deleting something when they can't tell who's using it. A tag turns an unresolvable risk into a Slack message.

And tags can tell the machines (or be used to determine) what to do. That's actions. Shutdown schedules, retention rules, access conditions, spend caps. This is the half of tagging's value that never shows up in a cost report, which is why it gets left out of the pitch.

Language that leads to reporting, ownership, actions. Gotta love it!

While working with this client, I discovered the following:

Their coverage was fine. The environment tag had roughly a dozen values in the wild that resolve to six real ones, because production showed up as prod, prd, and production, and test and QA meant the same thing while agreeing on nothing. Add case sensitivity, where an uppercase key and a lowercase key are two different tags as far as cost reporting is concerned, and you get a field that looks fully populated and cannot be grouped.

The finance codes were a more interesting data point. The internal order numbers came from a chart of accounts that has since been replaced. One retired value is still sitting on more than a thousand resources. So, nothing is broken and the bill gets paid but those resources are just answering a question finance stopped asking.

Here's the part that matters for the engagement: All of this is fixable. The resources are still sitting there. You can run a sweep, map the old values to the new ones, and recover. It's tedious and it's a real project, but the information was never lost.

Hold onto that.

The three jobs mentioned earlier have completely different tolerances for them to become a stale tag, and almost every standard I've seen holds every key to the same bar.

A stale reporting tag is annoying. Cost lands in the wrong bucket, somebody reallocates next month, life continues.

A stale ownership tag is worse than an empty one. An empty owner field makes you go find out. A wrong one sends you confidently to a person who left in April, and you learn this at the least convenient possible moment. One design decision fixes most of it, and it's in the standard: the owner value is a distribution list, never a person's name or individual email. People leave. Distribution lists get maintained by someone whose job it is.

A stale tag used to take an action causes an outage. If automation stops non-production at 7pm and something production is tagged dev, you no longer have a reporting problem.

Same decay. Three completely different outcomes and impacts

I've spent many of these issues on governance. For example, how there should be a gate that asks cost questions at design time. Or the rail that sits in the request path, because an agent can ignore a policy document but not the path its requests travel through. Or, the tradeoff nobody wrote down. And then two weeks ago, the tagging underneath all of it.

Every one of those controls needs to know which system, which team, which budget. The gate can't ask a question about a thing it can't identify. The rail can't attribute a request with nothing to attribute it to. Cost per unit of anything needs a denominator that resolves to a team, a product, or a customer.

Governance is not a layer you add on top. It's a layer that sits on metadata, and the metadata is the part I don’t like, but is absolutely needed.

Now put AI spend on top of it.

A compute instance has an obvious place to put an owner. It's a durable thing with an identity that persists, and if the tag is wrong you can go back and fix it. A model call has none of that. The unit of AI spend is a request. It exists for a few hundred milliseconds and then it's gone.

Which means the recovery path I described earlier does not exist. You can clean up a bad cloud tag because the resource is still there to be corrected. However, you cannot go back and tag a request that already ran. If the metadata wasn't attached at the moment the call was made, the information doesn't exist anywhere, and no remediation sweep will ever produce it. Cloud tag debt is a cleanup project. AI tag debt is permanent.

Cloud hands you a lot for free: region, account, resource type, often the pipeline that built it. A model call hands you a model name, a token count, and an API key. Everything you actually want to know is declared or it's lost. Which team. Which product. Which customer. Whether this was a two cent lookup or a four hundred dollar agent run that nobody authorized. All declared, all at run time.

Unfortunately, you can't fix that with a document, because the caller is increasingly not a person reading documents. This is the purpose of the rail I discussed in an earlier issue. If metadata has to be attached at the instant of the request, it has to be attached where the requests physically pass, which is the gateway. The key becomes the tag. That's the only version of this that survives contact with an agent.

Four moves, and the first three are ordinary tagging work.

Inherit and don't ask. New resources take tags from the parent at creation. Any standard that depends on a person typing a value correctly has already failed.

Audit before you deny. Rejecting untagged resources is the right end state but the wrong place to start. Run in audit mode, build the baseline, document the exclusions, then enforce. If you lead with deny and you'll spend six months as the person who broke deployments.

Chase cost, not resource count. Target a share of spend, not a share of resources when looking at what to work on. Ten thousand small resources and one large cluster do not deserve equal attention, and a coverage percentage definitely cannot tell them apart.

Now, with AI usage, go look to see how your organization calls models today, and find out what gets attached to those calls, if anything. If the answer is a shared key with no team, no product, and no cap on it, you have already started accumulating a bill you will never be able to allocate. Find a way to fix that before the number gets too big.

One confession to close. The implementation plan I’m writing for the client already changed while I was writing. Decay didn't start after we shipped. It started during the draft.

Tagging is not something you need to believe in, but it is something you should do. Do it in the smallest amount that works, derive what you can, and get it right on the AI side the first time, because that's the one where there is no second pass.

Written with the help of AI. All the ideas expressed are mine and mine alone.

Company: FinOpsly Website; FinOpsly Directory Listing

Category: Software

What They Do: FinOpsly is an AI-native Value-Control platform helping enterprises map cloud, data, and AI spend to business value and automate cost control through agentic AI

Why It Matters: Cost governance is becoming critical in the AI era