To Every Agent Its Own Database - Joe Reis

Joe Reis

SubscribeSign in

To Every Agent Its Own Database<br>A Working Reference Architecture for Agent-Native Analytical Exchange

Joe Reis<br>Jul 21, 2026

62

10

Share

Everyone is trying to make the data warehouse ready for agents. I think that starts from the wrong end of the architecture, so I inverted the problem and built the opposite in working code. I’ve been sitting on this for a bit, as I’ve been hyper-focused on my book (and course) on Mixed Model Arts. But I figured I’ll give a taste of a side quest I’m actively working on. More to come soon.<br>A couple of months ago at AI Council, my friend Hannes Mühleisen, co-creator of DuckDB, unveiled Quack, DuckDB’s client-server protocol. A week or so later, he gave a lunch-and-learn to my community and went deeper into what Quack could do.<br>The next morning, I woke up at 5 a.m. with an idea I had probably been working through in my sleep. I recall a hazy dream of me and my friends Bill Inmon, Zhamak Dehghani, and Hannes hanging out. Their influence on my idea will become more obvious as you read on.<br>Most companies are preparing their data platforms for agents by adding larger clusters, more replicas, faster semantic layers, stronger workload controls, and new interfaces around the same central analytical systems. That may work, especially because modern warehouses already provide admission control, workload isolation, resource groups, and quotas. But it still assumes that an agent should behave like a very fast analyst connecting to a shared platform.<br>I wanted to test a different model. Instead of routing every agent through the same analytical plane, I gave each agent its own embedded analytical engine and allowed agents to exchange data products directly.<br>What started as a prototype using DuckDB, DuckLake, Quack, and Malloy led to a broader question: what kinds of contracts are required when agents exchange analytical data without relying on one central semantic and computational authority?<br>The Warehouse Was Designed Around Different Workload Assumptions

My good friend Bill Inmon, widely known as the father of the data warehouse, helped formalize and popularize the architecture when organizations needed to separate operational workloads from integrated analytical workloads. The architecture obviously worked, with data warehouses becoming the central place where organizations could integrate, historize, govern, and query data from many operational systems. The term is now so commonplace that it is easy to forget that the design was once controversial (Bill has some real war stories here).<br>Much of the traditional warehouse (and lakehouse) operating model has been organized around human-paced analytical consumption: scheduled reports, dashboards, exploratory queries, and downstream processes that people eventually inspect or govern.<br>A human may run a query, inspect the result, and notice that something looks wrong. If revenue drops 40% overnight, someone will often stop and ask whether the business changed or whether the data is broken. Humans also carry implicit context from meetings, documents, Slack conversations, spreadsheets, and prior analysis.<br>Agents create a different workload. They can be numerous, highly concurrent, and prone to fan-out. One request may trigger several agents, each of which creates additional work. Their outputs can be passed into downstream computations within milliseconds, leaving little time for anyone to inspect intermediate results.<br>Agents also cannot be expected to infer freshness, semantic intent, or abnormality unless those requirements are represented explicitly. A human analyst may know that “revenue” means revenue net of refunds because someone from accounting clarified it during a meeting. An agent may have access to portions of that context, but it cannot be relied upon to recover and apply the same institutional knowledge consistently.<br>This creates several architectural pressures:<br>higher query concurrency,

speculative and redundant work,

rapid chaining of intermediate results,

faster propagation of errors,

and stronger requirements for machine-checkable semantics, provenance, freshness, and trust.

A centralized system can be scaled to accommodate much of this. However, without strict workload isolation, speculative agent traffic can interfere with other users. Semantic definitions can drift from their implementations, and governance processes designed around human review may not operate at the same speed as autonomous data exchanges.<br>Last year’s Supporting our AI Overlords paper describes several of these workload characteristics, including high throughput, heterogeneity, redundancy, and steerability. My architecture is not the design proposed in that paper, but it responds to a similar change in workload assumptions.<br>Instead of concentrating more agent activity around a shared analytical system, I tested what happens when analytical state and computation move toward...