Metric Definitions and Business Glossaries for AI Agents

AI agents can't ask a colleague what "revenue" means. A human analyst hears the question, figures out which department is asking, and knows Finance's revenue excludes returns while Sales counts every closed deal the day it closes. An agent has none of that instinct: it grabs the first definition it finds, runs the query, and hands back a number in the same confident tone whether that number is right or completely off.

That gap, between how humans resolve ambiguity and how machines just barrel through it, is what this piece is about. Metric definitions need to work like a contract: precise, machine-readable, enforced before a query ever runs, not patched up after the damage is done.

How widespread semantic ambiguity is stalling AI investments

Ask most executives why their AI initiative stalled and they'll blame the model, but nine times out of ten, that's not it.

Drexel University and Precisely surveyed more than 550 organizations in 2025 and found 62% point to a lack of data governance as the main thing holding back their AI work. Here's the number that stopped me: 67% of organizations say they don't fully trust the data they're using to make decisions, up from 55% just two years earlier. Meanwhile 76% of those same organizations call data-driven decision-making a top strategic goal. Only 12% think their data is actually good enough, and accessible enough, to support AI in production. Sit with that for a second: three quarters of companies say this matters more than almost anything else, and one in eight thinks they're ready for it.

The abandonment numbers back this up. S&P Global's 2025 survey found 42% of companies scrapped most of their AI initiatives that year, up from 17% in 2024. Organizations threw out 46% of their AI proof-of-concepts on average, before anything reached production, almost half gone, and usually not because the model was bad.

Look at how these projects actually get built and it stops being mysterious. Teams start with a prototype, wire a model up to whatever data's lying around, and prove the demo works in a conference room. Ownership, definitions, lineage, quality checks all get pushed to "later." By the time later shows up, the system already depends on datasets nobody documented, resting on definitions nobody bothered to reconcile across teams.

Gartner projects that by 2027, 60% of organizations will fail to get the AI value they expected, and names weak governance frameworks as the reason. The pattern across successful implementations points the same direction: data workflows have to be in order before the model ever enters the picture. Fix the definitions first, in other words, or expect the same story to repeat.

What a human-facing business glossary does, and what it was never built to do

Business glossaries exist for a good reason. They give data teams a shared place to write down what "active customer" means, what counts as "net revenue," how the company defines churn, and maintained well, read regularly, they do their job fine. A human hits an ambiguous term, checks the glossary, asks a follow-up if something's still fuzzy, and moves on with the day.

Most glossaries hold plain-language definitions, some notion of ownership, maybe a few examples or links back to source systems. That's usually where it stops, with no logic an agent could run and no way to tell if two conflicting entries are both technically "current."

What they almost never hold is machine-readable logic: not a sentence describing the calculation, but the actual rule an agent could execute against a warehouse. No domain scoping either, so "revenue" in Finance and "revenue" in Sales sit in the same bucket with nothing to keep them apart. No synonym mapping for the dozen ways someone might phrase the same idea, and nothing that tells an agent whether a definition connects to a schema that's still live.

Glossaries rot too, and this part gets underrated. Redefine "active user" and old dashboards, old slide decks, rarely get updated to match. A person can usually smell a stale doc from context alone, but an agent can't; it finds both versions sitting there, side by side, and treats them as equally true.

Necessary, then, but not sufficient. A glossary solves ambiguity for a reader who can apply judgment. A query engine has none to apply, so the gap has to close somewhere else.

What a machine-readable metric definition must actually contain

Think contract, not documentation. Precise enough that an agent querying "revenue" gets the right number, for the right context, every time, with nobody standing over its shoulder double-checking the work.

Start with the business concept itself: what a "customer" or a "region" actually is, described in terms an agent can reason with, since it has no institutional memory to lean on. Then the metric logic, which is the real engine: the calculation, filters, time grain, window, all spelled out. Something like "net revenue equals gross revenue minus returns, recognized at invoice date, in the currency of the originating transaction," not a paragraph gesturing vaguely at the idea.

Domain scoping decides which version applies where, so Finance's revenue and Sales' revenue are distinguishable the instant the query fires. Synonyms and aliases route "bookings" or "recognized revenue" to the right definition instead of leaving the agent to invent its own interpretation. Relationships and join logic keep a multi-step question from producing a broken join, or worse, a clean one that quietly joins the wrong things.

Lineage tells you which tables and fields a metric actually pulls from, and when someone last checked them. Sensitivity and access scope determine whether a metric gets restricted by role or region, enforced at query time under the real user's identity, not a shared service account's. Freshness metadata is a recency guarantee; a snapshot fine for a monthly dashboard is already stale for an agent making a call in real time.

Version control belongs on this list too, and people underrate it constantly. Definitions change as the business changes, and no version history means a quiet inconsistency creeps in where one agent runs last quarter's rule and another runs this quarter's, with neither one aware there's a conflict.

Define once, use everywhere: that's the whole principle. BI tools, notebooks, and AI agents pull from the same definition store, or inconsistency finds its way back in. It always does, the moment a definition gets duplicated across consumers.

This isn't theoretical. A 522-query enterprise benchmark testing text-to-SQL generation found reliability above 95% when the system grounded its answers in glossaries, semantic layers, and quality metadata, against schema-only setups with none of that grounding. That gap is real, and it isn't small.

Where the semantic layer sits in relation to the glossary

The glossary says what a term means. The semantic layer makes sure that meaning gets enforced the moment a query actually runs.

Picture it sitting between raw data and whatever's consuming it: translating tables and fields into business concepts an agent can act on, keeping metrics and KPIs consistent no matter which tool is asking, handling join logic so nobody's guessing how two tables relate. It routes context-dependent terms, that same "revenue" again, to the right domain-scoped definition automatically, without a human in the loop.

By the end of 2025, most serious data teams had some version of a semantic layer running, mostly built to keep generated SQL consistent and make sure a query used the right metric, but not built with autonomous agents in mind. For agents running in production, that semantic layer needs to sit inside something bigger, a context layer that also carries lineage, governance rules, quality signals, and access policies.

The industry's converging here, which is worth flagging. In September 2025, Snowflake, Salesforce, dbt Labs, BlackRock, and RelationalAI launched the Open Semantic Interchange, an effort to standardize how semantic definitions move between systems. A month later, dbt Labs open-sourced MetricFlow under Apache-2.0, turning it into a portable metric-rendering engine any vendor can build against. OSI uses MetricFlow as its declarative spec: define a metric once, in version-controlled YAML, compile it into dialect-specific SQL for whatever's consuming it. Semantics don't belong to one warehouse anymore; they sit above all of them.

As of 2026, dbt Semantic Layer and AtScale lead on architecture, alongside warehouse-native options like Snowflake's Semantic Views and Databricks' Metric Views. Gartner's 2025 Hype Cycle calls mature semantic infrastructure a prerequisite for agentic AI, full stop, and projects that by 2028, 60% of existing dashboards get replaced by GenAI interfaces sitting on top of exactly this kind of plumbing.

How governance must get wired into the definition layer, not bolted on afterward

The pattern's familiar by now. Prove the tech works first, defer ownership and lineage and access rules to some later phase that keeps sliding, and by the time governance gets real attention, agents are already running on undocumented, ungoverned definitions. Retrofitting it onto a system already in motion is brutal, far worse than building it in on day one.

Permissions have to check at query time, scoped to the actual person the query serves. A service account with broad access is a shortcut wearing a governance costume. An agent running a "revenue" query for a regional sales rep needs to return what that rep can actually see, not what the underlying service account can reach, and access needs to be revocable at the level of a single workload. Tie it to one shared credential instead, and pulling that credential breaks everything downstream at once.

Sensitivity checks can't stop at the individual field either. Two fields harmless on their own can turn into something restricted the moment you join them, and that has to get encoded at the metric level, not left for the agent to figure out.

Audit logs matter more than people give them credit for, especially at the query volume agents generate. A log that just says a query ran, without who triggered it or which definitions it touched, isn't useful. Strip the lineage out and an audit trail is just a pile of strings nobody can act on.

Write actions deserve more scrutiny than reads. An agent that can query a metric definition can often get handed tools to act on it too, and that's an entirely different risk profile that governance has to treat separately.

None of this is abstract. Gartner puts the average cost of bad data at $12.9 million a year per organization, between wasted resources, failed projects, and reputational damage, with productivity losses running as high as 20% and operational costs inflated by up to 30%.

What the platform layer responsible for all of this looks like in practice

The data layer agents query has to get built for AI from the ground up. It can't just inherit whatever standards were "clean enough" for human analysts, because those standards were never meant to survive contact with something that executes on ambiguity instead of noticing it. A dashboard tolerates a little fuzziness fine, but an agent takes that same fuzziness and turns it into an action, and that's a very different kind of failure.

A platform built for this needs a single interface across existing warehouses, SaaS tools, and operational systems, without forcing a migration of infrastructure that already works. Peaka, for instance, federates queries across those sources through connectors rather than moving the data itself. It needs metric definitions, table descriptions, relationships, and domain scoping embedded into every query path, something agents always pass through rather than a lookup they might skip past. Permissions need to be enforced at query time, under the real end user's identity, with every query logged automatically, identity and intent and lineage attached, at a volume most teams badly underestimate.

Structured business questions need structured, governed answers, routed through a queryable data layer rather than a vector database built for semantic retrieval. Different tools, different problems; conflating them is a big part of how teams end up with confident, wrong answers.

Data access, in this model, runs through a live query layer instead of static pipelines built on the assumption that sources and schemas just sit still. A snapshot fine for a weekly dashboard is already out of date for an agent deciding something in the moment.

Data architecture makes up the overwhelming share of implementation effort in agentic systems, well ahead of model tuning. Platforms treating the semantic and governance layer as the main engineering surface, instead of an afterthought, are just reading the room correctly. Informatica's 2026 push around a "trusted data foundation for every AI agent," and Alation's data products marketplace, both point the same direction: the market's converging on this layer as table stakes.

What breaks at each layer when the semantic contract is missing or incomplete

Skip domain scoping and the same term returns different numbers depending on where the query started, no error raised, no flag set anywhere. Nobody notices the agent's wrong, and confidently wrong is worse than obviously wrong.

Skip machine-readable metric logic and agents start writing their own SQL on the fly, guessing at filters and time grains, each one guessing differently. Ask the same question twice, get two different answers, both delivered with total confidence.

Skip lineage and when a source table changes, nothing tells any agent which metrics just broke downstream. The staleness spreads quietly, and usually nobody catches it until a number looks obviously wrong in a board meeting, by which point it's been wrong for weeks.

Skip freshness metadata and an agent making a real-time operational call leans on a snapshot meant for a monthly review instead. The SQL runs clean, but the answer's still wrong, just wrong in a way that looks fine on paper.

Skip query-time permission enforcement and an agent answering a regional user can hand back enterprise-wide data that user was never supposed to see, and nobody catches it until an audit turns it up, usually much later than anyone would like.

Skip a real audit trail, identity and intent attached, and you're left with query strings sitting in a log with zero context, unactionable at the scale agents produce it, governance on paper and nothing more.

Keep definitions maintained separately across consumers, and duplication creeps back on its own, slowly, the way it always does. The same metric drifts apart across BI tools, notebooks, and agents until nobody's quite sure which version is the real one anymore.