The Context Layer Grounds the Agent. Nothing Checks the Question.

01Answering got solved. Asking did not.

Point a frontier model at a warehouse through a decent semantic layer and it will compute pipeline coverage correctly, every time. The major data platforms have all shipped governed context for agents: metric definitions, trusted datasets, terminology, business rules, verified queries. Open-source context layers pull YAML, DDL and wiki pages into one reviewable repo. This work is necessary and it is done. Grounding is table stakes.

But grounding answers the question it is given. It has no opinion on whether that was the right question, and no mechanism for producing the question nobody asked. Enterprise value has always sat disproportionately in the second category: the churn concentration that nobody segmented for, the pricing change whose effect showed up three months later in a different metric, the relationship between support volume and expansion that held for six quarters and quietly broke.

Historically the constraint was human attention. Analysts could form perhaps a dozen serious hypotheses a week and test a few. AI removes that constraint on the generation side: a system can form ten thousand candidate hypotheses overnight. It does not remove it on the checking side. Generating questions became cheap. Verifying them did not.

02The failure mode that matters now

There are two ways an agent gets analytics wrong.

• Hallucinated query. Wrong table, wrong join, wrong grain. The semantic layer fixes this. Anyone still presenting this as the frontier is describing a problem that has already been solved.
• Hallucinated conclusion. Correct SQL, real numbers, and an explanation that is fluent, plausible and false. “Churn rose because of the January release” when the January cohort is small, the effect disappears in adjacent windows, and the real driver is a support-tooling migration nobody thought to correlate. Language models are exceptionally good at producing this kind of output because they are optimised for exactly what it is: a coherent story.

When a person reviews the output before anyone acts, the second failure is survivable. The reviewer’s judgement is the check. But the entire point of the current agent wave is that agents act: they adjust a bid, reprioritise a rep’s day, trigger a retention offer, draft the board note. Once an agent consumes an insight directly, a confident wrong insight becomes a bad decision automatically. The human checker has been removed and nothing has replaced it.

That is the architectural gap. It is not a generation problem. It is a checking problem, and no amount of context engineering on the prompt addresses it, because the prompt is upstream of the mistake.

03What a question layer does

The question layer sits above the semantic layer and below the agents. It has one job: continuously convert governed data into verified insight, and refuse to emit anything that has not survived a real test.

Its loop is four steps.

1. Generate. Form candidate hypotheses across the business. Not “is anything anomalous” but specific, testable claims: conversion for segment S fell after date D and did not fall in comparable segments.
2. Test. Run each hypothesis against the company’s actual data through the semantic layer. The test is statistical and structural, not a model reading the numbers and deciding whether they look right.
3. Score and gate. What survives gets a confidence score built from its statistical strength, its replication, and its business materiality. Below the threshold, it is discarded. Nothing below the threshold reaches an agent, ever.
4. Deliver with evidence. What passes goes to agents and people as a machine-readable insight with its full evidence record attached: the populations, windows, comparisons, and the alternative explanations that were tested and rejected.

The position on human review is deliberate and worth stating plainly. Insights that pass the gate go straight to agents with no person reviewing them first. That is only defensible if the gate is real, which is why the mechanics below are the product, not the interface.

04The mechanics that make the gate real

Where hypotheses come from

A hypothesis is a test specification: a metric, a population, a comparison, a window, and a claimed direction. Generation draws on four sources, and the mix is what keeps the search from being either trivial or infinite.

• Structural decomposition. Walk the metric tree. If a headline metric moved, form hypotheses over every child dimension and cohort that could account for it. Necessary, but on its own it only ever explains movements that have already happened.
• Change detection over time. Change points in individual series and, more usefully, in relationships between series. A broken correlation between two metrics that held for two years is a stronger hypothesis than a spike in either.
• Cross-domain relationships. Sales activity against product telemetry, support volume against expansion, campaign timing against pipeline velocity. The valuable questions cross the boundaries that org charts and dashboards respect.
• Business-context priors. Plans, targets, launches, pricing changes, campaigns, known events. These do two things: they generate hypotheses (“the pricing floor changed on 14 July; test everything downstream of price”) and they set materiality, because a two-point movement against plan matters more than a five-point movement in a metric nobody is managing to.

The fourth source is the hardest to build, because it lives outside the warehouse: in decisions, documents and the heads of operators. Bringing that context into generation is what turns statistical search into business search, and it is the long-term bet.

How a hypothesis is tested

This is where fluent systems fail and disciplined ones earn trust. Testing ten thousand hypotheses against one dataset is a textbook garden of forking paths: at conventional significance, hundreds will pass by chance. A question layer that does not control for this is an anomaly-spam generator with better prose. The checks that matter:

• False discovery control across the whole batch, not per-test significance. The system knows how many questions it asked and adjusts what counts as surviving.
• Effect size before significance. A statistically robust movement of 0.3% in a metric with a 2% weekly noise floor is not an insight.
• Replication in adjacent windows and populations. If the effect only exists in exactly the window and cohort where it was first found, it is discarded.
• Composition checks. Simpson’s-paradox style reversals are tested for explicitly: does the aggregate movement hold within every major sub-population, or is it a mix shift masquerading as a trend?
• Competing explanations run as competing tests. For any surviving hypothesis, the plausible alternatives are formed and tested too. An insight is only delivered with the alternatives that were rejected and the evidence that rejected them.
• Data-quality tripwires. Late-arriving data, backfills, schema changes and pipeline failures produce more false insights than real business change does. Every test runs against freshness and completeness checks first.

None of this is novel statistics. What is novel is running it automatically, at batch scale, as the gate between data and an acting agent.

What the confidence score is made of

Confidence is not a model’s self-reported certainty. It is a composite of things the system can actually measure: survival strength after false-discovery adjustment, replication count, magnitude relative to the metric’s own history, business materiality from context priors, and, over time, the historical hit rate of hypotheses from the same generator and domain. The delivery threshold is a policy the organisation sets per domain, not a hidden number.

The evidence record

Every delivered insight carries a record an auditor or a sceptical analyst can open: the exact queries against the semantic layer, the populations and windows, the comparisons, the rejected alternatives, and the freshness state of every source at test time. For regulated buyers this is not optional. For everyone else it is what lets a data team trust a gate they did not hand-build.

The feedback loop

Insights are delivered with a lifecycle. Acted on or dismissed, and by whom. Did the signal persist, spread or revert. Did the action taken produce the expected movement. Those outcomes flow back into two places: the generator’s priors, so hypothesis families that keep producing dismissed insights get deprioritised and ones that keep producing action get explored more deeply; and the materiality model, so the system learns what this business treats as important rather than applying a generic notion of anomaly.

This loop is what stops the layer from becoming noise by month four.

05Everything in the stack scaled except the asking

Look at what has improved in the last few years. Storage and compute became effectively unlimited. Semantic and context layers matured to the point where an agent can be handed governed meaning instead of raw tables. Language models went from producing plausible SQL to producing correct SQL, and from summarising a result to reasoning about it. Every layer between the event and the answer got faster, cheaper and more reliable.

One thing did not scale: the organisation’s capacity to ask.

Surfacing insight continuously has always depended on people. On how many analysts a company can hire, how much of their week survives reporting and ad hoc requests, how much domain context each of them carries, and how many hypotheses one person can hold in their head before something else moves. In most organisations that capacity is a handful of people forming a handful of questions a week, and the talent that can do it well is scarce, expensive and unevenly distributed. Large enterprises ration it. Smaller ones simply do not have it.

So the business has more data, better semantics and stronger models than ever, and the number of questions actually being asked of that data has barely changed. The constraint moved. It is no longer in the pipeline or the model. It is in the asking and the checking, and that is exactly the work a question layer is built to take on: forming far more hypotheses than a team ever could, and being far more ruthless about which ones survive.

06Where it sits

The question layer does not replace anything already in the stack. It consumes the semantic layer for meaning and governed access, consumes the data platform for compute, reads business context from wherever it lives, and emits verified insights to agents, applications and people. Concretely:

• Data platformCollect, integrate, store.
• Semantic and context layerDefine what the data means; ground the queries.
• Question layerForm, test, gate and evidence the insights.
• Agents and applicationsConsume verified insight and act.
• FeedbackOutcomes return to generation and materiality.

Keeping the question layer separate from the agent is a deliberate separation of concerns. If the checking logic lives in the agent’s prompt, every new model, agent framework or interface rebuilds it, and it is unauditable. As a layer, it is model-agnostic: the agents will change every quarter, the verified record of what the business has learned should not.

For organisations with a mature data and AI team, this is a force multiplier on the questions the team never gets to. For those without one, it is the analytical function they could not hire.

07Question the question

Every agent can already read a company’s data. The context layer made that reading accurate, and that is the commodity. What remains scarce is the ability to ask the question nobody thought to ask, prove the answer against real data rather than plausibility, and put only what survives in front of a system that will act on it.

That is a checking problem, and it deserves a layer of its own.