Last week, Berkeley’s EPIC Data Lab (Parameswaran et al) published an essay that is absolutely must-read for anyone who cares about AI data infrastructure: “Intelligence Is Free. Now What?”. Its central thesis is that as inference becomes inexpensive, the bottleneck shifts from generating intelligence to managing it. Among the points that it makes is that agents will need entirely new data systems to support long-running work, persistent state, coordination, failure recovery, and collective learning.
Separately, a week earlier, a paper was published on arxiv [disclosure: I was a co-author on that paper] that describes the implementation of Trellis, a database architecture built around the agent experience graph—the complete search history of an agent, including every hypothesis, tool invocation, execution result, failure, repair, reward signal, and causal relationship. Rather than treating this history as disposable logs, Trellis argues that it should become the primary database abstraction. Trellis is not only a vision — large parts of it have already been implemented by Gang Liao’s fantastic team at Meta, and it serves as the foundation for the KernelEvolve accelerator-kernel optimizer that was published in ISCA 2026.
These two pieces were not coordinated — I am not aware of any communication between the large sets of authors of both pieces discussing this vision. Nonetheless, the two pieces fit together remarkably well. The EPIC Data Lab describes the research agenda and motivates it extremely well. The Trellis paper outlines an almost identical agenda (with respect to Systems for Agents) and describes an initial implementation of the system architecture for this vision.
The central claim of both pieces
The Berkeley EPIC Data Lab piece argues that the next generation of database systems won’t simply serve AI agents. Rather, they will become the environment in which agents actually live.
Instead of thinking about databases as systems that answer SQL queries, Berkeley argues we should think about systems that help agents:
- Maintain long-running state,
- Coordinate with other agents,
- Recover from failures,
- Accumulate knowledge,
- Continuously improve.
That is a profound shift. The database is no longer supporting applications. It is supporting autonomous work.
The Trellis paper starts from exactly the same assumption. However, as a technical paper (as opposed to a blog post) it is able to go into more detail on each of these points.
Maintain long-running state
The opening paragraphs of the Trellis paper describe some of the important data generated by long-running agent processes:
“These agents explore: they generate artifacts, execute tools, observe failures, branch, and repair over hundreds of steps. This search produces a structured object we call an experience graph: executable artifacts, tool outputs, rewards, sibling comparisons, and causal lineage.”
In other words, it is not only the prompts or chat history between the client and agent that is valuable. Rather the entire search process produces extremely valuable data.
A modern agent doesn’t simply answer a question. As part of this process:
- It explores.
- It tries.
- It fails.
- It backtracks.
- It repairs.
- It compares alternatives.
- It gradually converges.
An agent doesn’t merely perform a search process; it experiences the search process. The knowledge it gains when trying and failing and experimenting is extremely valuable. It should not be treated as disposable state, nor maintained as hard-to-access local files.
The Berkeley article also highlights the importance of data systems being capable of sustaining this long-running memory. They agree that the existing state of the art of maintaining this memory in local files is woefully insufficient.
Trellis sharpens that observation by going into significant detail in describing how existing systems attempt to manage state and memory of past actions and interactions with a client. The Trellis paper argues that although some systems do indeed treat subsets of this memory as disposable, the real problem isn’t persistence per se, but where persistence lives. Today’s agents scatter their state across Python objects, JSON checkpoints, process-local memory, file-based memories, and execution logs. Trellis argues that this architecture fundamentally limits crash recovery, collaboration, reuse, and learning. Its central proposal is therefore not simply to “store more state,” but instead to elevate the entire experience graph into a durable, governed database state. Once the database—not the agent process—owns that experience, capabilities like crash recovery, cross-session reuse, horizontal scaling, and continual learning emerge naturally from the architecture rather than being bolted on afterward.
Coordinate with other agents
This general approach also has implications for coordinating with other agents. The Berkeley article states:
“[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?.”
The Trellis paper describes a similar vision that includes cross-session reuse across agents (so that one agent can pick up where another agent left off) and multi-agent scientific societies”.
“Cross-session reuse is vector-seeded graph retrieval… More broadly, Trellis turns inference-time search from disposable computation into a durable institutional asset.”
“[Trellis enables] a two-loop architecture: an inner loop of skill-driven agent sessions, and an outer loop of RSI tree search over a persistent data substrate … this framework extends from a single-agent search to multi-agent scientific societies where agents share hypotheses, critiques, and distilled knowledge.”
In other words, when memory is stored locally inside an agent, that agent benefits from it, but it is not so accessible from other agents.
In contrast, when memory is stored in a shared, globally accessible data system, all agents can benefit from it. Trellis is about giving an entire community of agents a shared, governed experience graph.
Memory is individual. Experience graphs become institutional.
Recover from failures
By storing memory/state in a shared data store, recovery from failures becomes significantly more straightforward. As the Trellis paper explains:
“Existing agent frameworks treat this experience as disposable state—JSON checkpoints and session logs that cannot be recovered after a crash…”
“… When the database owns the experience graph, agents become stateless compute, and crash recovery, horizontal scaling, and a closed-loop training flywheel emerge as architectural byproducts.”
When an agent fails, the experience it has developed prior to the failure doesn’t fail with it (as it would if memory was local). Instead, the experience prior to the failure is retrievable from the stared data store, allowing another agent to pick up immediately from the point where the failed agent left off. Accumulate knowledge
A critical point that the Trellis paper makes is:
“Existing agent frameworks treat […] experience as [local data that cannot be] queried across users, searched by similarity, or materialized into training data without brittle, after-the-fact scraping. Even the file-based memory that production agents have converged on … captures what an agent knows, not the reward-bearing experience graph of what its search tried.”
That paragraph explains where today’s agent frameworks fall short. Most “agent memory” today is really one of three things:
- Conversation history
- Markdown files
- Vector embeddings
Existing systems preserve facts. They rarely preserve experience.
Trellis argues that the most valuable artifact isn’t what the agent concluded. It’s everything the agent attempted along the way. That is an entirely different philosophy of memory.
For example, when writing code to solve a problem, an agent may try 10 different approaches, of which three were viable, yet only return one to the client. That which was returned is certainly knowledge. But the whole experience of trying the 10 different options, understanding the reason for failures, and reward scores associated with each attempt is also knowledge. Both types of knowledge are included in the vision of what data needs to be accumulated to optimize future interactions and learn over time.
Continuously improve
The Trellis paper describes how the accumulated knowledge described above is used to continuously improve the system:
“Because every converged solution raises the baseline for the next, this loop is a concrete form of recursive self-improvement.“
“…training-data extraction is a materialized view [over the data system substrate that Trellis implements]…”
“…a closed-loop training flywheel emerges as an architectural byproduct.”
When an agent gets to a particular point in the search space, it needs to decide what to try next. Generally, the search strategy being used dictates this decision. However, the experience of what has been tried by other agents at similar points in the search has the potential to significantly improve this decision-making process. By making this experience a first-class data citizen, it becomes much easier to collect it and use it to train models that impact the search strategy.
Search is a database workload
The central thesis of the Trellis paper is once you have an adequate data system that can manage all the relevant experience memory, future agent searches becomes a database workload over this system:
“Trellis [is] a data foundation that treats the experience graph as first-class, governed, queryable database state rather than ephemeral logs. The core insight is that search over experience graphs is a database access pattern. Frontier selection is a query, cross-session reuse is vector-seeded graph retrieval, training-data extraction is a materialized view, and reconstructing what an agent knew at any past step is a time-travel query.“
The paper then translates typical agent operations into familiar database operations.
| Agent concept | Database concept |
| Resume work | Query the frontier |
| Reuse previous discoveries | Graph traversal + vector retrieval |
| Build training corpus | Materialized view |
| Replay reasoning | Temporal (“AS OF”) query |
| Compare branches | Graph query |
This is exactly the kind of abstraction that the Berkeley article seeks and is a genuinely new way to think about agent infrastructure.
Stateless agents are a profound architectural shift
Another important point that is not made so clearly in the Berkeley article, but is hammered home in the Trellis paper is that if the data system for agents is built correctly, the agents themselves can become stateless, which greatly facilitates and accelerates their deployment.
“When the database owns the experience graph instead of the agent process, agents become stateless, serverless compute, and crash recovery, horizontal scaling, and a closed-loop training flywheel emerge as architectural byproducts.”
Most current agent frameworks assume the opposite — the agent owns the memory.
The Trellis architecture flips the relationship: the database owns the memory. The agent thereby becomes disposable.
This is similar to what happened in web architectures. Early web applications stored state inside application servers. Modern cloud systems made application servers stateless and pushed durable state into shared infrastructure.
Trellis proposes exactly the same transition for AI agents.
Why this abstraction became necessary
The Trellis paper amplifies the motivation that the Berkeley article describes with some lessons learned from KernelEvolve:
“KernelEvolve’s first implementation stored its search tree in process-local state and file checkpoints; this sufficed for a single session but failed as a production foundation. Progress was lost on crashes, parallel workers needed ad hoc coordination, prior discoveries could not be reused systematically, and training data had to be scraped from logs after the fact. Each missing capability was really the same missing abstraction: the experience graph was not a database object.“
That final sentence is the heart of the motivation: “The experience graph was not a database object.” It’s not that the orchestration framework wasn’t good enough. The problem was getting the right database abstraction. This is the main point of both the Berkeley article and the Trellis paper.
Trellis is the database abstraction that answers Berkeley’s call
To summarize what I’ve said so far. The article from Berkeley EPIC lab makes an important and convincing call for database abstractions for AI agents. Trellis answers every part of this call with concrete architectural design.
| Berkeley’s call | Trellis’s database abstraction |
| Long-running state | Experience graph |
| Coordination | Cross-session graph reuse + multi-agent scientific societies |
| Failure recovery | Database-owned experience graph → stateless agents + crash recovery |
| Memory | Experience graph instead of file-based memory |
| Continuous learning | Closed-loop training flywheel |
| Governance | First-class, governed database state |
| Collective intelligence | Durable institutional asset |
Conclusion
The Berkeley article from Parameswaran et al asks what data systems should look like in a world where intelligence is effectively free.
Trellis offers one of the first serious answers.
Rather than treating agent execution as transient computation surrounded by logs and checkpoints, it elevates the search itself into durable, governed database state.
If Berkeley’s article defines the research agenda, Trellis may represent one of the first concrete system architectures that begins to realize it. In an unusual time-travelling phenomenon however, the answer was published 9 days prior to the call (and has been under development for over a year prior to that)!
