Your AI Coworker Can Query Revenue. Does It Know What Revenue Means?

A Correct Query Can Still Give the Wrong Business Answer

On October 6, GoodData announced an Agentic Serving Plane built to supply AI systems with business definitions, permissions, and context alongside data. The interesting problem is not that a machine might struggle to retrieve a number. It is that two perfectly executed queries can return different numbers called “revenue,” and an AI coworker may confidently act on either one.

Imagine a shop owner asking, “Did revenue drop last month?” The payment processor shows money collected, including tax and shipping. The bookkeeping system recognizes sales after refunds. The sales system counts deals marked won, including work not yet delivered. None of those figures is necessarily defective. They answer different questions.

A person in the business might know which number belongs in a cash-flow discussion and which belongs in a sales meeting. A Teammate joining those conversations needs that distinction made explicit. More access to raw tables does not supply it. A larger model does not turn ambiguous accounting terms into company policy. The business has to decide what the metric means, where it comes from, and which decisions it can support.

GoodData's announcement is a vendor statement about its own product, not independent evidence that every implementation works as promised. Its diagnosis is useful nonetheless: software that asks one follow-up question after another needs governed definitions and workload controls, not simply another connector. The same operating problem applies to a ten-person company even when its “data platform” is a point-of-sale export and a spreadsheet.

The Semantic Layer Is a Business Agreement, Not Just a Data Product

A semantic layer is the set of agreed definitions that sits between stored data and the people or systems asking questions of it. It tells a consumer what “active customer” means, which timestamp determines a reporting month, how refunds affect revenue, and which segments can be compared. In a sophisticated stack those definitions may be implemented as reusable metrics, relationships, and permissions. In a small business, the first useful version might be a reviewed metric register and a handful of controlled reports.

The distinction matters because an AI coworker can make a semantic error while remaining technically accurate. It can read the correct API, add up the returned values without arithmetic mistakes, and still recommend a bad decision because it used the wrong definition of “margin.” That is not primarily a hallucination. It is an unresolved business rule disguised as a data-access problem.

dbt's Semantic Layer documentation describes centrally defined metrics that downstream applications can query instead of recreating their own calculations. Its metric documentation distinguishes simple aggregations from ratios and derived measures, and spells out filters and time dimensions. You do not have to adopt dbt to learn from that design. The reusable unit is not merely a query: it is a named definition with a calculation, scope, and owner.

A metric card beats an undocumented dashboard tile

For each metric an AI coworker will use, write down six things: its business purpose, its formula, its source of record, its time basis, its exclusions, and its human owner. Add a seventh field for the permitted action: may the Teammate summarize it, raise an alert, prepare a recommendation, or change another system because of it?

Consider “monthly recurring revenue.” Does an annual contract contribute one-twelfth of its value each month? Do paused accounts count? When does a cancellation take effect? Does the number include taxes, usage charges, or discounts? A spreadsheet cell labeled MRR cannot answer any of these. Neither can a prompt telling the Teammate to “use common sense.”

A metric card also needs a version and an effective date. If the finance lead changes the treatment of paused subscriptions on October 1, the September comparison should not silently use the new rule on one side and the old rule on the other. Preserve the prior definition or recompute both periods consistently; otherwise a policy change will look like customer movement.

Meaning, permission, and freshness are different controls

A correct definition is only one boundary. A customer-success Teammate might be allowed to view aggregate overdue invoices but not line-item payment details. A sales Teammate might use yesterday's pipeline figure to prepare a morning brief but should not cite it as a live cash position. Access to the right metric does not authorize every downstream use of it.

GoodData says its new layer is designed to apply business definitions and access policy on each request and isolate intensive machine workloads from other queries. Those are claims about a particular implementation, not prerequisites for every small company. The transferable idea is to check what the number means, whether this role may see it, and whether it is recent enough for this decision as separate questions. One green access light does not answer all three.

What Happens When Two AI Coworkers Disagree About the Same Number

Suppose a small service company has a sales Teammate and an operations Teammate. On Monday, sales reports $82,000 in “new revenue” based on signed agreements. Operations reports $61,000 based on jobs completed and invoiced. The figures are illustrative, not a company case study. They could both be accurate within their own definitions.

What bad looks like: Leadership sees the first number in a growth summary and the second in a staffing recommendation. An owner asks why performance collapsed overnight. The Teammates exchange messages, each repeats its source's number, and one invents an explanation for the gap. Then a staffing plan is changed on the basis of a reconciliation nobody actually performed. The problem is not that the Teammates failed to communicate; it is that “new revenue” was never a single shared measure.

What good looks like: The business keeps two named metrics: signed_contract_value, dated by signature, and recognized_service_revenue, dated by completion under the company's accounting policy. Both specify source, exclusions, refresh frequency, and owner. The sales Teammate can report the first as a leading indicator. The operations Teammate uses the second to assess delivered work. When the owner asks about the gap, the Teammates present the two definitions and a reconciliation request, not a made-up causal story. A human decides whether the gap reflects delivery timing, cancellations, or an error.

That is a seam design problem. The machine can assemble the evidence and identify disagreement. A person who owns the business definition must settle which interpretation governs the decision. After that decision, the definition belongs in the shared operating layer rather than buried in one conversation. Next month's Teammates should not have to rediscover it.

The same pattern appears in customer counts. Marketing might count unique leads, sales might count qualified accounts, and support might count active paying organizations. If all three call their figure “customers,” an AI coworker asked for retention can produce a polished answer on the wrong denominator. Rename and define the measures before debating the model's reasoning ability.

There is also a workload issue. GoodData points out that one investigation may generate many short-lived queries as a system narrows down the cause of a change. A small company may not need high-concurrency architecture, but it still needs a budget: a Teammate should not hammer a billing API every minute to answer an open-ended question. Cache appropriate non-sensitive aggregates, set query limits, and show the data timestamp in the answer. Governance includes the cost and reliability of asking, not only the correctness of the response.

Build a Minimum Viable Metric Contract in One Week

Do not begin by cataloging every column in every business system. Start with the decisions already being made from AI-generated summaries. Choose one high-value workflow, such as weekly cash review, renewal follow-up, or staffing capacity, and make its inputs explicit.

1. Choose one decision and name its human owner. “Review capacity for next week's jobs” is narrower than “make our company data AI-ready.” The owner must be able to decide what an exception means and when a recommendation is safe to use.

2. List the three to five metrics the decision actually uses. Write the exact question each answers. For capacity, that might include confirmed work, estimated hours, available staff hours, and overdue work. Avoid an all-purpose “business health” score nobody can audit.

3. Write a metric card for each one. Include formula, source of record, time zone, reporting interval, exclusions, refresh schedule, and version. Work through edge cases with the owner: canceled jobs, deposits, refunds, duplicate contacts, partial weeks, and late-entered records. If two people disagree, record the disagreement rather than letting a Teammate improvise a settlement.

4. Expose a controlled view rather than every raw record. Start read-only. Give the Teammate a report or query surface that implements the approved definitions and only the fields its role needs. This puts role-based AI governance into practice: prove the evidence path before granting operational authority.

5. Reconcile against a human-approved baseline. Ask the Teammate to answer a fixed set of questions for a closed historical period. Compare each result to the approved report, inspect disagreements, and document whether the cause was data freshness, join logic, metric definition, or model interpretation. A “looks plausible” check is not a reconciliation.

6. Define the stop rule. If a source is stale, a metric is undefined, or two approved views disagree beyond an agreed threshold, the Teammate should present the ambiguity and ask its owner. Do not let it silently select a convenient figure. An approval request should carry source, timestamp, metric version, and the proposed decision. Those operating-layer decision boundaries should persist beyond one chat.

7. Review definition changes like workflow changes. Keep a record of who changed a metric, why, and when. Re-run the baseline questions after the change. If a downstream alert relies on the old definition, update its threshold deliberately rather than treating a new number as an ordinary trend.

This is intent engineering in concrete form. The company is not merely telling an AI coworker where to find data. It is encoding which interpretation serves the business objective, which uncertainties require escalation, and which actions are out of scope. A shared definition lets different Teammates operate from the same facts while retaining different roles.

The sequence also separates an analytics task from an authority grant. A Teammate that detects a potential revenue decline may prepare a diagnosis and cite the definition used. It should not automatically cut staffing, change pricing, or contact customers because a metric crossed a line. Those choices have additional human and operational consequences. The financial-data boundary applies the same principle in a finance setting: prepare evidence and surface anomalies, then reserve consequential ledger decisions for an accountable reviewer.

A Better Answer Shows Its Definition and Its Limits

The best answer to “How is revenue doing?” is not a single impressive number. It names the measure, period, data timestamp, relevant comparison, and any known exclusions. It can say: “Recognized service revenue for September, excluding tax and refunded work, was lower than August on the approved report; I cannot infer whether demand fell until we reconcile signed work and completed jobs.” That is useful because a manager can act on what is known without mistaking a hypothesis for a fact.

An AI coworker is different from an on-demand AI tool here. The coworker returns next week, watches for changes, and may hand work to another Teammate. Persistent work makes a wrong definition compound: an inaccurate alert becomes a false priority, then a changed schedule, then a customer message. Persistence also makes the remedy practical. Definitions, corrections, and escalation rules can be maintained as durable operating context instead of retyped in every chat.

The October 6 GoodData launch is one more sign that business semantics are moving from a dashboard concern to an execution concern. An enterprise might buy a serving plane. A small business may start with a metric card and controlled report. The scale differs; the obligation does not. Before asking a Teammate to decide what a number implies, decide what the number is.

FAQ

Q: What is a semantic layer for AI coworkers?

A: It is a shared set of business definitions and relationships that tells an AI coworker how to interpret approved data. It can be implemented in dedicated software or begin as documented, controlled metrics. It does not replace access permissions, freshness checks, or human ownership of consequential decisions.

Q: Do small businesses need a data warehouse to define metrics?

A: No. Start with a source-of-record report and a reviewed metric card for a few decisions. A warehouse or formal semantic product becomes useful when definitions must be reused across many systems and queries; buying one before agreeing on the definitions will not settle what “revenue” means.

Q: Why can't a more capable model just infer the right revenue figure?

A: Different valid figures represent different business events. The model cannot infer an undocumented accounting policy, cancellation rule, or management objective with certainty from a column name. Give it an approved definition and require it to disclose ambiguity when a question falls outside that definition.

Q: Should every Teammate see the same metrics?

A: They should share the same definitions for measures they use, but access can differ by role. A summary of overdue balances may be appropriate for operations while individual payment information remains restricted. Definition consistency is not a reason to broaden permissions.

Q: What should an AI coworker do when two reports disagree?

A: Identify each source, definition, period, and refresh time; quantify the gap if it can do so safely; and send the discrepancy to the named metric owner. It should not pick a winner or trigger a consequential action until the difference is reconciled.

If you're ready to give persistent AI coworkers shared definitions, scoped access, and clear human decision boundaries, Associates AI Teammates provides the operating layer to configure and run them on your own terms. View pricing and get started at associatesai.team.