A Fresh Metric Can Still Be Wrong for the Question an AI Agent Is Answering

Semantic context in AI data pipelines matters because a current metric value does not tell an agent what the metric means. The calculation, grain, time basis, exclusions and dimensions that produced the number can determine whether the answer is useful or quietly wrong.

An executive asks an internal agent:

How is revenue tracking this month?

The warehouse was refreshed five minutes ago.

The agent retrieves the latest revenue metric and reports that performance is ahead of plan.

Finance disagrees.

The problem is not stale data.

The agent found a current number. It did not know that this version of revenue included tax, used booking date rather than recognition date and had not applied the adjustments used in the finance view.

Every value it retrieved was valid.

The interpretation was not.

Data freshness does not establish metric meaning

Data teams have spent years making freshness observable.

Pipelines expose delayed jobs.

Tables carry update timestamps.

Streaming systems reduce latency between operational events and downstream consumers.

Those controls answer an important question:

How old is this data?

An agent often needs a different answer before it can use the data safely:

What exactly does this number represent?

Those questions are independent.

A metric can be seconds old and still be inappropriate for the question being asked.

“Revenue” may mean booked revenue, recognised revenue, invoiced revenue, gross revenue or net revenue.

“Active customer” may mean a customer with an open contract, a login within a defined period, a completed transaction or recurring revenue above a threshold.

“Conversion rate” is meaningless until the numerator and denominator are understood.

Freshness tells the agent when the value was produced.

It does not supply the business definition.

A metric is more than a number and a name

Snowflake’s semantic-view documentation makes this separation explicit.

A semantic view can define metrics as aggregated measures of business performance while dimensions provide the contextual framework for analysing those metrics. It also captures relationships between business entities and the formulas used to calculate metrics.

That architecture points to a broader issue for agents.

Sending an agent:

renewal_rate = 91.4%

is not the same as giving it enough information to interpret renewal rate.

The value may also depend on:

• which contracts are eligible;
• whether the metric is customer-based or revenue-weighted;
• the period over which renewal is measured;
• treatment of grace periods;
• exclusions for cancellations or migrations;
• dimensions across which the metric may safely be compared.

Those details are not decorative metadata.

They determine what conclusions the number can support.

The same metric can answer one question correctly and another incorrectly

Suppose an agent receives a valid account-balance metric measured at the end of each month.

A manager asks:

What was our total account balance across the last six months?

The agent retrieves six correct monthly snapshots and adds them together.

Every balance is valid.

The total is not.

A point-in-time balance can be aggregated across accounts at a particular date, but adding repeated snapshots of the same balances across time counts the same underlying amount again and again.

Snowflake’s semantic-view specification explicitly supports identifying dimensions across which a metric should be treated as non-additive, and its query rules impose granularity constraints when facts and dimensions are combined. 

The practical implication is larger than a SQL rule.

An agent needs to know not only what a metric is, but also how it may be sliced, aggregated and compared.

A perfectly correct metric can become a misleading answer when the agent applies it across a dimension over which the metric is not additive.

Metric retrieval needs an interpretation envelope

A useful data pipeline for agents should not treat a metric value as a self-contained payload.

The value needs enough surrounding semantics for the consuming system to understand its permitted interpretation.

Call that a metric interpretation envelope.

For a business-critical metric, that envelope may include:

definition — what the metric represents;

calculation — how it is derived;

grain — the level at which it is valid;

time basis — event date, booking date, recognition date or another clock;

dimensions — how the metric may be grouped or filtered;

exclusions — records deliberately omitted from the calculation;

units — currency, percentage, count, duration or another measurement;

synonyms — the business language users may use when referring to it.

The agent does not need to display all of this every time.

It needs enough of it available when deciding which metric answers the question.

Natural-language access makes missing semantics easier to hide

A dashboard often exposes some of its interpretation through structure.

The user sees the chart title.

Filters are visible.

Units appear on the axis.

The surrounding report may make the reporting period obvious.

An agent can remove many of those cues.

A user asks a sentence.

The system resolves that sentence to data.

A fluent answer comes back.

The missing semantic step can disappear inside the interaction.

That is one reason current analytics platforms increasingly expose business metadata directly to AI systems.

Snowflake says Cortex Analyst uses semantic views to understand business concepts, metrics and relationships, with descriptions, synonyms, data types, calculation rules and verified query examples helping improve query accuracy.

Databricks likewise documents agent metadata in metric views—such as display names, formats and synonyms—as business context that helps natural-language tools such as Genie Agents interpret metrics more effectively.

The important shift is not that every enterprise now needs one particular semantic-layer product.

It is that natural-language access makes semantic completeness part of runtime reliability.

A successful query can still produce an unsuccessful answer

Traditional pipeline monitoring may see nothing wrong.

The source system is available.

The transformation completed.

The table is fresh.

The query ran successfully.

The metric returned a value.

The agent responded.

Every technical checkpoint is green.

Yet the answer may still be wrong for the business question because the agent selected the wrong definition, applied an invalid dimension or misunderstood the time basis.

That failure will not appear as pipeline latency.

It may not appear as a model error.

It may not even look obviously incorrect to the person reading the response.

This is why semantic quality deserves its own place beside freshness, completeness and schema validity.

The pipeline delivered the data.

It failed to deliver enough meaning.

The agent should be able to detect semantic uncertainty

An agent does not always need more context.

Sometimes it needs to recognise that the available context is insufficient.

If the user asks for “revenue” and several governed revenue metrics exist, choosing one silently is not necessarily the best behaviour.

The agent may need to ask:

Do you mean booked revenue or recognised revenue?

If a metric cannot be safely grouped by the dimension requested, it should not invent the comparison.

If the business definition is missing or ambiguous, the system should be able to treat that as unresolved data context rather than proceeding because a numerical value exists.

That creates a useful distinction between data availability and semantic readiness.

The metric may be available.

The agent may still not be ready to use it.

Semantic quality has to travel with the data

This does not mean every query needs a long dictionary attached to it.

It means the machine-readable path to a business metric should preserve enough context for an agent to determine what the metric means and where its interpretation stops being valid.

That is a narrower requirement than building an enterprise semantic layer.

It begins at the consumption boundary.

When an agent receives a metric, does it also receive the information required to know whether that metric actually answers the question?

Freshness can tell the agent that the number changed five minutes ago.

It cannot tell the agent whether it chose the right number in the first place.

The useful question is:

If two fresh metrics share the same business name, what tells the agent which meaning the user intended?