The Operating Model for Trustworthy Analytics AI Agents
A valid SQL query can produce the wrong answer when it starts from the wrong definition or source.
That sentence is the entire problem with how most teams evaluate analytics agents. They measure whether the output is correct. They skip the harder question: did the agent use the right information to get there?
I have spent the past year building production analytics systems. One produces a daily executive briefing using five parallel agents. One investigates where customers drop off and produces fix-ready actions with owners and tickets. One brings investigative analytics into Slack using an intent router and tiered query controls.
Each system taught me something different about where analytical trust breaks. The executive briefing taught me that an answer needs a governed route with evidence, not just a plausible number. The investigation system taught me that every wrong answer has a specific failure class, and treating them all as “the agent got it wrong” makes diagnosis impossible. The conversational agent taught me that a confident wrong answer from the wrong table is worse than no answer at all.
Together they produced an operating model with three layers: when an agent must refuse to answer, how an answer earns and maintains trust, and how to diagnose exactly where things break.
OpenAI, Anthropic, and Meta have each published how they built internal analytics agents. Their architectures differ. But they keep running into the same operating constraint: a capable model is not enough when definitions, sources, and validation are weak.
---
Part 1: When the agent must stop
An analytics agent needs hard rules for when it must not answer. Without them, fluency fills the gap. The agent produces something that sounds right, and sounding right is dangerous when the number gets forwarded to an executive.
Every response should resolve to one of four states before the agent writes anything:
**Answer** when the route and validation checks pass. **Clarify** when the question lacks a period, segment, grain, or metric definition. **Review** when the route is plausible but the owner, benchmark, or validation remains unresolved. **Refuse** when the source is unsafe, stale, contradictory, or outside scope.
The refuse state needs hard gates. Here are the ones I use:
1. The requested source does not match the approved source for the metric
2. Freshness falls below the metric’s minimum requirement
3. Required filters or exclusions cannot be applied
4. Two approved artifacts conflict and no precedence rule exists
5. Arithmetic, reconciliation, or known-range checks fail
6. The request asks for action under unresolved high-impact ambiguity
7. Credentials, personal data, or restricted fields appear in the output path
8. The system has a plan but no evidence that the source actually ran
That last one catches a subtle failure I have seen repeatedly: the agent writes a query, describes what it would return, and presents the description as a result. A plan is not an execution.
When the agent refuses, it returns a structured record: which gate failed, what it observed, why answering would be unsafe, and the specific next step to resolve it. No hedged answer. No “here is a number but I am not sure.” The refusal is the output.
OpenAI addresses this through institutional knowledge layers that encode which tables are canonical across more than 3,500 internal users and 70,000 datasets. Anthropic builds procedural skills with explicit stopping conditions and reports that skills drove accuracy from roughly 21% to approximately 95%. Different solutions to the same problem: the agent needs something outside itself that tells it where to look and when to stop.
---
Part 2: How an answer earns trust
Refusal gates handle cases where the agent should not answer at all. The lifecycle handles everything else.
My executive briefing runs every morning. Five parallel agents each analyze a different dimension: core metrics and decomposition, daily trajectories and leading indicators, market context, internal communications for operational signals, and data freshness with prior briefings for continuity. A synthesis agent assembles their outputs into one executive narrative.
This system had to be right every day. That constraint produced a nine-stage lifecycle:
**Scope.** Define the metric, period, segment, and decision context. If something material is ambiguous, move to Clarify.
**Retrieve.** Pull the smallest set of approved context: definitions, source guidance, freshness rules. Precision matters more than volume.
**Bind source.** Commit to a named definition and approved table before seeing the result. This prevents the agent from shopping for the most convenient number after the fact.
**Execute.** Run the approved query. Record metadata. Distinguish between a proposed query and an executed one.
**Validate.** Check definition alignment, freshness, arithmetic, grain, filters, reconciliation against known ranges.
**Record evidence.** Save a compact record: the question, source, context used, checks performed, remaining uncertainty. A number without an audit trail is a guess with formatting.
**Review.** A named owner approves or corrects the answer and the proposed reusable route.
**Reuse.** Save the reviewed path (the method, not the number). On the next run, skip discovery but still validate freshness and record new evidence.
**Measure.** Track retrieval accuracy, application correctness, and answer state accuracy separately. A single accuracy number hides which stage broke.
Two clocks run on every saved path. A **freshness clock** tracks whether the underlying data is current enough. An **expiry clock** tracks whether the saved method, definition, and owner approval are still valid. A path can have fresh data and still be expired. The table loaded this morning, but the reusable route required quarterly owner review, and that approval lapsed. The agent routes back to Review.
OpenAI built cross-session memory that captures corrections at the institutional level. Anthropic grounds definitions in a semantic layer with explicit source-of-truth contracts. Both are solving pieces of the same two-clock problem: keeping the data current and keeping the method current.
---
Part 3: Why it broke
Standard evaluations ask: did the agent get the right answer? Context-path testing asks: did the agent use the right information to get there?
An agent can arrive at a correct number through the wrong path. That path will produce a wrong number when conditions change.
My investigation system caught this repeatedly. It would surface a pipeline silently failing, a conversion decline persisting across multiple cohorts, and a denominator bug distorting a metric leadership watched weekly. Each failure had a different root cause. The pipeline issue was a data freshness problem. The conversion decline was a real business change. The denominator bug was a definition error baked into the source.
To diagnose failures precisely, I track four context sets for every question:
**Required context:** the artifacts needed for a defensible answer, defined before the run.
**Eligible context:** the relevant artifacts available to the agent.
**Retrieved context:** what the agent actually pulled.
**Applied context:** what actually changed the answer.
Retrieved but ignored is a different failure from never retrieved. That distinction is the entire diagnostic value.
From there, every failure falls into one of six classes:
**Missing asset.** The required definition does not exist yet. No prompt engineering fixes this.
**Retrieval miss.** The artifact exists but the agent did not find it. An indexing or embedding problem.
**Context conflict.** Multiple sources disagree and the agent picked one without flagging it. Needs a precedence rule.
**Application error.** Right context retrieved, then ignored. A prompt structure problem.
**Query error.** Context was correct, the generated SQL was not.
**Source data error.** The underlying data did not load or returned corrupt results.
Adding more documents to context fixes none of these uniformly. It might help retrieval misses marginally while making retrieval precision worse, which creates new application errors.
I keep four metrics separate: retrieval recall (did the agent find required context), context precision (how much noise came with it), application rate (did retrieved context actually shape the answer), and conditional correctness (given good retrieval, was the answer right). Merging them into one accuracy score hides which stage broke.
Anthropic validates this approach through ablation testing: systematically removing context layers to identify which one caused the failure. Meta found that 88% of data-scientist queries rely only on tables the user queried within the preceding 90 days, which suggests that context-path reuse is the natural pattern when the right tables are already known. Both observations point to the same conclusion: “wrong answer” is not a diagnosis. Each failure class has a different fix.
---
How these connect
The refusal gates are the safety layer. They prevent the agent from delivering answers it should not have attempted.
The lifecycle is the quality layer. It defines how an answer earns trust and how that trust degrades gracefully.
Context-path testing is the diagnostic layer. It tells you exactly where things broke and what kind of fix each failure needs.
OpenAI built multi-layered context and institutional memory across 70,000 datasets and more than 600 petabytes of data. Anthropic built a semantic layer with procedural skills that drove self-service analytics accuracy from roughly 21% to approximately 95%. Meta built an analytics agent adopted weekly by 77% of their data scientists and data engineers. Their architectures differ. The shared constraint is the same: a fluent model cannot substitute for governed definitions, validated routes, and honest failure handling.
The playbooks are open on GitHub: