Three problems that neither another analyst nor another agent will solve.
Data leaders know these mornings well. None of them is a staffing problem, and none of them is fixed by giving stakeholders a chat window. There is a missing layer between a metric being defined and anyone, human or agent, understanding what it means.
Every AI answer still ends up on your desk.
Stakeholders point agents at the warehouse and get instant, confident answers. Then they forward them to your team to check, because an agent starts from zero on every question and narrates whatever pattern it finds, with no way to test it. The same question asked twice returns two different stories, and you are the referee. The agents did not remove the bottleneck. They industrialised it.
The silently wrong number costs you the most trust.
A headcount gets summed instead of taken at period end, a balance gets averaged across the quarter, or a metric quietly stops syncing and still gets quoted in the board pack a fortnight later. Nobody files a ticket for numbers like these, because nobody notices them until they surface somewhere expensive. Your team takes the blame either way.
The backlog grows faster than your headcount.
Every analyst you hire creates capacity that is consumed within weeks, because the underlying problem never changed: stakeholders cannot see how metrics connect, so they ask your team for context that no dashboard was designed to provide. You are not short-staffed. You are absorbing a structural gap in your stack.
Not a dashboard. A causal model tested against your data daily.
KPI Tree does not visualise your data in another way. It models how your metrics drive each other, and then it checks the model. Every relationship in the tree is a driver edge carrying a confidence level and a statistical significance score, recalculated daily as new periods land, so causality is statistically proven over time rather than asserted once. AI drafts the tree, your team corrects it, and the evidence decides. What stakeholders trace, and what every agent inherits, is judgement your team has already validated.
- Every driver edge carries a confidence level and a statistical significance score, retested daily as new data lands.
- AI drafts the tree from a plain-English description of the business, and every node and edge stays editable.
- Your team prunes false-positive correlations, so the model reflects their judgement instead of overruling it.
- Stakeholders navigate the model and answer their own questions without writing a single query.
Synced from your semantic layer, so the silently wrong number gets caught.
Your metric definitions stay where they are. KPI Tree syncs them from dbt, Looker and Snowflake semantic views, and reads the aggregation semantics as it does: a headcount is taken at period end rather than summed, a balance carries its last value rather than averaging, without anyone configuring it by hand. Data quality is watched continuously, and when a metric stops updating, a silent-metric trigger fires and routes it to the named Accountable owner instead of waiting behind a warning badge. The Analyst view keeps SQL close, so your team can query the metric data behind the tree and validate any number it shows.
- Metric definitions sync from dbt, Looker and Snowflake semantic views, with metrics calculated where the data lives on Snowflake, BigQuery, Databricks, Redshift, Azure SQL and PostgreSQL.
- Aggregation semantics are detected automatically, so sums, averages, last values and first values are applied as your definitions intend.
- Outliers, gaps and staleness are tracked on every metric, and a metric that stops updating routes straight to its named Accountable owner.
- The Analyst view lets your team run SQL against metric data to validate any calculation without leaving the tree.
One causal model for your team and every agent they use.
Your semantic layer tells AI how each metric is calculated. KPI Tree adds the layer above: how metrics drive each other, who owns them, and whether the last action worked. That layer is Canopy, the business context layer, served over MCP to Claude, ChatGPT and the agents your organisation already uses. An agent connected to Canopy answers with the driver edge and its confidence and significance, the named owner and the verified-impact history attached, so every surface grounds in the same model your team maintains. The two layers are peers in a stack, not substitutes.
- The MCP surface carries significance-tested driver edges, RACI ownership and verified-impact status, context no warehouse table holds.
- One-click setup connects Claude, ChatGPT and other MCP clients, with every answer scoped to the permissions of the person asking.
- Agents stop rebuilding their picture of the business on every question, because the causal structure is defined once and tested daily.
- Your semantic layer remains the source of calculation truth, synced rather than replaced.
From service desk to the team that built the system.
The loop that used to run through your inbox now runs on the platform. A metric moves and the named Accountable owner is notified with the driver behind the change attached, complete with its confidence and significance. The action they take is tracked against the metric it was meant to move, and the impact is verified from the numbers the pipeline already produces, not self-reported in a retro. Meanwhile the questions that used to land in your DMs get answered where they are asked: mention KPI Tree in Slack and the reply is grounded in the model your team has already validated, not reconstructed from scratch per question.
- When a metric moves, its named Accountable owner hears about it with the driver included, rather than a channel being told a number changed.
- Actions are tracked against the metric they target and impact is verified from the data, so outcomes are observed rather than self-reported.
- The Slack assistant answers metric questions in the channel from the same causal model, so routine questions stop landing in your backlog.
- The engagement heatmap shows who is viewing, who is acting and who needs a nudge, measured in actions taken rather than queries run.
Start alongside your BI tool. Let the results speak.
KPI Tree is not a replacement for your BI tool. Dashboards keep handling exploration and the data that has not yet been defined as a metric. KPI Tree takes the structured layer: the defined metrics, the driver relationships between them with confidence and significance stated, the ownership, and the actions verified against the numbers. Start with one tree and one team, and expand as the request volume drops.
“Your semantic layer tells AI how metrics are calculated. KPI Tree adds the layer above: how they drive each other, who owns them, and whether the last action worked. Peers in a stack, not substitutes.”
Your data stack has every layer except the one that creates understanding.
Your warehouse stores data reliably. Your semantic layer defines metrics consistently. Your BI tool visualises them clearly. None of them records what drives a metric, who is accountable for it, or whether the last action moved it. KPI Tree adds that layer, for the people who ask and for the agents they ask with.
Peers in a stack, not substitutes
KPI Tree sits above your semantic layer, not in place of it. Definitions sync from dbt, Looker and Snowflake semantic views and remain the source of calculation truth. The layer above adds what they cannot model: driver relationships with confidence and statistical significance, live ownership, and verified outcomes. Nothing moves. Everything connects.
Causality you can defend
Every driver relationship carries a confidence level and a statistical significance score, tested daily against your data, and your team prunes what the statistics cannot rule out. When an executive challenges the answer, the working is on the canvas rather than inside a model nobody can inspect.
Economics your team can verify
Comparison periods, rolling totals and driver correlations are precomputed, turning roughly ten agent queries per metric into one. Every aggregation and comparison runs in KPI Tree's own compute engine, so the warehouse bill stays flat while questions scale. The capability above is why you buy the layer; the saving is what funds it.
Common questions
How does this work alongside our BI tool?
How is this different from what our semantic layer already does?
Why not point our agents straight at the warehouse?
Can our analysts still write SQL?
What happens when a metric goes stale?
How long does it take to set up?
Related guides
Semantic layer vs business context layer
A semantic layer settles what a metric is. It cannot settle how metrics drive each other, who owns them, or what happens when one moves.
dbt semantic layer and metric trees: how they fit together
dbt is the plumbing, the metric tree is the application above it
Why AI Agents Need Business Context, Not Just Data Access
Data access makes an agent fast. A causal model makes it right.
Give your team back the week they lose to requests and rechecks.
Your stack is solid and your team is good. The missing piece is the layer that records how metrics drive each other, who owns them, and whether the last action worked, for the people who ask and the agents they use. See KPI Tree running on your own stack.
