Why Agent First BI
BI is moving from something people build and people read to something agents maintain and agents read. Metrics Book is the stack built for that: open source, on one virtual machine, with an agent doing the work a data team used to do.
Agents now maintain BI, and read it
Section titled “Agents now maintain BI, and read it”Two things changed. Agent harnesses such as Claude Code can now work in a repository for hours, run commands and open pull requests. And the models behind them got good at working with data: writing SQL and dbt, reading a metric’s definition, checking a number against another.
Done right, an agent is now better at helping a person act on data than that person is at analysing it alone. So most analysis becomes a conversation: you ask, the agent queries, explains and suggests the change.
That does not remove dashboards. You still want a few reports that show where you stand at a glance, and Metrics Book keeps them, as anfra reports in git. The deep questions are where the agent takes over.
So the stack under BI should change too
Section titled “So the stack under BI should change too”Most companies doing BI today pay for two things:
- A cloud data warehouse, such as BigQuery or Snowflake. You pay for compute and storage plus a large margin for the service around it: the engineering, the console, the support.
- A BI tool on top, priced per seat and built for people: self-service screens and drag-and-drop charts. Most of these tools are now adding AI to give a reason to keep paying for them.
Built from the ground up for agents, the stack looks different. You run open-source tools on one virtual machine and pay for the machine: compute and memory, not a service margin. What it costs compares the two at list prices: from 1 TB of data up, the warehouses cost several times more for the same work.
Agents ask more questions, and warehouses bill each one
Section titled “Agents ask more questions, and warehouses bill each one”Data size is only half the bill. Agents ask far more questions than people do: one answer can take an agent dozens of queries, and it asks again when a number looks wrong. So an agent-first setup hits the database many times more often than a team of people would.
A cloud warehouse charges for that demand side: the bytes each query scans, or the hours a warehouse stays busy. Store the same data and ask ten times the questions, and the bill grows with them. A VM costs the same however many queries it answers. Its memory also keeps the tables agents ask about most in RAM, so a repeated question is answered from memory at no extra cost.
On 1 TB of data, the warehouses cost about what one VM does at 300 queries a day, and many times more at 30,000. What it costs shows the numbers and how they were worked out.
A mistake costs time, not money
Section titled “A mistake costs time, not money”On an on-demand warehouse, a mistake lands on the bill. An agent stuck in a loop, a query that reads every table, a warehouse sized too big and left running: each one bills until someone notices. On the 1 TB company, an agent stuck in a loop for a month multiplies BigQuery’s bill more than 40 times, and that is with Google’s default daily quota stopping it. Every vendor lets you set a ceiling, but only if someone sets it, at the right level.
On your own VM, the same mistake makes things slow. The bill stays the one you agreed to when you rented the machine. The agent gets the tools to find out why: every run records each step’s time, CPU and memory, and the ops commands designed for phase 7 rank what used the most, show the slowest queries and check the budgets you set. Then it fixes the cause, or tells you the machine is too small and which one to move to. What a mistake costs has the numbers.
Why this was not the obvious choice before
Section titled “Why this was not the obvious choice before”An open-source stack on your own server has been possible for years. It needed a skilled person to set it up, keep it running and fix it when it broke, and that person cost more than the warehouse margin saved.
An agent changes that sum. It sets the stack up, changes it through pull requests and keeps it healthy, held to checks that run on every change. A person reviews and merges. The work that made the open stack expensive is now the agent’s job.
The four tools
Section titled “The four tools”Each one is code first, and something agents already write well. dlt, DuckDB and dbt are open source; anfra is open apart from its compiler and query runner.
| Tool | Why it is in the stack |
|---|---|
| dlt | Loads data. Code first, with maintained connectors for the sources most companies use, and room to write your own when one is missing. |
| DuckDB | Stores and queries the data. Easy to run and fast on one machine. |
| dbt | Transforms the data. The most used tool for the job, its core is open source, and agents write it well. |
| anfra | The semantic layer from Holistics: how the tables join, which metrics and dimensions exist, and the reports people still want. |
The semantic layer matters most for agents. However smart an agent is, it needs one place that says what “net sales” means and how the tables connect. anfra holds that in code, and its queries translate straight into SQL the warehouse runs. On top of it sits an MCP connector, so any agent can query the governed metrics. Open source says which parts of anfra are closed.
What Metrics Book adds
Section titled “What Metrics Book adds”- The metrics book: each metric with a curated description an agent reads before it answers.
- Terms: the business words your company uses, each with one meaning.
- Search across everything: metrics, models, columns, terms and reports, by meaning as well as by name.
- Sign-in and access: per dataset, metric and report, with every query in an audit log.
- Tooling for agents: the
mbCLI, with--json, no prompts and refusals that say how to pass. - One source for internal apps: your own tools read the same metrics through the API with a service account.
When it fits, and when it does not
Section titled “When it fits, and when it does not”Metrics Book fits a company with up to tens of terabytes of data and a normal number of people using it.
Build it another way if you have petabytes of data, or hundreds of thousands of users querying it. At that size one virtual machine is the wrong shape, and the trade-offs change.
One deployment serves one organisation. Row-level security is not in version 1; the changelog lists what is built today.