A finance lead starts the morning with a question: which overdue invoices were paid since the last bank day? Nobody built a report for it.

For most of my career, the route from an ERP to an answer like that went through a data lake or a data warehouse. ETL jobs copied the data out. Data marts shaped it. Cubes and dimensions made it fast to slice. A dashboard sat on top. Newer stacks load the data first and transform it inside a cloud data warehouse, and the cube became a semantic model, but the shape is the same. Building it took a long time, the licenses kept costing, and it answered the questions someone had predicted.

The morning question wasn't one of them. In my experience it rarely is.

Built for the questions someone predicted

The data warehouse does what it was built for. Monthly reporting, the KPI board, the numbers that have to match last year's. For those, a governed, historical copy of the data is the right tool.

The trouble is the question that arrives before anyone built a report for it. That one goes to the person who knows the tables, or to an Excel workbook that queries the ERP directly, or it waits. BARC has tracked this for years: on average about 25% of employees actively use BI tools, with minimal growth over seven years.

Five weeks of questions

Since January I've built a Model Context Protocol (MCP) server for Db2 for i. It lets AI assistants read an ERP on IBM i, read-only. People at one company use it on most working days, and the server records one sentence from the model on why it makes each call.

About six people made 2,667 tool calls. 71% of them were SQL the model wrote itself, joining tables it had found itself. The questions spread across the business: receivables and ledger checks, stock and purchasing, sales, the order book, service orders, prices. Some of them, anonymized:

Which payments landed on overdue invoices since the last bank day.
Customers with both open credit notes and open invoices, so they can be netted now.
The order book on the same date each year, because the order book is seasonal.
Stock value split between two stock locations, for an insurance tender.
Last year's sales split into products and service, as the base for product liability insurance.

Five weeks of questions to the ERP: 1,890 queries an agent wrote itself, grouped roughly by keyword. Receivables, ledger and finance 344. Stock, purchasing and suppliers 240. Sales analysis 235. Finding the right table or column 188. Checking one record 163. Order book and open orders 86. Service and work orders 71. Prices 36. Not matched by any keyword 527, drawn as a dashed outline.

It isn't only IBM i. Microsoft now documents an MCP server for Dynamics 365 finance and operations with a tool to "find or read records by using SQL".

Plausible and wrong

Then a number comes back that looks right and isn't.

I wrote about this in September: the model finds the order table, finds the status column, writes a clean query, and counts the wrong orders as open. On a real system I watched it count hundreds of deleted orders as still open. The note that said which flag marks a deleted order was there. The model hadn't read it.

The errors here were harmless: 4% of calls failed, almost all of them SQL that Db2 for i rejected and the model rewrote. The dangerous answers don't fail.

Anthropic's data team reports that without curated context, "Claude's ability to answer analytics questions accurately didn't exceed 21% on our evals." They also warn that "pointing Claude at a warehouse and letting the agents execute can create a false sense of precision." Their setup runs on a data warehouse, so a clean copy of the data doesn't fix this.

What the data warehouse was really for

The data warehouse route does two jobs.

One is plumbing: copying the data out, keeping history, shaping it so a dashboard can slice it fast. For the one-off question, an agent with a read-only connection to the source does most of that work in the conversation.

The other is meaning. Which orders count as open. Which rows are deleted. Which sales figure is the reported one. Hidden inside the ETL jobs, the marts and the cube definitions were years of decisions about what the numbers mean. That job doesn't go away.

Modern stacks already give that job its own layer: the semantic layer, where a measure like net sales is defined once. Chris Child of Snowflake said of core metrics at Atlan's Great Data Debate: "Traditionally that was in the BI tool, but it should sit a layer lower." What I'm describing is a small semantic layer, written for an agent instead of a dashboard.

In a small study this spring, Michael Rumiantsau and Ivan Fokeev gave three frontier models the same 100 analytics questions, with and without one document describing the data. Accuracy went from between 45% and 51% to about 68%, and the document "accounts for essentially all of the significant variance; model choice within tier does not."

The document

In the Db2 for i server that meaning lives in a few YAML files, in three parts:

Rules the model reads before its first query. The few things no query may miss, like which flag marks a deleted order.
Table notes it reads when it touches a table. What the table holds, what each code means, how tables join.
Business tools for the questions people ask again and again, answered with SQL the business already trusts.

In those five weeks the model looked up the business context about once for every ten queries it wrote, with reasons like "Need receivables rules for overdue and payment checks".

A person owns it. Anthropic found that letting the model generate the whole layer was net-negative on their evals, and recommends "generating the documentation with Claude, but having a human own the definition."

It has to be kept up. Their accuracy drifted from about 95% to about 65% in a month when the documentation wasn't maintained. A data warehouse that falls behind fails loudly, with a broken load. A document that falls behind fails quietly, with plausible numbers.

And the morning question? It came back day after day, so now it runs on a schedule every weekday at nine. The assistants have that built in. Claude's scheduled tasks, formerly called routines, save a prompt and its connectors once and run them in the cloud, "so they keep working when your laptop is closed." The docs add that the prompt must be "explicit about what to do and what success looks like." For a report, what success looks like is the meaning.

The morning run still reads the business rules about four times and writes about 14 queries, fresh each morning. Nobody watches it at nine, and the people who read the result didn't ask the question. That makes it the next one to become a business tool, with the SQL written once and checked by someone who knows the answer. The more automatic the delivery, the more of the meaning has to be written down first.

Where I still draw the line

I wouldn't use this for financial accounting or IFRS reporting yet. There every detail matters, and a 95% answer is a wrong answer. Leave that to the ledger reports and the closing process.

Tristan Handy of dbt Labs put the split well at the same debate. Ad-hoc analysis dashboards: "I think that part is largely going away." And for the low-stakes question, the person asking is "fully responsible for their answer."

History is the other limit. A source system knows what an order looks like now, not always what it looked like on the last day of March. When the question is about how something changed, a data warehouse that kept the snapshots still earns its place.

How I'd start

Read-only, enforced in more than one place. A read-only connection, a list of the libraries or schemas the agent may touch, and a query timeout on the server.
One system, one person's questions. Pick the function lead with the longest list of unanswered questions.
Write the rules down with the people who own the numbers. Start with the deleted flags and the status codes.
Log why each query was made. Reading the intents tells you which questions repeat, and those become business tools.
Schedule only what has a business tool behind it. A routine that writes its own SQL has nobody watching when it runs.

The data warehouse, shrunk

The finance lead's question still needs someone to know which payments count since the last bank day, that a free-of-charge line doesn't add to the invoice total, and that a deleted row is still in the table. That knowledge used to be poured into a data warehouse, a cube and a few years of ETL. Now it fits in a document a person can read in one sitting, and an agent reads before every query.

The plumbing got cheap. The meaning didn't. It just got smaller, and easier to keep honest.

The data warehouse shrinks to a document

Built for the questions someone predicted

Five weeks of questions

Plausible and wrong

What the data warehouse was really for

The document

Where I still draw the line

How I'd start

The data warehouse, shrunk

Links

More from the blog

In open source, the code is the cheap part

We still price software with a pre-agentic cost model

AI sessions are contractors. Always-on agents are hires.