The next reader of your data is not a person.
For forty years, data systems have been built around one kind of reader: a person at a desk, asking one question at a time. Every warehouse, every query planner and every dashboard quietly assumes that pace. A few questions an hour, a report every morning, time to think in between.
That reader now has company. Agents don’t ask a question; they ask four hundred, in parallel, then four hundred more based on what came back. They don’t wait for the morning report and they don’t stop for lunch. And they are only getting started.
Brewric is working on what they will need underneath them.
A different kind of reader
An analyst asks a question and reads the answer. An agent asks a question, reads the answer, asks six more and hands the results to three other agents, who start asking their own. One task can fan out into hundreds of queries in a few seconds.
Most of those queries want the same thing. Different agents, different words, the same tables underneath. When people ran ten queries a day, reading the same files twice was a rounding error. When agents run ten thousand an hour, it is the bill. The disks and the network give out long before the models do.
And the data won’t hold still. New rows land every few seconds while the agents are mid-thought. If step one of a plan reads one version of the world and step four reads another, the plan quietly falls apart. A swarm of agents needs something no analyst ever asked for: that all of them, at once, see the same moment in time.
The bytes converged. The engines didn’t.
Something settled in the last few years. After a long fight over how tables should be stored, one open format won, and every serious engine now reads and writes it. For the first time, the bytes don’t belong to whoever computes on them.
Compute went the other way. Ask a serious data team how many engines they run and the answer is rarely one. A self-run open-source cluster for the heavy lifting. A lakehouse platform for the notebooks. A cloud warehouse, because finance got there first. Something federated to stitch it all together. The teams building the most advanced AI are no exception. None of it is an accident: each engine is the best at something, and adding one is always easier than removing one.
So one table now lives under four roofs, with four catalogs, four permission models and four opinions about what is current. Every engine sees its own piece. Nothing sees the whole, and the agents arriving on top can’t tell the difference.
Everyone builds their own
Software got cheap to write. Teams that used to buy tools now assemble their own, on open frameworks they can read, fork and bend. And the first thing every company wants to build is an agent of its own: one that knows its business, its tables and its words.
Every one of those agents hits the same wall, and it isn’t intelligence. It is context. What does this column actually mean? Which of these three tables is the real one? What did “active customer” mean last quarter, and who changed it? It is why context and semantics have become the words everyone in data is saying.
There is a trap inside the same trend. If software is cheap to write, it is cheap to copy. A nicer interface over metadata, a dashboard for your catalog, a hosted wrapper around open parts: each will have an open-source twin within a year. Whatever lasts here can’t be only software. It has to be a position, and what accumulates there.
Meaning lives below the dashboard
Meaning used to live in BI tools. Someone defined revenue inside a dashboard, and everyone downstream trusted the number. Agents don’t open dashboards. They go straight to the tables, and the definition never makes the trip.
- typedecimal(18, 2)
- nulls0.4%
- refreshedevery 4 min
- ownerleft in March
- defined ina dashboard nobody opens
- meaningnot recorded
So meaning has to move down, to the one place every question passes through. There it doesn’t have to be declared once, by someone who has since left; it can be learned, continuously, from how the data is actually used. Ten thousand queries say more about a column than its name ever will.
That place, in the path of everything written and everything asked, is also the only place governance can truly be enforced. You can’t route around what everything routes through.
Routing, not choosing
The last two years taught us something about models: no single one is best at everything, so you route. Each prompt goes where it is served best, cheapest or fastest. Questions about data deserve the same idea. One engine is cheap for wide scans, another is fast at joins, another holds the governed copy, another has accelerators sitting idle at night.
An agent shouldn’t need to know any of that. It should ask, and something underneath should decide where: which engine, which snapshot, and whether the answer already exists because another agent asked nearly the same thing a moment ago.
Read once, answer many
Once questions flow through one place, the expensive part, reading the bytes, can be shared. Overlapping questions against the same snapshot can be answered from a single read. Aggregates can be built once, at the level of the whole estate rather than one file or one cluster, and served to everyone who needs them, even across engines that have never spoken to each other.
The hardware is arriving too. Chips built to train models turn out to be remarkably good at chewing through columns of data. Used well, they make one shared read faster than the hundred private ones it replaces.
The one that remembers
In the end, the agent that remembers the most will win. Not chat history: institutional memory. Which joins work. Which tables lie. What the board meant by “active” last quarter. Today almost all of it evaporates when a session ends, and tomorrow’s agent starts from zero.
Memory should live where the data lives: in open tables, versioned, governed and queryable, able to travel back in time like everything else in the lakehouse. Remembering shouldn’t be a feature of one model. It should be a property of the ground every model stands on.
And memory compounds. Every question asked through the same layer teaches it something: what gets asked together, what each column means, what is expensive and what can be shared. More agents make it smarter; a smarter layer brings more agents. It is the oldest moat there is, and the only kind that can’t be cloned from a repository.
Primitives, not platforms
Agents don’t click through interfaces. They need a handful of sharp things: a consistent snapshot, a shared read, a meaning, a memory, a route. Small enough to compose, deep enough to depend on.
The last era of data was won by platforms with beautiful screens. The next will be won underneath them, by whoever puts the right primitives in the path of every query. Done right, it gets better with every model release instead of obsolete: better models mean more agents asking more questions, and every question makes the ground beneath them worth more.
The last era of data was built for people who ask questions. The next is for things that never stop asking.
The shape of the bet
Brewric began as a list of convictions that wouldn’t leave us alone. Drawn together they make a shape, and every corner of it pushes the same way.
Write to us
We are early, and quiet on purpose. If you run more than one engine, are building agents on your own data, or simply see the same shape we do, we would like to hear from you.