The lakehouse organized data for analysts. Nobody has organized it for agents.

Every data warehousing or data lake / lakehouse technology you have ever used was designed with a human at the end of the pipe.

Not always at the keyboard, and often behind a dashboard, a BI tool, or a Jupyter notebook — but always, ultimately, a person. The schema was authored by a person, for a person. A data engineer sat down, thought about the questions the business would ask, and encoded those questions into tables, models, and marts. Then analysts consumed what was pre-built. The entire modern data stack — warehouses, lakehouses, dbt, catalogs, semantic layers — is a decade of brilliant work resting on one unexamined assumption: a human decides the shape of the data, ahead of time, and a human reads the result.

That assumption held for fifty years.

It is quietly breaking right now, and most of the industry hasn't noticed yet.

What the lakehouse actually solved

It's worth being precise about what the last paradigm shift achieved, because the next one rhymes with it.

Before the lakehouse, you picked a failure mode. You could keep everything raw in a data lake — lossless, cheap, and unusable, a swamp nobody could query. Or you could model everything into a warehouse — organized, fast, and lossy, with the original data discarded or stranded upstream. Fidelity or structure. You simply had to pick one.

The lakehouse's real contribution wasn't a table format. It was a discipline that refused the trade-off: keep the raw data forever, add structure on top of it, build purpose-shaped views above that, and bind the whole thing together with a catalog, lineage, and schema enforcement. Transformations became additions rather than replacements. The original was always still there.

That discipline standardized how an entire industry serves data to its consumer. But look at who that consumer is. The transformation is shaped like the analyst's questions. The catalog is browsed by data engineers. The models are authored in dbt by people who interview stakeholders, guess at future questions, and ship schemas on a quarterly cadence. The lakehouse is a magnificent machine for serving humans — humans who ask questions slowly, in batches, in ways you can anticipate.

The consumer just changed

Production AI agents are a genuinely new kind of data consumer, and they violate every assumption the human-oriented stack encodes.

An agent doesn't ask questions on a quarterly planning cycle. It asks them mid-incident, mid-conversation, mid-task — and the questions it needs answered next week are ones nobody could list this week. An agent doesn't want a star schema optimized for GROUP BY across a billion rows; it wants everything that happened to this entity, in order, in the last thirty minutes. Keyed, windowed, time-ordered slices — a read pattern OLAP engines are actively bad at. And an agent doesn't sit politely on the other side of a dashboard. It acts. Which means it also needs to be told when something changes, not just answered when it asks. Every warehouse, lakehouse, and vector store ever built is pull-only. The consumer who needs push has arrived, and the shelf is empty.

Watch what teams building production agents do today and you can see the mismatch playing out. The agent wraps six systems in six tools, calls them one at a time, and joins the results in its own reasoning loop — adding latency and burning tokens doing the job a data layer should have done before it asked. Or someone runs an LLM over the incoming data to distill it into "memories" and knowledge graphs, recreating the pre-lakehouse failure mode — lossy-but-organized — except now the lossiness includes hallucination. We are watching the industry re-learn, at agent speed, the exact lesson the lakehouse taught: fidelity and structure are not opposites. They're a discipline.

The deeper break: who authors the model

But there's a second assumption underneath the first, and it's the one I think actually defines the next decade.

In the classical stack, the data model is authored ahead of the consumer. Human writes schema → dbt builds models → analyst reads what exists. This works because human consumers are slow and predictable. You can interview them. You can anticipate their questions. The model evolves on the timescale of sprint planning.

Agents invert this. An agent discovers, at runtime, that it needs a shape nobody predicted — a 24-hour timeline of events for a customer, keyed by tenant, filtered to errors. In the current world, that need dies as an awkward chain of tool calls, re-executed from scratch on every run. In the world I think we're heading toward, the agent proposes the shape, and the store materializes it.

Call it the agent-defined data model. The agent introspects a catalog to see what context already exists. It asks for a derivation it needs and gets back a named, persistent, reusable view that other agents can discover too. Views that agents keep hitting get optimized and kept fresh; views nobody calls get deprecated. The data model stops being a quarterly artifact authored by people guessing at questions and becomes a living structure shaped by the actual read patterns of the actual consumers.

What has to stay human

If that sounds like chaos — agents mutating schemas in production — the objection is fair, and the answer is the same one the lakehouse gave: discipline, not vibes.

The raw layer stays immutable and lossless; agent-shaped views are derivations on top, never rewrites. Lineage records exactly which raw records produced which view, so every derived shape is auditable and rebuildable. Humans keep governance: they can pin views, review proposals, set retention, and roll anything back. Nothing about agent authorship requires giving up the audit trail; it requires extending it. The catalog becomes bidirectional: humans read and govern it; agents read and extend it.

That's not a loss of control. It's the same bargain the lakehouse struck — freedom above, guarantees below — just extended to a new author.

The rhyme

Here is the pattern worth sitting with. Roughly once a decade, the primary consumer of operational data changes, and the data layer reorganizes around them. Applications have databases. Analysts got the warehouse, then the lakehouse. Each shift looked, from inside the previous paradigm, like an unnecessary complication — until it was obviously the only sensible architecture.

Agents are the next consumer. They read differently (keyed, windowed, in-order), they consume differently (pull and push), and — the new part — they can participate in shaping the model itself. The stack that serves them won't be a warehouse with an AI feature bolted on, because the break isn't at the query layer. It's at the authorship layer, and that's a write-time assumption buried in the foundations of every system built for the previous consumer.

The lakehouse gave analysts a data layer with fidelity, structure, and governance. Agents deserve the same, plus the one thing analysts never needed: a seat at the table when the model gets written.

The only open question is what that new layer will look like — and who it will hold the pen to write it.

---

I'm building NavFlow — the data plane production agents read from and get triggered by. If you're running agents against real systems and feeling this gap, I'd genuinely like to compare notes: cal.com/ashishbagri/navflow.