Every BI stack I have ever seen ends the same way: a human looks at a chart and decides what to do. The upstream engineering work (ingestion, modelling and testing) exists so that a person can read the chart and decide. The dashboard provides the information and a person takes the action, and analytics has worked this way for twenty years.
For my MSc dissertation I first built the usual analytics part of that process. I built a churn intelligence stack for a live B2B SaaS environment: survival analysis to say when accounts are likely to leave, gradient-boosted classification with SHAP explanations to say how likely and why, and DR-Learner causal inference to say which interventions actually work rather than which ones merely correlate with staying. It sits on a warehouse of 48 dbt models in layered Kimball style, loaded by Python extractors and orchestrated with Dagster.
Then, instead of stopping at the dashboard, I put a Model Context Protocol endpoint on top.
What MCP actually changes
MCP is a small open standard that lets an LLM agent call tools you define. My server exposes twelve of them over the intelligence stack: things like churn_at_risk_accounts, churn_score_for_account, and csm_intervention_priority, organised into churn, account, and customer-success domains over a shared database layer.
The difference is easiest to see in one exchange. A customer success lead asks: "Which accounts are high risk this quarter, and which of those would actually respond if we intervened?" On a dashboard, that is two filters, a mental join, and an argument about what "respond" means. Through the MCP endpoint, an agent chains two tool calls, cross-references the survival window with the causal treatment group, and answers with the ranked list and the SHAP drivers per account. The person still makes the decision but no longer has to wait, filter or combine the two views manually.
My main point is this: dashboards inform, agents act, and the main engineering question becomes the quality of the data layer underneath.
Agent answers depend on tested marts
Most agent demos leave out the following point. An LLM agent will answer from a broken mart with exactly the same confidence as from a correct one. It has no idea your revenue model silently double-counts renewals. A human analyst might question a suspicious number; the agent summarises it without checking it.
The reliability of the agentic layer therefore depends on routine data work in the stack. In this build that meant dimensional models with tests on every layer, contracts on the interfaces the tools query, and correctness gated in CI before anything reaches the serving layer. This work is hard to show in a demo, but it is the reason the agent's answers can be trusted.
If your marts are not tested, an MCP endpoint gives fluent, confident answers that can be wrong.
Limitations
This was a dissertation build against an NDA-protected environment, so the case study on this site is sanitised and the published code is anonymised. The survival model cross-validated at a C-index of 0.850 and the classifier at an AUC of 0.924, outperforming a logistic baseline. The causal layer corrected a selection bias of roughly 50 percentage points that a naive comparison would have reported as fact. The tested data layer is what made those results reliable.
Agents reduce the time between a question and its answer; analysts are still needed. Someone still has to decide what a treatment group means, whether an intervention is worth its cost, and when the model is wrong. That someone now spends their time on judgement instead of filters.
The pattern applies to other domains
Nothing here is churn-specific. Any intelligence layer with real modelling underneath it, priced risk, demand forecasts, fraud scores, can be exposed the same way: tools over tested marts, explanations attached to every number, and an agent in front. I think in three years it will simply be what "serving layer" means.
Read the full case study → View on GitHub →
I am an analytics engineer in Manchester, UK, and I build data platforms with dbt, Dagster and PostgreSQL. If you work on similar problems, you can contact me through the contact page.