……民有、民治、民享的政府——亚伯拉罕·林肯,葛底斯堡演说(1863年)
人工智能的成本正在急剧下降。2023年初,GPT-4级别的能力每百万token成本约为30美元;如今同样的能力已降至1美元以下,部分供应商甚至将成本压至0.10美元以下。从各项基准测试来看,推理价格每年下降9倍至900倍不等,中位数降幅接近50倍。即便是前沿模型,每一代的价格也在大幅降低,开源模型紧随其后。关键在于,即便“诺贝尔奖级天才水平”的智能尚未到来,但足以胜任绝大多数知识工作的智能已经存在,并且每月都在变得更便宜。按照这个速度,我们很快将进入近乎免费的智能时代——这种智能对于日常知识工作来说绰绰有余。
声明:本文由加州大学伯克利分校电气工程与计算机科学系副教授、EPIC数据实验室联合主任Aditya G. Parameswaran及其合作者主导撰写。本文兼具领域综述与观点探讨性质,下文讨论的若干研究方向(包括智能体推测、结构化记忆以及从零开始合成定制数据系统)均基于作者自身正在进行的工作。
那么,这个近乎免费的智能新时代对数据系统意味着什么?我们认为,近乎为零的推理成本将带来三个新的挑战——同时也是机遇:
面向智能体的数据系统。智能体很快将成为数据系统的主要工作负载——每个终端用户请求都会触发大量智能体集群被启动。考虑到智能体与人类(或代表人类执行任务的应用程序)在特性上的差异,我们应如何为这类智能体用户重新设计数据系统?
智能体构成的数据系统。随着智能体开始承担大部分知识工作,我们需要一种新的基础架构,让数千个智能体能够管理长期运行任务的状态、进行协调并达成共识,以及处理故障。能够可靠且高效地运行和管理智能体集群的数据系统应该是什么样?
由智能体构建的数据系统。智能体正迅速变得能够一次性合成完整的数据系统——这意味着我们可以为每个新工作负载重建定制系统。验证此类系统是否符合预期行为是一项挑战。要让智能体构建出我们真正可以信赖的数据系统,需要具备哪些条件?
为智能体构建的数据系统、基于智能体的数据系统,以及由智能体构建的数据系统
接下来,我们将逐一详细讨论上述内容,随后探讨数据系统与智能体相互交织的未来,尤其是当这三项挑战相互叠加时的情况。
为智能体构建的数据系统
智能体查询数据库的行为与人类或商业智能工具不同。它会执行我们称之为“智能体推测”的操作:一种高容量、异构的工作流,涵盖模式自省、列式探索、部分查询公式化再到完整查询公式化。当多个智能体各自探索假设空间的不同部分时,每个用户请求可能相当于数千条独立的 SQL 查询。现在,用户可以提出“高层级”的数据任务,例如根因分析——比如“为什么今年伯克利的咖啡销量下降了”——或探索性群体分析——比如“哪些用户群体在下个季度最有可能流失”——每一项都涉及潜在的连接、聚合和筛选组合的组合空间。
重新设计以更有效支持智能体推测的数据系统
来自这些智能体的请求存在多种优化机会。例如,在一个文本转 SQL 的基准测试中,当多个智能体尝试完成同一任务时,只有 10-20% 的子计划是互不相同的。因此,80-90% 的子查询执行的是重复工作。同样的实验表明,随着智能体尝试次数的增加,任务成功率显著提升——因此这种冗余实际上是有益的。但从数据系统的角度来看,这却是浪费的工作。
一个以智能体为先的数据系统可以利用这些特性,帮助智能体更快地取得进展。它可以在重叠的子计划之间复用结果,借鉴数十年前关于多查询优化和共享扫描的研究成果。或者,数据系统可以尝试追求“满意解”,返回对智能体推进任务而言足够好的近似答案,这利用了近似查询处理(AQP)领域的研究成果——或者流式传输最终或中间操作符的结果,以帮助智能体判断查看剩余部分是否必要或有帮助。
这里的另一个机会是彻底重新思考查询接口:智能体不再是一次只提交一条 SQL 查询,而是可以提交一批查询,每条查询都有自己的近似要求。由于枚举指数级的搜索空间(如上述根因分析或队列分析示例中那样)并非智能体推理能力的最佳用途,或许数据系统应该支持更高级的原语,而不是要求智能体显式地列出每条 SQL 查询。一个想法是借鉴 DBT 风格的 Jinja 宏,为智能体提供基于循环的原语,以便它们与数据系统交互。
一支充满干劲的智能体大军,随时准备不知疲倦地完成你的数据任务。
最后一个机会是,不再将数据系统视为被动的查询执行者;数据系统可以变得主动,因为它们对数据和系统特性拥有更深入的了解,而这些是智能体可能事先不具备的——它们可以引导智能体走向不同的方向,提供相关查询的结果,并给出性能层面的反馈(例如,系统可以先向智能体提供延迟估算,而不是直接执行一个昂贵的查询)。我们之所以现在能做到这一点,而过去不行,是因为智能体可以接受任何形式的文本反馈,而不期望严格的 SQL 查询结果。事实上,数据系统还可以提前为智能体准备好物化视图和虚拟视图,并将其作为上下文的一部分提供给智能体,因为这可能比让智能体自行编写或使用这些视图更廉价或更高效。
智能体的数据系统
此前,我们重点关注了智能体如何与数据系统交互。现在,我们来考虑智能体持续工作所需的其他一切要素:它们驻留在何处、如何记忆、如何相互协调,以及如何处理彼此的故障。这种智能体基础层与驱动原始智能的推理栈是分开的。然而,推理栈本身正通过 API(例如来自 OpenAI 或 Anthropic 的 API)被抽象化,或者对于开放权重模型而言,则通过隐藏底层细节的服务框架来实现抽象化。到目前为止,智能体基础层一直通过诸如 Claude Code 和 Codex 之类的工具,结合各种存储和检索记忆的机制来进行管理。
首先,在记忆方面,当前的共识是文件即一切;智能体写入非结构化的 Markdown(MD)文件,然后可以通过 grep 或基于嵌入向量的检索来搜索这些文件。事实上,许多人认为,持续学习的解决方案在于让智能体摄入大量信息(例如,整个代码库、Slack 消息、公司维基等),然后将它们的学习成果写入 MD 文件,再根据需要选择性检索这些文件。确实,文件系统、Bash 脚本和 MD 文件现在乃至将来对智能体都仍然重要。然而,在规模化场景下,当智能体承担绝大多数知识工作时,这种方法将不再有效。
鉴于上下文窗口有限,检索所有可能相关的 MD 文件片段并将其塞入上下文的做法,终将难以为继。即使上下文窗口持续增长,不将所有信息放入上下文也有延迟方面的好处——而且在许多情况下,例如当知识工作涉及与大型数据库或代码库交互时,将所有相关数据序列化到上下文中是不可行的。
数据系统作为多智能体集群的基础层
可以使用知识图谱表示,但知识图谱同样受限于非结构化基于记忆的存储方式,因为它们缺乏结构化搜索能力。真正需要的是能够跨多个相关属性(或维度)仅检索与任务相关的记忆。例如,一个调试不稳定测试的智能体应该能够只提取标记了相关模块、语言、框架和故障模式的记忆——而不是基于关键词或嵌入向量相似度进行检索。另一个问题是实际检索什么内容;包含错误的原始智能体轨迹用处不大,因为它们会导致智能体重复同样的错误——相反,我们希望检索到的记忆具有纠正性。
我们最近探索了一种相关的结构化记忆概念,将记忆按多个属性进行组织,每个属性可以设置为 * 表示通用适用,或设置为待匹配的值列表。对于数据智能体而言,维度可以包括列和表、操作类型,以及最终的自由文本纠正指令。因此,我们可以加入仅适用于特定操作类型的记忆(例如"执行日期时间操作时,使用财年而非日历年惯例"),或仅适用于特定表的记忆(例如"查询产品名称时,优先使用 product_cleaned 列而非 product 列")。一个待解决的问题是定义特定于应用的结构化记忆——也就是其他人所说的记忆世界模型。我们认为这类似于为每个应用定义模式——也许智能体本身可以帮助我们随时间推移定义并优化它。
存储和检索结构化知识的一种可能方式 [来源链接]
结构化记忆对于进化框架有效管理搜索空间也很有用。事实上,存储、结构化和挖掘大量单智能体和多智能体轨迹,可以帮助未来的智能体变得更加高效——可能通过基于结构化记忆的机制实现有效的递归自我改进。
另一个挑战是,当有众多智能体同时执行变换时,如何支持对共享内存的并发编辑,以及更广义上的并发编辑。尽管已有一些关于支持多版本和写时复制语义的有益尝试,但当数千个智能体同时试图编辑共享状态时,这些技术是否足够有效尚不明确。例如,当智能体针对用户请求尝试各种潜在事务时,其中绝大多数事务的效果需要被回滚——只有那个“正确”事务的结果得以保留。支持恰好一次语义的相关工作在此具有参考价值,基于 CRDT 和操作变换的底层技术也同样适用。对于记忆等模糊机制的更新,为了降低延迟,我们或许可以在一致性上做出牺牲,以换取完美的正确性。虽然智能体可以通过语义推理来补偿或回滚自身行为,从而最终完成大多数任务,但主要挑战在于它们在此过程中相互干扰的程度。需要避免的一个重要故障模式是一种“活锁”形式,即无休止的补偿行为阻碍了任何有意义的进展。
除了共享状态之外,在试图支持大规模智能体集群时还会出现其他问题,包括智能体失败时该如何处理、智能体之间应如何相互通信(直接通信还是通过中间共享状态),以及我们应如何处理掉队的智能体。在支持持久化多智能体执行方面已有一些进展,例如 Temporal,但此类解决方案能否在数千个智能体的规模下应用仍有待观察。在通信方面,我们需要能让智能体相互协商的机制。想象一下,四个开发智能体试图就一个共享模式达成共识,它们的目标各不相同但又相互重叠。在人类环境中,这需要反复讨论和妥协;而对于智能体集群,我们必须定义相应的机制,使它们能够收敛到一个能反映各自主体根本目标的设计上。或者,如果所有智能体都需要访问某种有限资源,那么通信同样是必要的。目前尚不清楚,通过集中式协调还是采用去中心化方法才是最佳方案。
智能体驱动的数据系统
最后,如果智能能力实际上是免费的,那么我们就可以利用这种智能从头合成新的数据系统。事实上,在许多场景中,通用型数据系统可能有些大材小用,因为它们必须支持所有模式、查询和硬件目标。针对给定的工作负载,包括 Bespoke OLAP 和 GenDB 在内的近期研究表明,可以使用智能体流水线在几分钟到几小时内、以几美元的成本合成一个完整的、针对特定工作负载的分析引擎。这些引擎是一次性的:当工作负载发生变化时,只需重新生成即可。类似地,我们的工作表明,可以针对特定工作负载从头合成自定义的键值存储。事实上,像 Kiro 这样的现代 IDE 已将系统开发的规范提升为一等公民。
智能体可以从头合成自定义数据系统
然而,主要问题在于,规格说明通常并不完美,无法覆盖所有边界情况。当前的智能体会利用缺失的规格说明,通过奖励黑客手段来获得高绩效指标。在我们自定义的键值存储工作中,我们发现缓解这一问题的一种方法是,让辅助验证智能体尝试生成能够捕捉到边界情况被利用的测试用例,从而实质上扩展规格说明。另一种方法是同时生成一个系统及其正确性证明,我们在这方面已取得一些初步成功,但还需要更多工作来巩固这一方法。此外,征求人类为系统编写规格说明的最佳方式仍有待探索——能否以迭代式、人在回路中的方式进行,而非一次性、不完整的方式?事实上,即使是手动编写的软件,人类编写的规格说明也是不完整的,因此可以预期,未来更对齐的智能体在设计决策时将越来越多地运用更优的判断力。
一种可能的数据系统合成流程 [来源链接]
这里涉及的其他问题包括,测试从一个成熟的系统(例如 Postgres)出发,移除组件/功能,是否能够带来更高的性能或更多的用户信任。另外,是否存在机会使设计可组合,包含各种经过验证的组件,并根据工作负载进行混合搭配?例如,也许工作负载的变化还不足以需要更新存储层,但查询优化器可能需要修改。一个可能更可行的方案是,将智能体与证明系统结合,针对与形式化证明相关的代码关键部分进行工作,而不是对整个系统都这样做。
最后一个机会是摆脱传统数据系统栈中那些接口定义明确(例如解析器、查询优化器、存储管理器……)的组件——这些组件以往很大程度上由单个人类团队全权管理。取而代之的是,智能体可以找到将这些组件“融合”在一起的新方法,或许由此发现新的优化机会。智能体还可以填补功能上的空白,使现有系统功能更加完备,或达到与其他竞争系统同等的功能水平——或者类似地,根据功能请求或问题(或许是由其他智能体提交的!)持续改进开源系统。如何以优先考虑正确性、长期维护和人类可解释性的方式来实现这一点,将是一个挑战。
展望更远的未来
在智能近乎免费的时代,数据系统比以往任何时候都更加重要。随着智能体承担起知识工作的主要部分,数据系统的工作负载将发生变化,它们运行所需的底层基础设施必须被构建出来,并且它们将越来越多地参与到自身的设计中。这些转变中的每一个都开辟了一个令人兴奋的新研究方向。
数据系统与智能体的协同进化
放眼更远的未来,智能体与数据系统之间的界限可能会开始模糊。例如,智能体可以设计它们自身运行所依赖的数据系统,同时定义接口以及底层的系统组件。接口和内部结构都可以由智能体以递归自我改进的形式随时间演化。还有一个机会是,将数据系统重新构想为所有相关状态的全局唯一真实来源:包括原始数据、记忆和协调状态,从而进一步消除被智能体查询的数据与智能体活动所产生数据之间的区别。最后,数据系统本身也可能融入智能体组件,从根本上从被动的计算引擎演变为智能、主动、自我优化的架构。未来会怎样,很难预测。我们即将迎来一场狂野的旅程!
致谢
本文所述的观点及正在进行的工作,是 EPIC 数据实验室、数据系统与基础研究组以及更广泛的伯克利 AI 系统社区众多优秀合作者共同研究与多次讨论的成果。感谢各位!
本文的 BibTex 引用格式:
@misc{intelligence-is-free-blog,
title={Intelligence is Free, Now What? Data Systems for, of, and by Agents},
author={Aditya G. Parameswaran and Shubham Agarwal and Kerem Akillioglu and Shreya Shankar
and Sepanta Zeighami and Rishabh Iyer and Matei Zaharia and Alvin Cheung
and Natacha Crooks and Joseph Gonzalez and Joseph Hellerstein and Ion Stoica},
howpublished={\url{https://bair.berkeley.edu/blog/2026/07/07/intelligence-is-free-now-what/}},
year={2026}
}
... government of the people, by the people, for the people ...
— Abraham Lincoln, Gettysburg Address (1863)
The cost of AI is dropping rapidly. GPT-4-class capabilities cost roughly $30 per million tokens in early 2023; today the same runs under $1, and some providers are pushing costs below $0.10. Across benchmarks, inference prices have fallen between 9x and 900x per year, with a median decline near 50x. Even frontier models are getting dramatically cheaper each generation, with open-source models following closely behind. And crucially, even if “Nobel-Prize-winning genius-level” intelligence isn’t here yet, the intelligence that suffices for the vast majority of knowledge work is here today, and getting cheaper by the month. At this rate, we are soon entering the era of virtually free intelligence—the kind that is more than enough for everyday knowledge work.
Disclosure: This post is a perspective led by Aditya G. Parameswaran—an Associate Professor of EECS and co-director of the EPIC Data Lab at UC Berkeley—together with his collaborators. It is part landscape survey and part perspective, and several of the research directions discussed below (including agentic speculation, structured memory, and synthesizing custom data systems from scratch) draw on the authors' own ongoing work.
So, what does this new era of near-free intelligence mean for data systems? We believe three new challenges—and opportunities—stem from near-zero inference costs:
Data Systems For Agents. Agents will soon become the dominant workload for data systems—with swarms of agents spun up in response to each end-user request. Given differences in characteristics between agents and humans—or applications acting on their behalf—how should we redesign data systems for such agentic users?
Data Systems Of Agents. As agents start taking on the bulk of knowledge work, a new substrate is needed for thousands of agents to manage state over long-running tasks, coordinate and reach consensus, and deal with failures. What do data systems that reliably and efficiently run and manage agent swarms look like?
Data Systems By Agents. Agents are rapidly becoming capable of synthesizing entire data systems in one go—meaning we can rebuild custom systems for each new workload. Verifying that such systems match intended behavior is a challenge. What does it take to let agents synthesize data systems we can actually trust?

Data Systems For, Of, and By Agents
Next, we will discuss each in more detail, followed by discussing the intertwined future of data systems and agents, especially as the three challenges intersect.
Data Systems For Agents
An agent querying a database doesn’t behave like a person or a BI tool. It performs what we call agentic speculation: a high-volume, heterogeneous stream of work spanning schema introspection, columnar exploration, partial and then full query formulation. With multiple agents each exploring portions of the hypothesis space, each user request could amount to 1000s of individual SQL queries. Now, users can issue ‘high-level’ data tasks, e.g., root-cause analysis—e.g., ‘why did coffee sales in Berkeley drop this year’—or exploratory cohort analysis—e.g., ‘which user segments are most likely to churn next quarter’—each involving a combinatorial space of potential joins, aggregations, and filter combinations.

Data Systems Redesigned to More Effectively Support Agentic Speculation
The requests from these agents have various opportunities for optimization. For instance, on a text-to-SQL benchmark with multiple agents attempting each task, only 10-20% of the sub-plans are distinct. Thus, 80-90% of sub-queries perform duplicate work. The same experiments show task success rates significantly increasing with more agentic attempts—so the redundancy is actually helpful. But from the data system perspective it’s wasted work.
An agent-first data system can exploit such properties to help agents make progress faster. It can reuse results across overlapping sub-plans, drawing on ideas from decades-old literature on multi-query optimization and shared scans. Or the data system can try to satisfice, returning approximate answers that are good enough for agents to make progress, leveraging work from the AQP literature—or streaming the results of the final or intermediate operators to help agents decide if seeing the rest is necessary or helpful.
Another opportunity here is to rethink the query interface entirely: instead of agents issuing a single SQL query at a time, they could instead issue a batch of queries, each with its own approximation requirements. Since enumerating an exponential search space (as in the root cause or cohort analysis examples above) isn’t a good use of agentic reasoning ability, perhaps data systems should support higher-level primitives rather than requiring agents to list each SQL query explicitly. One idea here is to draw on DBT-style Jinja macros to provide looping-based primitives for agents to interact with data systems.

A Caffeinated Army of Agents Ready to Tirelessly Complete Your Data Tasks
A final opportunity here is to stop thinking of data systems as passive executors of queries; data systems could be proactive, as they possess more grounding in data and system characteristics that agents may lack a priori—they could steer agents in different directions, provide results for related queries, and also provide performance-level feedback (e.g., instead of executing an expensive query, the system could first provide the agent a latency estimate). The reason we can do this now as opposed to the past is that an agent can accept any form of textual feedback and isn’t expecting a strict SQL query result. In fact, the data system could also prepare both materialized and virtual views for an agent in advance, provided to the agent as part of context, as this may be cheaper or more effective than having an agent author or use them.
Data Systems Of Agents
Previously, we focused on how agents interact with data systems. Now, we consider everything else agents need to keep working: where they live, how they remember, how they coordinate with each other, and how they deal with failures of each other. This agentic substrate is separate from the inference stack powering raw intelligence. However, the inference stack itself is being abstracted away through APIs (e.g., from OpenAI or Anthropic), or, for open-weight models, through serving frameworks that hide low-level details. So far, the agentic substrate has been managed through harnesses like Claude Code and Codex, coupled with various mechanisms to store and retrieve memory.
First, on the memory front, the current wisdom is that files are all you need; agents write to unstructured markdown (MD) files, which can then be searched using grep, or via embedding-based retrieval. In fact, many argue that the solution to continual learning is having agents consume a lot (e.g., an entire codebase, slack, company wikis, …) and then write their learnings into MD files, which are then retrieved selectively on demand. Indeed, file systems, bash scripting, and MD files are and will still be important for agents. However, at scale, when agents are doing the vast majority of knowledge work, this approach will no longer be effective.
Given limited context windows, retrieving all MD file fragments that may be relevant and stuffing it into the context will break down at some point. Even if context windows continue to grow, there are latency benefits to not put all information into context — and in many cases, e.g., when knowledge work involves interacting with large databases or code bases, it will be infeasible to serialize all relevant data into context.

Data Systems As A Substrate for Multi-Agent Swarms
One could use a knowledge graph representation, but knowledge graphs suffer from the same limitations as unstructured MD-based memory due to their lack of structured search. What one needs is to be able to retrieve only memory that is pertinent to the task, across multiple attributes (or facets) of interest. For example, an agent debugging a flaky test should be able to pull only the memories tagged with the relevant module, language, framework, and failure mode—rather retrieving based on keywords or embedding similarity. A separate issue is what to actually retrieve; raw agent traces with mistakes are not very useful as they will induce agents to repeat the same mistake—instead, we want the retrieved memory to be corrective.
We recently explored a related notion of structured memory, where we organize memory across various attributes, each of which could be set as * to indicate universal applicability, or set as a list of values to be matched. For a data agent, the dimensions could include the columns and tables, type of operation, and finally, open-ended natural-language corrective instructions. So, we could include memory that only applies to a given type of operation (e.g., ‘when performing date-time operations, use fiscal year as opposed to calendar year conventions’), or a given table (e.g., ‘column product_cleaned is preferred over column product when querying on product name’). One open question is defining an application-specific structured memory—or what others have called world models for memory. We believe this is akin to defining a schema for each application—and perhaps agents themselves can help us define and refine it over time.

One Possible Way To Store and Retrieve Structured Knowledge [From Here]
Structured memory will be useful also for evolutionary frameworks to effectively manage search spaces. Indeed, storing, structuring, and mining large volumes of single and multi-agent traces can help future agents become much more efficient—potentially enabling effective recursive self-improvement through structured memory-based mechanisms.
Another challenge is to support concurrent edits to shared memory, and concurrent edits in general, when there are many agents performing transformations. While there have been some useful attempts at supporting multiversioning and copy-on-write semantics, it isn’t clear that such techniques will suffice when thousands of agents are attempting to edit shared state at the same time. For instance, when agents are trying various potential transactions in response to a user request, the effects of the vast majority of these transactions need to be rolled back—with only the one ‘correct’ transaction’s result persisting. Work on supporting exactly-once semantics is relevant here, as are underlying techniques based on CRDTs and operational transformation. For updates to fuzzy mechanisms such as memory, we may be able to sacrifice on consistency for perfect correctness in the interest of latency. While agents can reason about semantics to compensate or roll back their actions to eventually finalize most tasks, the primary challenge lies in the degree to which they step on each other’s toes during the process. An important failure mode to be avoided is a form of “livelock,” where incessant compensating actions prevent any meaningful progress.
Beyond shared state, other concerns emerge when trying to support an army of agents, including what to do when agents fail, how agents should communicate with each other (directly or through intermediate shared state), and how we should deal with straggler agents. There have been some developments in supporting durable multi-agent execution, such as Temporal, but it remains to be seen if such solutions will apply at scale across thousands of agents. On the topic of communication, we need mechanisms to enable agents to negotiate with each other. Imagine four developer agents attempting to reach consensus on a shared schema, with distinct but overlapping objectives. In a human setting, this would involve iterative discussion and compromise; for agentic swarms, we must define the mechanisms that allow them to converge on a design that reflects the underlying goals of their respective principals. Or if agents are all requiring access to a limited resource, again communication will be necessary. It remains to be seen if this is best done via centralized coordination, or if a decentralized approach is necessary.
Data Systems By Agents
Finally, if intelligence is effectively free, then we can employ this intelligence to synthesize new data systems from scratch. Indeed, in many settings, general-purpose data systems may be overkill, as they have to support every schema, query, and hardware target. Given a workload, recent work, including Bespoke OLAP and GenDB, has shown that one can use an agentic pipeline to synthesize a complete, workload-specific analytical engine—in minutes to a few hours, at a cost of a few dollars. The engines are disposable: when the workload shifts, one can simply regenerate them. Analogously, our work has shown that one can synthesize custom key-value stores from scratch, targeted to the workload. In fact, modern IDEs, such as Kiro, elevate specifications for systems development to be a first-class citizen.

Agents Can Synthesize Custom Data Systems From Scratch
The main issue, however, is that specifications are typically imperfect, and don’t cover all corner cases. Present-day agents will exploit the missing specifications to reward-hack their way to a high performance metric. In our custom key-value store work, we found that one way to alleviate this is to have auxiliary verification agents trying to generate test cases that catch the exploitation of corner cases, essentially expanding the specification. Yet another approach is to both generate a system and a proof for its correctness together, for which we have found some early success, but more needs to be done to solidify the approach. Further, it remains to be seen what is the best way to solicit human-written specifications for a system—can this be done in an iterative, human-in-the-loop manner, as opposed to a one-shot, incomplete one. Indeed, human-written specifications are incomplete even for manually authored software, so one would expect that future agents that are more aligned will increasingly exercise better judgement when making design decisions.

One Possible Data System Synthesis Pipeline [From Here]
Other questions here involve testing whether starting from a mature system (e.g., Postgres) and removing components/functionality can lead to higher performance or more user trust. Separately, is there an opportunity to make the design composable, comprising various verified components that are mixed and matched given a workload? For example, perhaps the workload hasn’t changed enough for the storage layer to be updated, but perhaps the query optimizer requires changes. A perhaps more viable proposition involves employing agents coupled with proof systems to target critical parts of the code associated with formal proofs, rather than doing so for the entire system.
A final opportunity here is to move away from the traditional data systems stack with clearly-defined interfaces (e.g., parser, query optimizer, storage manager, …) — that were each largely the prerogative of a single human team to manage. Instead, agents can find new ways to “blend” these components together, perhaps identifying new optimization opportunities as a result. Agents can also fill in missing gaps in functionality to make existing systems much more feature-complete, or reach feature-parity with other competing systems—or analogously, continuously refining open-source systems in response to feature requests or issues (perhaps filed by other agents!) Doing so in a way that prioritizes correctness, long-term maintenance, and human interpretability will be a challenge.
Looking Further Ahead
In the era of near-free intelligence, data systems matter more than ever. As agents take on the bulk of knowledge work, the workload for data systems will change, the substrate they need to run on will have to be built, and increasingly, they will participate in designing data systems themselves. Each of these shifts opens up a new, exciting research agenda.

Co-Evolution of Data Systems and Agents
Looking further out, the boundaries between agents and data systems will likely start to blur. For instance, agents may design the data systems they themselves run on, defining both the interfaces as well as the system components underneath. Both the interfaces and internals can be evolved over time by agents in a form of recursive self-improvement. There is also an opportunity to rethink data systems as a holistic source of truth for the entirety of relevant state: including raw data, memory, and coordination state, further erasing the distinctions between the data that is being queried by agents and data generated as a result of agentic activity. Finally, data systems may themselves incorporate agentic components, fundamentally evolving from passive computation engines into intelligent, proactive, self-optimizing architectures. It is hard to predict what the future may hold. We’re in for a wild ride!
Acknowledgments
The perspective and ongoing work described in this post are the product of joint research and many discussions with wonderful collaborators at the EPIC Data Lab, Data Systems & Foundations group, and the broader Berkeley AI-Systems community. Thank you all!
BibTex for this post:
@misc{intelligence-is-free-blog,
title={Intelligence is Free, Now What? Data Systems for, of, and by Agents},
author={Aditya G. Parameswaran and Shubham Agarwal and Kerem Akillioglu and Shreya Shankar
and Sepanta Zeighami and Rishabh Iyer and Matei Zaharia and Alvin Cheung
and Natacha Crooks and Joseph Gonzalez and Joseph Hellerstein and Ion Stoica},
howpublished={\url{https://bair.berkeley.edu/blog/2026/07/07/intelligence-is-free-now-what/}},
year={2026}
}