Metric definitions for AI database agents: stop making the model guess what revenue means
The fastest way to get a wrong answer from an AI database agent is to ask a simple business question.
“What was revenue last month?”
That sounds easy. The database has invoices, subscriptions, payments, refunds, credits, discounts, taxes, trials, failed charges, and test accounts. The model sees tables. Your business sees definitions.
If those definitions are not part of the system, the model has to guess.
Table names are not metric definitions
Most natural-language SQL demos assume the schema is self-explanatory. It rarely is.
A table called payments may include failed attempts. subscriptions may include trials. amount may be gross, net, pre-tax, post-tax, or stored in cents. created_at may mean invoice creation, payment capture, or customer signup.
The model can write valid SQL against all of that and still answer the wrong question.
Related: Schema context for AI database agents.
Start with the metrics people actually ask for
Do not try to document the entire database first. Start with recurring reporting questions:
- MRR and ARR,
- active customers,
- trial conversion,
- churned accounts,
- usage by workspace,
- failed syncs,
- open support risk.
For each metric, define the approved source, filters, time zone, exclusions, grouping rules, and freshness expectation.
If the metric is important enough for a leadership meeting, it is important enough to define before an agent calculates it.
Approved views beat clever prompts
A prompt can tell the model how to calculate revenue. An approved view makes the definition executable.
For example, instead of exposing raw invoice and payment tables, a team might expose reporting.monthly_recurring_revenue with columns such as:
account_id,month,mrr_cents,plan,currency,is_test_account.
The model still helps users ask flexible questions. But the business definition lives in infrastructure, not in a fragile instruction.
Related: Tenant scoping for AI database agents.
Metric context should travel with the tool
An MCP database server should not only expose “run query.” It should expose the meaning and limits of the data it makes available.
Useful context includes:
- plain-language metric descriptions,
- allowed dimensions,
- time grain and time zone,
- known exclusions,
- freshness timestamp,
- whether the metric is exact, estimated, or sampled,
- links to related approved views.
That context helps the model choose the right data and explain caveats instead of hiding them.
Related: Tool result contracts for AI database agents.
Audit the definition, not just the query
When someone challenges an AI-generated answer, the audit trail should show more than the SQL text.
It should show which metric definition was used, which version of the view was queried, what scope applied, how many rows came back, and whether the result was truncated or stale.
Otherwise every disagreement turns into a forensic exercise.
The goal is not to make the model sound more confident. The goal is to make the answer reviewable.
Where Conexor fits
Conexor is MCP infrastructure for AI-ready engineering teams. It helps connect databases and APIs to AI clients like Claude, ChatGPT, Cursor, n8n, Continue, and any MCP-compatible client.
For natural-language SQL, the useful boundary is not “can the model query the database?” It is “can the system give the model the right business definitions, scope, and evidence?”