# The Rise of the Agent Workforce: Rethinking Agent Infrastructure — Ankit Mathur — session 2026-11-11T19:45:00.000Z → 2026-11-11T20:05:00.000Z _57 transcript lines · 40 slides_ ## Transcript Alright. Well, super excited to be here. My name's Ankit. I'm from Databricks. I work on AI infrastructure there. And today I'm gonna talk about, the rise of the agent workforce and how we're building our agent infrastructure to support what we Think is the next generation of agents. I wanted to start by taking a step back and and thinking about how we help computers become good at other things, better even than humans. And one of the games I grew up playing a lot lot was chess. It's one of the great examples of something where computers became way better than humans a long time ago, but I think it's important to think about why that happened and how we can apply those lessons today. One of the biggest, you know, to summarize at a high level, a lot of work went into it. The biggest thing that agents were able to do, that computers were able to do, was explore the space of decisions much more effectively than humans. For most complex problems, there's actually a bunch of different ways you can solve the problem, And at each turn, you can kind of pick... Think of three more decisions that you can make. And really, it's the exploration of that space that all of us are engaged in. In. All of us who solve hard problems are engaged in the search space for what's an amazing product, what's the right solution to this math problem, and etcetera. Right? I think we've seen some really exciting progress from the labs, like Anthropic, OpenAI, and Google, on solving problems that are well formed. So, you know, if you think about chess, it can be modeled effectively. You can evaluate your position. You can actually play it, simulate it. You can try different moves and safely think about all the different alternatives. Similarly, with math problems, often the ones that agents are really good at solving, they... You can actually verify if you got the result right. And how do we then take That mindset and apply it to the problems that we actually face day to day. I think, like, let's... A lot... Everyone here is an engineer, so let's take it to engineering for a bit. I think, you know, if you take it to the pre AI days, most people think about solving a single problem, and they're kind of single threaded on that problem for the time that they're writing code on it. And, you know, as a company or a product, if you wanted to solve more problems, you brought in more people. And the very basic version of agents just help Create leverage for that engineer. Now you can be single threaded on three things at the same time, and ultimately that helps you explore new product ideas, ship faster, iterate faster, and that's obviously very exciting. But it's it's not actually close to what we needed to do to win at chess or any of these other problems. What we're seeing at the absolute frontier are these teams of agents that are able to make significant progress by exploring the decision space more effectively. So how do we move towards that world where we actually have these teams of Agents that are coherently attempting to solve problems. It's actually quite complex, and we think it requires a little bit different type of infrastructure. Specifically, I think an important question to ask is how do we give agents a realistic world to explore? Because in other problems, we're able to help define that world very effectively. But even in software engineering, we actually really struggle to do that. Like, just consider this movement towards software factories, right, where you're away from the from the agents, and you're actually operating a bunch Of agents that are working on a problem. How do you validate that those agents are effective? Like, before, you had a branch, you had main, you branched your PR off of that. Maybe you have an agent working on that PR, and you have some reasonable assertion that this is kind of a sim... You know, you have some, some tests or something like that that help you guide your development. But if you're actually merging tens of PRs a minute or even more. Right? Like, if you play out the future of Of agents building code and software. Your PR is just out of date the moment you branched. The the moment you started, you're already out of date. And so it demands a different mindset of thinking of how do we verify these things. You actually might want to move most of your verification to post merge. And so that kind of brings me to this a little bit radical idea. I I don't think we should try to write hundreds or thousands of unit tests. Instead, I want to explore this idea of simulating reality. Can I give my Agent of faithful reproduction of what's actually there in the real world, in my production code, in my production agent, and let it work on that. And with you... When you can do that, you can actually do that at scale. If you find a way to simulate reality, then you can actually do that across lots of different explorations. At Databricks, one of the big things that people do on our platform is build data pipelines. We've got tens of thousands of data pipelines on Databricks, and the biggest problem that happens with pipeline Is that they break. And in this era of agents, what people want is they wanna fix those broken pipelines with agents, because these are serious business problems that they... That are, you know, caused by a broken pipeline. If a pipeline breaks, that business can't operate that day. And so this becomes a major emergency. But, like, how do you actually validate this with an agent? Do you trust it on your production data pipeline? It's pretty risky because writes might not be idempotent, even reads might be Extremely expensive and affect other use cases in production. Right? Sometimes it's not fully broken. It's just partially broken. One of the things we started doing was building on top of branchable infrastructure. And so what we did was we branched the entire data platform. We branched the tables, the compute, the governance, and we gave the agents a place where they can actually play with the data platform and explore different hypotheses. And these hypotheses can be ambitious, like, can I investigate the upstream pipe? Is healthy, maybe I can do that by changing the pipeline code and running it again. In any reasonable data platform, you wouldn't do that with an upstream pipeline unless you had a bunch of engineers take a look at it and make sure it was super safe. With our branch to data platform, you can actually do that now, so it can investigate a bunch of different things. So we can investigate 10 ideas in parallel with our agents, actually get to a faithful conclusion about whether it fixed the real data pipeline, and then make that assumption, make that assertion back either to a main agent or to a human. And what we saw before was happening was that people would just, like, LLMs would give us text back, some human would take a look at it and be like, okay. This might be an interesting theory. Then they would go apply that theory in some way, and ultimately, that became more of this, like, AI assisted version of fixing the data pipeline. But really, where we wanna go is is is hands off, full full auto for this kind of problem. And we were we were struggling to do it without this branchable infrastructure. So how do we do it? I'm gonna talk a little bit about that. This talk. We built this on top of our Postgres native agent platform, which started with the Neon database, which is a branchable database that gives us a single place that we can actually use for our services and for our agents. And then we added in a bunch of really core agent primitives that allow us to build sophisticated different types of agents, and And those are ones that are probably familiar to all of you, things like memory, things like sandboxes, file systems, and ways to host those agents. And these low level primitives, we can build Build with them, but the key is that we made just all of them branchable. So you can branch the entire reality of stuff that's built on this platform for us... For ourselves. So how do we actually do that? Well, let me walk it through, like, kind of case by case. The first thing is just the database. Right? And, you know, we can take an example of application services, but here I'm gonna talk about just even storing the conversation state for for an agent. When you fork or branch an agent, you actually might wanna inherit the history. And you might even, if you have a team of agents, give Access to a given member of that team to what the other team members of the team are doing. And we found the database to be a convenient abstraction for this. The key was that, hey. Like, when a new reply comes in on the on the branched agent, it shouldn't necessarily change anything about the other one. And this is possible because Neon has a branched database. But then we actually found that agents need more than just structured databases. Of course, they need structured databases, but they also like to do this, you know, write these things called memories. And memory These are, you know, at a very high level, they compile down to an unstructured database for agents. There are two ways that memories get generated. The first is just by synthesizing the context and the conversations that someone's already had with them, and the second, by agents actually explicitly saving content to an unstructured place. The key thing here is that you actually wanna consolidate and distill that information. There's a ton of information coming in through there, and if you just give that... You know, if you just let it kind of go on its own, you have Problems of staleness. You have conflicts in the information, and all of those can be extremely damaging to teams. So we have this thing that basically dreams overnight. We use offline compute, and it takes the conversations. A different agent essentially highlights things that are conflicts and consolidates the ad hoc notes that were written by various members of the team. And then all members of the team can actually recall from that memory database, and you can use this in a bunch of different ways. We use this within our Slack. Agents, but we also use this when we're launching a parallel set of agents to investigate a deep issue, for example, in the data platform. Now how does branching come into this? Well, some of the agents, like in many of the use cases, they propose memories, and it's not clear whether those memories generalize to the actual broader set of agents or if that's a specific thing for just that agent. And so with the branchable database for memory, which is built on top of this Neon database, we can actually just propose that memory somewhere in there. That branch can continue to iterate, and at some point, we can find a way to merge it back in if it's necessary. We found this to be a flex... An important layer of flexibility, because without the ability to completely branch the memory, we found it was very hard to maintain the memory for a team of agents. Especially as we increase parallelism, you can actually experience, like, significantly reduced quality if all the agents are pursuing different goals. I I I like to think a little bit of it as an... As, like, kind of similar to dynamic programming. Right? If you've Or the branch of expiration, and then you have a different agent that happens upon that same pathway, it's very damaging to, like, always revisit that, but sometimes you want to, and so the ability to propose a memory is extremely important to us. How is all of this kind of branchable database possible? Well, the way that Neon does is it is it separates compute from storage. Compute, for Postgres is running in some separate place, and then we actually have the shared history and the storage in a different layer. And what that Let's us do is copy on write for branching. So when we have a branched version of the database, you can actually have a's, you know, compute a's rights separated from compute b, and that's the kind of the core layer of infrastructure that allows us to build these applications on top of that database. But then we found, you know, obviously, agents are far more than storage, and and branching storage wasn't enough. We also found that as they were running in sandboxes, agents like to take notes on stuff and write down scripts and Use those to actually iterate on various kinds of problems. It it... It's one of the most exciting things about agents that I've found, that they are able to generalize this capability that's needed maybe for testing code and and things like that, and solve other more broader general problems using that same construct. But then when you branch it, you actually need to give the future agent a similar context. If you... We found that when we started the branched agents without the same files that that agent had to begin with, it just wasn't as effective. So when you're investigating an outage, for example, with an agent, you might have notes and plans, and a future branch of that agent might update those notes. It might find new things, but we don't want that to go back, because we're actually exploring 10 different pathways at the same time. So building a branchable file system was extremely important, and allowed us to build what we call a branchable sandbox. Because then what we can do is we can launch that sandbox compute, and and that's a hard problem in and of itself. It's not one we're gonna talk about today, but That compute can be attached to storage, and critically, the agents actually really aggressively leverage files very often. And so it can be very painful to make all your storage fully remote. And so the really core piece of what what we've been building here is a syncing process between what we call a local cache and the remote cache. And then what that allows us to do is as we're able to make progress on that, when we wanna branch, we can actually branch a second sandbox, use that similar file system, and it Reduces our latency first... For branching while also keeping performance of the regular agent reasonable. So what this allows us to do at a high level is branch the entire working state, and this gives us the platform layer to actually go do that. Now this isn't obviously sufficient. You're gonna wanna branch even more. If you're building on top of software, you wanna find a way to branch that too. And so this is along the lines of how we're thinking. Right? Like, we... The data platform was built on top of some of these But there's a lot more that we've been able to branch there as well. But we're really excited about this layer for just even building agents. And just to, like, kind of separate a little bit even from software development, like, another thing a lot of us are spending a lot of time thinking about is security. I mean, just taking a step back, I think this is probably the single most important thing for any product that anyone sells at this point because trust is kind of the most important thing that we're selling when we work with other people. And With agents being the ones who generate the vulnerabilities, it's kind of impossible to find a different solution than having agents be the ones who are monitoring for those exact vulnerabilities in your code. So you should be thinking about how you can build an agent factory that's detecting security issues in your code base. And so this is something we're spending a lot of time on... Spending a lot of time on. So typically, what happens in a security incident? Well, let's say you suspect something. An agent might be always looking for it. Why is There this, like, network traffic that's egressing all of a sudden from my control plane. Well, I can assemble an incident timeline, and that's obviously the first step in an investigation. But anyone who's been a part of a serious security invest... Investigation knows that time is of the essence. It's a perfect problem for and that's exactly what you do when a security incident happens. You bring everyone online, so you can explore 10, 15, 20 different theories at once, because an hour earlier that you can you can detect the real issue is an hour that you're actually more safe. So, okay, what if we did that with a branchable agent? Let's say there's two paths to investigate. So, you know, the agents assembled the incident timeline, and now you can ask two questions. Hey. Did a recent deployment introduce some kind of new integration? Like, maybe I can go look at the code, or I can explore a totally different theory. Is a compromised identity accessing this data? And the core thing that we are able to do here is we branch that whole original agent that was starting the investigation. And then the new one is able to work in a completely isolated copy of the world. And in some cases, when we're able to, we can even branch the actual service that we're investigating. And so when you have this isolated copy of conversation, memory, and storage, you can fully explore that security risk and and let the agent loop on its own. And that's kind of the key thing here. The way that these agents are good is that they're able to loop, verify, try new theories. I think Andrej Karpathy said it really well. They're far more tenacious than Any human probably in the history of software. And so they're able to just... But, like, we keep getting in the way by inserting ourselves as an approval layer. And so this is a solution that we think helps with that. Just, like, take away the consequences of making a mistake a little bit. Bit. Branch the entire state so that you're not actually, you know, worrying about that same risk. And then you... We've, you know, we've been able to find this to actually, come to a reasonable conclusion as well. So what This all add up to? For us, we think that your infrastructure needs to be branchable, and that's what we're building with Neon, with Databricks, and we're super excited about that branchable future because we think that teams are going to be the next generation of agents, both for software and the way that we actually build products. Thank you. ## Slides ### 00:00:03 # Code Summit ## AI Engineer ### 00:00:38 # AI Engineer Code Summit Presented by Google DeepMind ## AVAILABLE ### LIVE TRANSLATION Scan the QR code to access real-time translation. [QR code linking to https://events.google.com/deepmind-code-summit/translation] ### 00:01:06 # AI Engineer Code Summit ## STAY IN THE LOOP SCAN THE QR CODE OR VIEW THE SCHEDULE AT AI.ENGINEER/SCHEDULE [https://ai.engineer/schedule](https://ai.engineer/schedule) [QR code linking to ai.engineer/schedule] ### 00:01:38 [Dark background with a subtle grid of dots, featuring a slightly brighter, circular cluster of dots in the center.] ### 00:02:12 # AI Engineer Code Summit ## Presented by Google DeepMind [Background display showing a grid of company logos and the event title, indicating sponsors and participants] ### 00:02:41 # AI Engineer Code Summit ## PRESENTED BY Google DeepMind [https://events.google.com/ai-engineer-code-summit/live-translation](https ### 00:03:12 # AI Engineer Code Summit ## Presented by Google DeepMind ### The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff databricks ### 00:03:36 # The Rise of the Agent Workforce: Rethinking Agent Infrastructure Presented by Google DeepMind at AI Engineer Code Summit Ankit Mathur / Member of Technical Staff, databricks [https ### 00:04:08 # Most people solving a problem think single threaded - Single threaded ### The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff databricks [A white dot on the slide] [QR code for the presentation] ### 00:04:35 # Most people solving a problem think single threaded ## Basic agents [Diagram showing a single input line branching into three separate output lines, each ending in a teal circle] ### 00:05:08 ## How do we give agents **a realistic world** to explore? ### AI Engineer Code Summit Presented by Google DeepMind ### The Rise of the Agent Workforce: Rethinking Agent Infrastructure ### 00:05:39 # Software factories demand a new model of validation ## The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff, Databricks [https://www.databricks.com/](https://www.databricks.com/) [Diagram showing two horizontal lines labeled "Main" and "My PR", each with multiple dots, connected by a vertical line, representing a version control branching and merging process.] ### 00:06:08 # Software factories demand a new model of validation ## The Rise of the Agent Workforce: Rethinking Agent Infrastructure [Diagram illustrating a version control workflow with a 'Main' branch showing multiple commits ### 00:06:40 # Don't test. **Simulate.** ## The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff [Diagram showing a flow ### 00:07:08 # Production data pipeline. > "The pipeline failed." ## The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff [Diagram illustrating ### 00:07:39 # Production data pipeline. > "The pipeline failed." ### The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff databricks [Diagram illustrating a production data pipeline with an agent interacting with it, and a branch point labeled "Branch here" where the pipeline failed] ### 00:08:08 # Branch the data platform. - Production data pipeline - Tables · Compute · ... - BRANCHED DATA PLATFORM - Investigate upstream pipeline health - Tables · Compute ### 00:08:40 # Branch the data platform. ## The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff databricks [Flow diagram illustrating a data platform branching ### 00:09:07 ### AI Engineer Code Summit Presented by Google DeepMind # Built on Postgres-native agent platform - NEON - Lakebase --- ### The Rise of the Agent Workforce: Reth ### 00:09:37 # Branch the conversation. ## Conversation - NEON - History [Diagram showing a box labeled "NEON" with "History" and two lines, connected by a horizontal line to a red circle, illustrating a branching point in a conversation.] ### 00:10:12 # Branch the conversation. ## The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff databricks [https://www.databricks.com/](https://www.databricks.com/) [Flow diagram showing a central 'NEON History' box branching into two separate 'Conversation' paths, labeled A and B. Conversation A includes a 'New reply'.] ### 00:10:34 # Memory is an unstructured database for agents ## The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff databricks [https://www.databricks.com/](https://www.databricks.com/) [Flowchart showing "Agents" recording to "Conversations" and saving to "Memories", both within a "Lakebase"] ### 00:11:07 # Memory is an unstructured database for agents - **Agents** - Records to **Conversations** (within **Lakebase**) - Saves to **Memories** ( ### 00:11:38 # Memory is an unstructured database for agents ## The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff, databricks [Diagram showing an Agent connected to a Memory database within Lakebase. The Agent can also "Propose a memory" to the system.] [QR code] ### 00:12:08 # Memory is an unstructured database for agents ### The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff databricks [Flow diagram illustrating an Agent interacting with a Memory database (labeled "Lakebase") and a Memory database branch. The Memory database contains multiple memory items. The Memory database branch also contains multiple memory items, with one labeled "Proposed memory" highlighted in red. Arrows show data flow from Memory database to Agent, from Agent to Memory database branch, and from Memory database to Memory database branch.] [QR code linking to https://www.databricks.com/](https://www.databricks.com/) ### 00:12:38 # Memory is an unstructured database for agents - Lakebase - Memory database - Agent - Memory database branch - Proposed memory [Diagram illustrating an Agent interacting with a Memory database and a Memory database branch, with Lakebase connecting the Memory database to the Agent.] ### 00:13:07 # Separate compute from storage. ## Compute A - Postgres - RAM + local NVMe ## Compute B - Postgres - RAM + local NVMe Neon storage - A writes - B writes - Shared history ### The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff, Databricks [https://databricks.com/](https://databricks.com/) [Diagram illustrating two compute instances (Compute A and Compute B) each running Postgres with local RAM and NVMe, both connected to a shared Neon storage layer that manages writes and a shared history.] ### 00:13:40 # Branch local filesystem. ## Sandbox - /outage-123 - notes.md - plan.md ### The Rise of the Agent Workforce: Rethinking ### 00:14:08 # Branch local filesystem. ## Sandbox - Folder: `/outage-123` - `notes.md` - `plan.md` - **Branch ### 00:14:40 # Branchable sandbox storage. ## Compute A ### The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff [https://www. ### 00:15:12 # Branch the whole working state. ## Agent - Conversation - Memory - Storage ### The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff ### 00:15:36 # Branch the whole working state. ### The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff, databricks [https://www.databricks.com/](https://www.databricks.com/) [Diagram illustrating an "Agent" component with Conversation, Memory, and Storage modules. Its state branches into two distinct components, A and B. Each ### 00:16:09 # Example: Agentic Security ## The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff databricks [Diagram showing an Agent feeding into ### 00:16:36 ## Example: Agentic Security > "I've assembled the **incident timeline**." ### The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff [Diagram illustrating an agent feeding into an investigation workspace, which then pop ### 00:17:12 # Two paths to investigate. - Investigation workspace - Captured evidence - Agent - "Did a recent deployment introduce a **new integration**?" - "Is a **comprom ### 00:17:36 # Branch the investigation. ## The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff [Flow diagram illustrating a process: an "Agent" leads to an "Investigation workspace" which holds "Captured evidence". From this workspace, a "BRANCH" creates an "ISOLATED COPY" containing "Conversation, Memory, Storage", while the "Source workspace continues" along a main timeline.] [QR code] ### 00:18:08 # Branch the investigation. The diagram illustrates a branching process: - An initial **Agent** leads to an **Investigation workspace** where **Captured evidence** is stored. - The main process ### 00:18:41 # Your infrastructure needs to be **branchable**. ### The Rise of the Agent Workforce: Rethinking Agent Infrastructure Ankit Mathur / Member of Technical Staff, databricks [NEON logo] [Diagram showing a single point branching into three separate lines, each ending in a dot] [QR code] ### 00:19:05 # AI Engineer Code Summit Presented by Google DeepMind ## // AVAILABLE # LIVE TRANSLATION Scan the QR code to access real-time translation. [https://events.google.com/io/live-translation](https://events.google.com/io/live-translation) [QR code linking to Google I/O live translation] ### 00:19:40 # LIVE TRANSLATION // AVAILABLE Presented by Google DeepMind for AI Engineer Code Summit Scan the QR code to access real-time translation. [https://codesummit