Zoey Weaver, who leads growth at MotherDuck, interviews Kaitlyn Henry, MotherDuck's Chief of Staff and formerly Chief of Staff at dbt Labs. Kaitlyn walks through two internal data apps built on MotherDuck, an AI token spend tracker and the weekly business review, and explains why Guides keep every team working from the same metric definitions. Both dashboards in the demo use dummy data.
Tracking AI token spend with a Flight
Frontier labs make usage data hard to get. Admin portals show spend per user and per API key, but unless you are on an enterprise plan there is no API, only CSV downloads for some data and screen scraping for the rest. Kaitlyn says she has never written a line of code or a line of SQL by hand, and she still built a Flight that downloads the CSV reports and scrapes the admin screens every Monday at 9 a.m., structures the results into MotherDuck, and feeds a dashboard. She says it took under two hours.
The dashboard breaks spend down by model and by surface, with Claude Code driving most of it and Cowork climbing. In the demo data, annualized spend is about $197K, roughly the cost of one headcount. The question she watches is how high that number can get before it is worth looking at open-weight models. She also reaches out to individual users when their usage spikes, and a Claude skill can give each person a summary of their own usage.
On ROI, she treats small spend like headcount: is AI making the team as productive as one more person? Beyond that, she argues ROI is an individual question because everyone uses these tools differently, so the work is helping each person use them well and making agent management part of a manager's job.
Checking a pipeline an agent built
Because the usage Flight scrapes screenshots, trust is the hard part. Kaitlyn lets the Flight pull the data, asks the model to explain how it processed it, spot checks the results, then folds the fixes back into the Flight prompt. She says that gets her about 90% of the way there. Her other rule: if you own a dashboard, look at it at least every two weeks, so you have an instinct for when a number is wrong.
The weekly business review Dive and Guides
The weekly business review Dive is meant to be the canonical source of truth for how the business is doing: pacing against the quarterly target, revenue from new versus existing customers, weekly changes in expansion and contraction, and an AI chat box for asking what drove a change. Building the dashboard is the easy part. Getting everyone to agree on what the numbers mean is not.
Guides are how MotherDuck does it. They are large markdown files that define about 25 key business metrics and how to calculate them, and they sit directly on top of MotherDuck, so every Dive and every question asked in Claude uses the same calculation. Her warning for operators: without them, someone says last week's AWR was 4.8, the CEO says 4.7, and the whole meeting goes to arguing about the number.
To settle a definition like churn in a usage-based business, she picked the two or three stakeholders who cared most (the CEO, the head of finance, and the customer success lead), got them aligned, and codified it once. Everyone else picked it up through their tools.
Guides, dbt, and where metric logic should live
MotherDuck still uses dbt for transformation but has no hard semantic model. After running a BI vendor's semantic modeling next to Guides, Kaitlyn found Guides did the same job with far less work. She says per-query a guide costs more than logic in the data model, since an LLM has to interpret it, but maintaining a data model over time is costly too, and guide logic can be moved into the model gradually.
She argues definitions belong in the warehouse. A friend on LangChain's data team told her their agents all query the warehouse directly and skip the semantic layer, so definitions need to live as close to the data as possible. She also described moving off a dedicated BI tool after shipping Dives internally, with the two data engineers reporting they had done almost no work. Her closing view: building dashboards is largely solved, and the next problem is trust in the data, which means back-end work that non-technical people can now do.
