Data Agents: Notes from the VLDB 2026 Panel
Data Agents: Rethinking Data Systems in the AI Agent Era
VLDB 2026 hosted a panel titled "Data Agents: Rethinking Data Systems in the AI Agent Era." The panel organized itself around four questions:
WHAT is a data agent? An interface, a coding agent, another X-DB — or a new paradigm?
WHY is it genuinely different? Better models, or new data-systems abstractions?
HOW will it reshape databases? What fades, what grows, what survives?
If we meet again at VLDB 2075, what will a data system look like?
These are my notes from the room. What follows is a summary of the discussion, not a set of conclusions — because the panel didn't reach many.
What is a data agent?
The panel opened with a poll. Which statement is closest to your view?
(a) A natural language interface to existing data systems
(b) A coding agent equipped with data tools and a semantic layer
(c) A new workload that calls for another specialized X-DB
(d) A fundamentally new data-systems paradigm
Most of the discussion that followed circled around one thing: the context layer, and the ambiguity it introduces.
The RDBMS world is deterministic. You send a query, you get a defined answer. Context-driven systems are not deterministic, and that ambiguity now propagates outward into applications, agents, and business processes. Everyone is trying to figure out how to manage it.
There's also a cost to pay. Producing good context means manually defining a semantic layer across all your data. That's a large, ongoing manual burden, and it sits on top of everything else.
Isn't NL2SQL solved?
Someone asked. In benchmarks, maybe. In the real world, not really.
Part of the reason is that a natural language problem doesn't cleanly translate into a SQL statement. It translates into a workflow: some SQL, some unstructured data processing, some Python, some LLM calls. That raises a harder question — what is the contract between the agent and the database? In the RDBMS era we had one, and it was clear. We don't have its replacement yet, and it isn't obvious who should own which layer.
Then there's efficiency
SQL people worry about this a lot, and reasonably so. Once a request spans SQL, scripts, unstructured data, and model calls:
Who owns end-to-end performance?
Who owns optimization when LLMs are in the plan?
Who owns it when unstructured data is in the plan?
And accuracy
Accuracy is a challenge — not just of final results, but of intermediate ones. Which led to an uncomfortable question: is a database even mandatory? Some agents are using files and grep. Grep doesn't scale, but it is easy and it works well enough on text. Orthodoxy doesn't have a great answer to that yet.
Whatever else changes, accuracy will keep being the thing application developers care most about.
An alternative interface
One idea worth flagging: instead of exposing the query as the API, decompose the database into a set of capabilities and operators, and expose those directly to LLM tool calling.
So the interface between the data agent, the LLM, and the database is still up for grabs.
The self-driving car analogy
It came up, and it holds up well. Autonomous vehicles forced us to define levels of autonomy and to sort out legal responsibility for actions taken by the machine. Data agents need the same: read and write capability, with constraints, at defined levels of autonomy.
Search deserves a similar look. The fact that agents reach for grep on text tells you the problem isn't depth of functionality — it's ease of use and the ubiquity of the tooling. Unstructured data management, processing, and interface remain open. We need to converge on an interface.
Why is it different?
The second poll proposed a formula:
data agent = coding agent + data tool infrastructure + semantic layer
Is that all we need? And if not, is the gap in the models, the tools, or the data layer?
The conversation went straight back to converged processing — a single language and interface spanning structured and unstructured data.
Beyond that, a few concrete gaps surfaced.
We don't know what the application actually wants. For each natural language or SQL query, the system needs better information about the goal, so it can deliver results at the appropriate level of accuracy. This is a good moment to reopen the approximate query processing literature and take a fresh look. We also need to know how much expense the application is willing to tolerate.
Agents waste a lot. A significant number of agent-issued queries get killed outright. That's pure waste.
Agents abuse transactions. They start many transactions that get aborted before commit. They appear to be experimenting inside "private transactions" — trying a set of changes, then discarding most or all of them based on what the next step decides.
Data selection is unsolved. Determining which data to use to answer a question is still an open problem.
Put together, the useful unit isn't a query — it's a triple: (accuracy, performance, expense). Knowing that triple for a given question is what should determine the execution plan and the resources allocated to it. And "cost" here isn't just database or data processing cost. LLM cost and LLM latency belong in the same budget.
How will it reshape databases?
The third question: another X-DB, or a new organism? By 2030, will a database still be recognizable as a database?
Two futures were on the table. Either databases fragment further into multiple specialized systems, or they metamorphose into an "Agentic Data System" built for the agentic workload.
Agents are a disruptive technology. They arrive with different personalities and preferences, and they'll keep changing. The open question is how databases should evolve — or metamorphose — to meet them.
Hardware efficiency is one of the sharp edges. Handling millions of tables and trillions of rows efficiently matters more now, because agents have become accustomed to reading and writing enormous amounts of data simply to simulate scenarios — not to execute a predefined business process. This is the cost of branching: many branches get explored, and few survive, if any.
Transactional support needs rethinking. Nested transactions. Compensating transactions. Transactions that span a conversation. And one requirement that runs through all of it: a transaction is always executed on behalf of another identity, so end-to-end accountability has to hold.
2030 and beyond
The panel's last question looked all the way out to VLDB 2075, but the discussion kept landing on 2030.
"One size fits none," or "one data platform includes all capabilities"? The second image shows the alternatives, a bit more graphically.
Only time will tell.
------Raw Notes
VLDB 2026 had a panel on "Data Agents: Rethinking Data Systems in the AI Agent Era". The four main questions where: 01 WHAT:What is a data agent? Interface, coding agent, X-DB -- or a new paradigm? 02 WHY: Why is it genuinely different? Better models -- or new data systems abstractions? 03 HOW: How will it reshape databases? What fades, what grows, and what survives? 04 If we meet again in VLDB 2075, what will a data system look like? WHAT PROBLEM: Q1: A Data Agent is: Which statement is closes to your view? a) a natural language interface to existing data systems b) a coding agent equipped with data tools and a semantic layer c) a new workload that calls for another specialized X-DB 4) a fundamentally new data-systems paradigm Discussion (what I remember): Everyone is trying to figure out the context layer and how to deal with the ambiguity created by the context (as opposed to the deterministic RDBMS world). Dealing with this ambiguity is creating challenges to apps, agents and business processes. There's a huge burden of manually defining the semantic layer for all the data so the systems generate better context. This is a big overhead. Isn't NL2SQL a solved problem? (Keshav: not really in the real world!). What's the boundary between the agents and the database? What's the contract (like we had in the RDBMS)? The agents get a NL problem.. that doesn't get translated into a SQL easily, but to a workflow that's a combination of SQL, unstructured data processing, python scripts, LLM calls. Who should own which layer? On top of all that, what about the efficiency? SQL people worry about this a lot. Who owns the end-to-end performance? Who owns the optimization and performance when LLMs are involved? When unstructured data is involved? Result accuracy (even intermediate ones) is a challenge? Is database mandatory? Some are using files and grep? While the grep isn't scalable, it's easy to use on text. What's the answer from orthodoxy? Accuracy will continue to be a big deal for app developers. Other idea is to decompose the database into set of capabilities/operators and expose them to the LLM tool calling directly (instead of query as the API). So, eventually, the interface between the data agent to the database, LLM and database is still up for grabs. Self driving car is a good analogy for data agents. We've to deal with different levels of anatomy, legal responsibility for actions. Similarly, data agents should be able to read and write - with constraints and different levels of autonomy. Search is another big problem. Data agent's use of grep on text data shows the problem isn't just the depth of functionality, but ease of use and ubiquity of available tooling. Unstructured data management processing and interface is still an open issue. We need to converge on the interface. WHY PROBLEM: Q2: Are the following all we need for data agent? If not, is the gap in the models, tools or data layers? data agent = coding agent + data tool infra + semantic layer Is this is all? Data agent = Coding + Data Tool agent + Semantic layer Back to issues with converged processing/language/interface for structured and unstructured data. We need better information on the goals of the app for each NL/SQL query so the system can generate results with different levels of accuracy. May be we need to reopen up all those AQP papers and take a fresh look. We also need the info on level of expense that app is willing to tolerate. Significant number of queries from the agents get KILLED. Lot of wastage. Agents also start many many transactions that get aborted even before the commit stage. They seem to be experimenting with a lot of changes in their "private transactions" and ultimately aborting most/all of them depending on the next step decision. Determining what data to use to answer the question is still an open problem. Knowing the combination of (accuracy, performance, expense) for question is important. This will determine the execution plan and resources allocated for it. And the cost is not just database or data processing cost. Cost and latencies of LLMs should be considered as well. HOW problem: Q3: Another X-DB or a new organism? By 2030, will the database still be recognizable as a database? Will it the databases evolve to multiple specialized databases or will the databases metamorphasize to an "Agentic Data System" to handle the agentic workload? agents are distruptive technologies... They'll have to have and adapt to various personalities and preferences. The question is how should the databases evolve or metamorphasize to meet the needs of data agents? One key issue is using the hardware efficiently to handle millions of tables and trillions of rows. The data agents have become used to reading, writing a lot of data just to simulate scenarios, and not just executing a predefined business process. These are all result of branching -- many branches to explore, just a few survive, if at all. Need to look at the transactional support needed for agents. E.g. nested transactions, compansating transactions, transactions within conversations, etc. Transacations are always execute on behalf of another identity -- need to ensure end to end accountability. 2030 Databases: What's next? Will it be "One size fits none" or "one data platform includes all capabilities"? Only the time will tell.
Comments
Post a Comment