On October 7, 2026, Constructive co-hosted and sponsored Frontier Research Club #26, Agents in Production: The Data Layer. It was an official a16z SF Tech Week session, put on with Kristopher Floyd and The Frontier Syndicate at Pebblebed's space in San Francisco.
The invite asked one question: what needs to change when AI agents become users of production databases?
It also said what agents need. They need to remember what happened, recognize when facts change, respect permissions, and recover when their actions go wrong. Very little of that lives in the model. It lives in the systems that store, govern, and serve the agent's data. That's the layer Constructive works on, so this was a room we wanted to be in.
The Frontier Research Club format suits the topic. Papers go out in advance, talks are short, and most of the evening is questions and critique. Everyone who registered was reviewed, and the room was a mix of academic and industry researchers, engineers, founders, and investors.
Secure databases for agents
Agents aren't only using databases anymore, they're building them: writing the schema, the migrations and the policies. When an agent writes your policies, one question matters more than the rest: who can reach which rows?
That's what Constructive works on. We build secure-by-default Postgres for agents, with roles, policies and row-level security compiled into the database. Your agents can stay stochastic. The database underneath them can't.
We announced Safegres: safe and fast Postgres, graded. Safegres is a static analyzer for a live PostgreSQL database. It reads the system catalog and parses every policy predicate and function body into an AST, then answers two questions the catalog already contains the answers to: who can actually reach this row, and what does checking that cost per row? It scores them on two independent axes. Generation got cheap. Verification didn't.
Then I handed it over to the researchers.
Talk 1: agent memory needs a real database
Daniel Chalef, founder and CEO of Zep, gave the first talk: Context as Production Infrastructure: Governed Facts, Invalidation, and the Audit Trail.
His starting point: your agent's memory is rotting and it doesn't know it. Facts change, permissions shift, and new information contradicts what came before. An agent that keeps acting on a stale fact, or on context from the wrong tenant, gets no warning that anything is off.
Daniel's answer is that agent memory needs what databases already provide:
- Provenance: where a fact came from.
- Access control: who is allowed to see a given memory.
- Staleness: knowing when a fact stops being valid.
- Context as production infrastructure: memory held to the same bar as the rest of the production data stack, not a side store you bolt on.
This is the problem Graphiti, Zep's open-source temporal knowledge-graph engine, is built for. The pre-read was the team's paper, Zep: A Temporal Knowledge Graph Architecture for Agent Memory.
Talk 2: agents don't query, they speculate
The second talk came from Shu Lynn Liu and Shubham Agarwal, PhD researchers in the UC Berkeley Sky Computing Lab. They presented their CIDR 2026 paper, Supporting Our AI Overlords: Redesigning Data Systems to Be Agent-First. The co-authors include Ion Stoica and Matei Zaharia, two of the Databricks co-founders.
Their argument is that agents don't use a database the way people do. A person writes a query and reads the result. An agent speculates. It explores schemas, column statistics, sample rows, and partial solutions, often in parallel, and then validates what it finds.
That workload looks nothing like what databases were designed for:
- On the BIRD text-to-SQL benchmark, more attempts help, but 50 parallel attempts are largely redundant. Most of that work is wasted.
- Agents create roughly 20x more branches and 50x more rollbacks than humans.
Their proposals follow from that:
- Probes with natural-language briefs: the agent tells the database what it's trying to do, not just which query to run.
- Satisficing query processing: a good-enough answer, fast, when that's all the agent needs.
- Storage for semantic caching and cheap branching: so a large number of redundant, short-lived attempts doesn't swamp the system.
Memory layer, or a whole new database?
Frontier Syndicate summed up the discussion as memory layer or a whole new database? The two talks start at different ends of the stack. Daniel's starts from what an agent remembers. Shu and Shubham's starts from how an agent queries. They reach the same conclusion: what agents need from their data are database properties.
Provenance, access control, invalidation, isolation, branching, rollback. None of these are new ideas. Databases have spent decades making them correct. What's new is a user that exercises them far harder than any human, all the time.
That's our view at Constructive too. An agent that speculates will touch rows it shouldn't and try paths no one planned for. The only thing that reliably holds under that load is a policy the database enforces on every query, every branch, every retry. You can let agents explore freely when the security boundary is in the data layer and not in whatever code the agent happened to produce. And since agents are increasingly the ones building the database too, that boundary has to come with it by default.
Your next database user won't be a human. It's worth building the database for it now.
Thank you
Thanks to Kristopher Floyd, The Frontier Syndicate, and the Frontier Research Club for putting the night together. Thanks to Nicole Levin and the Pebblebed team for hosting us, to Daniel, Shu, and Shubham for two sharp talks, and to everyone who stayed late arguing about it. Photos and video by Sumi Shan.
Frontier Research Club runs regularly in San Francisco, and you can find upcoming sessions on the Frontier Syndicate calendar.