There's still no free lunch in data analytics | Cassis<br>Skip to content Product<br>Blog<br>Docs

Try for free

Talk to us

Back to stories<br>There's still no free lunch in data analytics<br>AI agents don't remove the human cost of making data useful. They redistribute it.

Matthieu Blandineau May 14, 2026

On this page

Summary

The human economy of retrieval<br>How data systems have always distributed costSlack the data team<br>Write the SQL yourself<br>Pre-built dashboards<br>Self-service BI<br>Spreadsheets<br>Data catalog<br>Code-defined semantic layers<br>Where the cost lands

Deciding where to pay<br>What AI agents changeOn the querying side: a step change<br>On the indexing side: the requirements go up<br>The reliability question<br>Agents redistribute cost, they don’t remove it

The real bottleneck is semantic coordination<br>Every time someone in your company needs an answer from data, someone pays a human cost: the time, judgment, and design work to make the information findable, trustworthy, and usable. This has been true since the first analyst opened a SQL editor. Dashboards, data catalogs, semantic layers: these are all different bets on where to concentrate that effort. AI agents are the latest bet. They shift where the cost lands, but they don’t remove it.

In this post, we’ll map how this cost is distributed across the systems data teams already use, and then look at what AI agents actually change about the equation.

The human economy of retrieval

This cost can be paid in different ways. A classic framework for thinking about it is schema-on-write vs. schema-on-read. As Hrishi Olickel elegantly put it, think of schema-on-write as putting clothes straight into the wardrobe, sorted by function, and schema-on-read as sorting through a messy pile when you need something. The choice decides whether you pay upfront or at retrieval.

This illustrates that any system distributes its cost between upfront effort and usage effort. For analytics, we can break this down into three dimensions:

Indexing cost: the upfront effort to prepare, structure, and organize information so it can be found later. Designing schemas, writing metric definitions, building dashboards, documenting business logic. This includes the part nobody budgets for: getting four teams to agree on what “active customer” means.

Querying cost: the effort at the moment of retrieval. Browsing a wiki, writing SQL, crafting a prompt, or Slacking the data team.

Reliability: the trustworthiness of what comes back. A number can be technically correct (the SQL ran) but semantically wrong (it used the wrong definition of “active customer”).

Different systems distribute these three costs differently.

Let’s make this concrete. A CFO wants to know how many active enterprise customers renewed last quarter. Before anyone can answer, someone needs to decide which table holds customer data, what “active” means (last login? contract status? usage threshold?), what counts as “enterprise” (revenue band? employee count? plan tier?), and what date range defines “last quarter” in your fiscal calendar. Every system below handles this CFO’s question differently. The question is who does the thinking, and when.

How data systems have always distributed cost

Before AI agents entered the picture, every data team already lived with some combination of the following systems. Each makes a different bet on where to concentrate human effort.

In practice, these systems aren’t mutually exclusive. Most data teams run several in parallel (dashboards for the board deck, self-serve for exploration, Slack for everything the dashboards don’t cover) and layered on top of each other (a semantic layer feeding a BI tool feeding a dashboard). We’ll discuss them separately to isolate the trade-offs, but a real setup is usually a combination.

Slack the data team

The CFO’s question goes to a senior data engineer, who drops what they’re doing, explores the warehouse, applies tribal knowledge about what “active customer” means in this context, and delivers an answer.

Indexing cost: minimal. The warehouse schema exists, the tables are there, but nobody has invested in making the answer to this specific question findable. No metric definition, no documented business logic for “active enterprise customer.”

Querying cost: close to zero for the CFO. But the cost doesn’t disappear. It lands entirely on the data team. Every question pays the full retrieval price from scratch. Nothing is recorded. When the same question comes back next quarter from a different stakeholder, the data engineer does the same work again.

Reliability: high, if you get the right person. The answer quality depends on which engineer picks up the question and whether they’re applying fresh logic or muscle memory from last time. But it doesn’t scale.

One senior data manager we spoke to described a weekly rotation where one person is dedicated to answering ad-hoc questions, consuming about 20% of a team of five or six people. Permanently.

The total cost of...