the truth layer · interactive

Agent lifecycle

How an AI agent turns a plain-English question into a governed, trustworthy metric answer — in six stages.

Stage 01

Query embedding

The user's natural-language question is converted into a high-dimensional vector so the system can find semantically similar metrics — even when the words don't match.

User
What was APAC revenue last quarter versus plan?
Semantic match, not keyword match. The query says "APAC revenue" — but the winning metric is named Total Revenue (FP&A Blend). Embeddings understand that FP&A leaders asking this question mean the governed, plan-comparable revenue number, not a raw regional slice.
Stage 02

Tool selection

With a target metric in mind, the agent picks how to fetch it. It has three tools. Its choice is driven almost entirely by each tool's description.

Option A

raw_sql_query

Direct warehouse access. Execute arbitrary SQL against production tables. No semantic layer, no metric definitions — caller is responsible for joins, filters, and correctness.

description signals: ⚠ no governance
Option B

warehouse_table_query

Query curated analytics tables (fct_revenue, dim_region). Cleaner than raw SQL, but no metric ownership, no freshness SLA, no trust score.

description signals: ⚠ no contract
Option C

metrics_library.get

Returns a governed metric with its canonical definition, owner, freshness SLA, upstream lineage, and trust score. Used by FP&A leadership for board reporting. Supports period & plan comparison out of the box.

description signals: ✓ governed · ✓ owned · ✓ trusted
Tool descriptions ARE prompt engineering. The agent didn't pick Metrics Library because it's faster or cheaper — it picked it because the description contains the words "governed," "owner," "SLA," "trust score," and "FP&A leadership." Every word in a tool description is a vote.
Stage 03

Progressive context loading

Loading every candidate's full definition would burn the context window. Instead the agent pulls a cheap preview, filters, then hydrates only what survives — and compresses again once it has an answer.

① Preview · top 6 candidates

Call the lightweight metrics.preview endpoint — name, one-line purpose, owner. ~50 tokens each.

② Filter · above similarity threshold

Drop anything under 0.80. Only 3 survive. The other 3 never touch the context window.

③ Hydrate · full definition for 3

Call metrics.get for the survivors: full definition, lineage, SLA, trust contract. ~500 tokens each.

④ Compress · summarize post-answer

After the agent has produced the answer, each hydrated metric is compressed down to a ~15-token reference for the next turn.

Context budget

0 tok/ 6,000 naive
− 4,200 tokens saved vs naive load
Progressive loading = progressive trust. Naively hydrating all 6 candidates would cost 6,000 tokens. The previewed-then-hydrated path costs 1,800. After compression, the agent carries only 45 tokens of metric context into the next turn.
Stage 04

Trust contract evaluation

The agent opens the metric's trust envelope and checks five signals. It computes a single trust score and maps it to an action band — but a silently broken pipeline can make reported and actual diverge.

Trust envelope · Total Revenue (FP&A Blend)
Trust score
87
Act
<60 Escalate
60–80 Caveat
>80 Act
stale upstream table · monitors green · reported score unchanged
Severity · same band
Reported 87 · Actual 87 · No divergence. Agent acts on the metric.
Stage 05

Persona-aware rendering

The API returns one payload. The agent renders three answers. Same data, different framing — because a CFO, a veteran analyst, and a new intern need different things to trust the number.

Personas aren't cosmetic. The intern needs a human to ping; the CFO needs a trust grade and plan variance; the analyst needs the lineage path to sanity-check the join. Rendering is a trust-layer decision, not a UI afterthought.
Stage 06

Evaluation & calibration

Evaluation has two gaps. Most teams only close the first. The second is where the incidents come from.

Gap 1 · agent behavior

Does the agent do the right thing?

Pre-production, testable. Given a question, does it pick the right tool, the right metric, and render it correctly? Measurable in a lab.

  • Tool-choice accuracy
  • Metric-selection precision
  • Rendering conformance
Gap 2 · data trust

Is the answer actually true right now?

Post-production, invisible until something breaks. The agent did everything right — but the upstream table silently went stale four hours ago. No test catches this.

  • Upstream freshness drift
  • Schema / semantic silent changes
  • Lineage health decay

Which eval catches which gap?

Evaluation typeGap 1 · behaviorGap 2 · data trust
Offline backtestingReplay past queries against known-good answers ● strong ○ misses
Online production signalsThumbs, retries, escalations, trust-envelope deltas in the wild ● partial ● catches
Adversarial stress testingInject stale data, broken lineage, ambiguous prompts ● strong ● strong

Event stream · the feedback loop

Every render, trust-envelope read, user reaction, and eval run is an event. The stream feeds back into the trust signals the next query will use.
Calibration is continuous. The trust score the agent saw in Stage 4 is not static — it is the rolling output of this event stream. Close Gap 1 with offline + adversarial tests; close Gap 2 with live production signals flowing back into the envelope.