For agents
Canopy is the business context layer for AI agents.
Every other context layer helps AI answer. Canopy is the only one that closes the loop: each metric carries what drives it, who owns it, and whether the last action actually worked, and it learns from that. So your agents move the business instead of just describing it.
What agents get on Canopy. None of it lives in your warehouse or semantic layer.
Causality, statistically proven. Not LLM pattern-matching
An intelligence layer runs proprietary ML models and statistical tests daily across all your metrics, from Pearson correlation to Granger causality, BH-FDR corrected. Your team edits the tree, pruning what is not causal, so every agent inherits that judgement.
Actions that respect your org chart. Live RACI on every metric
Canopy knows who is Responsible, Accountable, Consulted and Informed, and who reports to whom, so an agent notifies, assigns and escalates to the right person, not a mailing list.
Learns from actions actually taken. Not what people said
Actions are tracked against the metric they were meant to move and the impact is verified. What worked strengthens the model, what did not gets discounted, so recommendations sharpen over time.
Ten queries become one. Precomputed context
Comparison periods, rolling totals and outlier checks are precomputed around every metric, so an agent gets the full picture in one call instead of ten warehouse round trips. An order of magnitude fewer tokens per question.
Your warehouse bill stays flat. Our compute, not yours
Every aggregation, comparison and correlation runs in KPI Tree's proprietary encrypted in-memory engine, not your warehouse. Question volume grows; warehouse spend does not.
Plans and reforecasts in context. Not just actuals
Budgets, forecasts, targets and ramp profiles flow through the same pipeline as your actuals, so whether you are ahead of plan is a question an agent can actually answer.
Agents know when to trust a number. Outliers and staleness tracked
Every metric is continuously checked for outliers, gaps and stale syncs, and that status travels with every answer, so an agent qualifies its answer instead of confidently quoting a broken number.
Curated context in, noise kept out
Layer in qualitative context from tools like Notion and Slack, and connect any MCP-compatible server as a data source so long-tail SaaS metrics land in the same trees, ownership and targets as warehouse metrics. Curation runs in both directions: context known to be unreliable, such as self-reported numbers, is kept out, because an agent grounded in bad context is worse than an agent with none.
Same agents. Same MCP. Different context.
Connecting an agent to your warehouse or catalogue is real and good: governed definitions kill hallucinated SQL and permissions are inherited. Pick what your agent sits on today; the comparison is about everything after the number.
MCP| KPI Tree Canopy | ||
|---|---|---|
| Metric Context | ||
| Cross-platform | One warehouse only. Metrics living in other warehouses, databases or tools are invisible to the agent.Governs the Snowflake estate, including external sources it catalogues, but the context stops at the platform boundary.Governs the Databricks estate. Context stops at the platform boundary. | One context layer across Snowflake, BigQuery, Databricks, Redshift, Azure SQL, Postgres and Google Sheets, plus anything with an MCP server. Metrics from different platforms live in the same tree, with the same causality, ownership and actions. |
| Metric definitions | Raw tables and SQL. The agent re-derives every metric per question, so ask twice and you can get two answers.Strong. Semantic views give governed, composable definitions with lineage. This is the layer Canopy syncs from, not a rival to it.Strong. Unity Catalog metrics give governed definitions and lineage. This is the layer Canopy syncs from, not a rival to it. | Governed definitions synced from your semantic layer, identical on every surface, with the causal model on top. |
| Data lineage | Object dependencies and access history exist, but the agent reconstructs lineage query by query.Strong. End-to-end column-level lineage across the Snowflake estate.Strong. Table and column lineage across the Databricks estate. | Full dbt lineage travels over the same MCP: which models and columns feed every metric, with the causal model above it. Where the number came from and what moves it, in one context. |
| Queries per question | Roughly ten warehouse round trips per metric: the value, each comparison period, rolling totals, outlier checks.Definitions are governed but values are still computed per question; every comparison period is another query and another context-window round trip.Definitions are governed but values are still computed per question; every comparison period is another query and another context-window round trip. | Comparison periods, rolling totals and outlier checks are precomputed, so one call returns the full picture. Roughly ten queries become one. |
| Warehouse bill | Every agent question is warehouse compute, and agents ask a lot of questions.Every agent question is still warehouse compute; governance does not change where the queries run.Every agent question is still cluster or SQL warehouse compute; governance does not change where the queries run. | Aggregations, comparisons and correlations run in KPI Tree's proprietary encrypted in-memory engine. The bill stays flat as question volume grows. |
| Data confidence | None. The agent confidently quotes whatever the table returns, including broken numbers.Lineage and popularity signals point at authoritative assets, but there is no per-metric outlier or staleness state attached to an answer.Lineage and tags help discovery, but there is no per-metric outlier or staleness state attached to an answer. | Outliers, gaps and stale syncs are tracked continuously per metric, and that status travels with every answer. |
| Business Context | ||
| Causality | None. The LLM narrates whatever pattern it spots in the moment, and correlation gets presented as causation.Not covered. Semantic views define how metrics are calculated, not what drives them.Not covered. The catalogue defines metrics, not the causal relationships between them. | Driver edges statistically proven daily by proprietary ML models and statistical tests, Pearson through Granger causality with BH-FDR correction, and pruned by the people who know the business. |
| Ownership | None. Ownership lives in people's heads.Role-based access says who may read a table, not who is accountable for the metric moving.ACLs and tags say who may access the data, not who is accountable for the number. | RACI on every metric plus the live org chart, so an agent knows who is Accountable, who to notify and how to escalate. |
| Plan context | Plans usually live in planning tools or spreadsheets outside the warehouse, with no shared aggregation logic.Not covered. Governed context describes the data estate, not your budgets and reforecasts.Not covered. The catalogue describes the data estate, not your budgets and reforecasts. | Budgets, reforecasts, targets and ramp profiles flow through the same pipeline as actuals, so an agent knows what the plan was. |
| Action Context | ||
| Acting on a change | None. The answer ends in the chat window.Out of scope. Agents can read governed context; acting on a metric move is not what the catalogue does.Out of scope. Agents can read governed context; acting on a metric move is not what the catalogue does. | A metric move pushes to the named owner with the driver attached, and workflows escalate up the reporting chain when nobody acts. |
| Agent write-back | An agent can run SQL, but there is nowhere to record an action, an owner or an outcome.Read-oriented. There is no task, ownership or outcome object for an agent to write to.Read-oriented. There is no task, ownership or outcome object for an agent to write to. | The context is writable through the same MCP: agents file tasks against metrics, update ownership and propose tree edits, with every change traced. |
| Learning over time | Stateless. Every session starts from zero and the org never learns from itself.No action or outcome history; nothing accumulates between sessions.No action or outcome history; nothing accumulates between sessions. | Actions are tracked against the metric they were meant to move and the impact is verified. What worked re-weights the model. |
Causality, statistically proven daily
An intelligence layer runs proprietary ML models and statistical tests daily across all your metrics: Pearson correlation, lagged cross-correlation, partial correlation and Granger causality, with BH-FDR correction across the thousands of edge tests. Correlation alone is never reported as causation, and none of it is what an LLM thinks is a pattern in the moment. And because people edit the tree, relationships your team knows have no causal link are pruned, so every agent answer inherits that judgement. Statistical inference plus human correction, compounding, and no agent can re-derive it from raw tables.
Every driver edge. Every day.
Your org chart, in context
Canopy knows who reports to who and keeps an always-current RACI on every metric, so an agent's answer can become an action routed to the right named person rather than a paragraph describing a problem. When someone leaves or moves team, the accountability moves with them. There is no ownership primitive in a warehouse or a semantic view; this is context only the layer above can carry.
James Harrington
CEO
Sarah Chen
VP Revenue
A · Revenue
David Mitchell
VP Product
Sofia Martinez
VP Marketing
Emma T.
Growth
Laura F.
Sales
Reporting lines and RACI, current on every answer.
It learns from what actually happened
Canopy tracks the actions people actually took on top of the metrics, not what they said they did, and which of them moved the number, verified by the same pipeline that calculates actuals. That outcome history is context an agent can use: not just what drives revenue in theory, but which interventions have proven to move it here, in this business, when someone owned them. No other feedback signal comes close to observed behaviour change, and no stateless connection accumulates it.
Fix checkout flow
Verified · +£32kLinked to Revenue · measured by the actuals pipeline
Pause underperforming ad sets
Measuring…Roughly ten queries become one, and the warehouse bill stays flat
An agent investigating a metric straight on the warehouse runs roughly ten queries: the current value, each comparison period, rolling totals, outlier checks, every one a live warehouse hit and a context-window round trip. Canopy precomputes that metadata so a single query returns it, and every aggregation, comparison and correlation runs in KPI Tree's encrypted in-memory engine, not your warehouse. Agents burn an order of magnitude fewer tokens, answer faster, and your warehouse bill stays flat while question volume grows. This funds the layer; the capability above is why you buy it.
Revenue
19 Mar 2025Precomputed for every date in your history · in-memory · no warehouse query
Any date, any grain, every comparison. No query.
Every metric re-aggregates automatically to any granularity, daily, weekly, monthly, quarterly or yearly, while respecting each metric's additivity: sums sum, rates average, balances carry their last value. And for every date in your history, more than twenty comparison frames are already computed: rolling 7 and 30 days, week on week through year on year, every to-date frame against last period and last year, same day last year, retail 4-5-4 calendars, even Black Friday alignment. An agent can time-travel to any date and read all of it in one in-memory call, at answer speed. Budgets and reforecasts aggregate through the same pipeline, side by side with actuals.
Fast because nothing is computed twice
Your warehouse is queried once per metric per sync, never once per question. From there, every aggregation, comparison and correlation runs in KPI Tree's proprietary encrypted in-memory engine. There are no pre-aggregations to define and no cache warm-ups to schedule; the precompute is automatic for every metric and refreshes as new data lands. People and agents get answers at in-memory speed, question volume never reaches your warehouse, and the bill stays flat while usage grows.
Confidence built in
An agent on raw tables cannot tell a stale number from a fresh one, or an outlier from a trend, so it answers confidently either way. Canopy tracks outliers, gaps and staleness automatically and surfaces them as context, so the agent knows when to trust a number and says so when it should not. Budgets, reforecasts and ramp profiles are part of the context too, flowing through the same pipeline as actuals, so an agent knows what the plan actually was, not just what happened.
Run your own workflows on this context
Because Canopy holds the org chart, the RACI and the metric triggers, you can automate business processes on top of it. Someone is out of office? The action escalates to their manager automatically. A metric goes silent or a period closes off-target? A workflow fires, with approvals as the human gate. This is context that does things, not context that gets quoted.
Prefer us to run the agents? Meet Canopy Agents
Everything on this page is what external agents consume over MCP. When you would rather not bring your own, Canopy Agents are the agents KPI Tree runs for you: the Personalised Action Plan, RACI assignment, canvas and Slack agents, plus custom agents you deploy, all on this same context with your permissions, model choice, spend caps and full run history.
Weekly revenue review
scheduled · MondaysAsk questions that were previously impossible
What is driving churn, who owns the fix, and did last month's action actually work? No warehouse query answers those. Canopy's MCP carries the driver edges, RACI, verified impact, plans and full dbt lineage behind every metric, and it is writable: agents file tasks, update ownership and propose tree edits, all traced. Every answer is scoped to the asking user's permissions. And because the context is defined once, connecting another agent costs nothing: one-click setup for Claude, ChatGPT, Gemini, Copilot and the other MCP clients, with no separate integration per agent.