From Babysitting Bots to Open-Source Attention Routing: The Colony2 Agent-Cell Model

Summary

The binding constraint in multi-agent systems is not compute but human attention — every time an agent pauses, fails, or needs review, a human must re-acquire context for what the agent was doing, what it decided, and what state it is in, a problem that multiplies across large agent swarms.
Colony2 addresses this by decomposing agent infrastructure into pluggable components around a single primitive called a cell — a repo-scoped runtime with its own context, capabilities, and contract where agents invoke explicit commands rather than acting in an opaque conversation, making every step an inspectable state transition.
The Colony2 durable workflow runtime is built on Neon Postgres, recording execution as first-class state so jobs can pause at wait points, retry on failure, resume after interruption, carry full audit history, and surface human approvals as routable primitives in the execution graph.

From Babysitting Bots to Open-Source Attention Routing: The Colony2 Agent-Cell Model

Single-agent chat loops require a human watching every step, and swarms multiply that burden until coordination becomes the binding constraint. This talk reviews an open-source approach to massive parallel agent coordination that decomposes infrastructure into pluggable components around one primitive: the cell, a repo-scoped runtime with its own context, capabilities and contract. Because agents invoke explicit commands rather than acting in an opaque conversation, every step is an inspectable state transition. The cell’s durable workflow runtime is built on Neon Postgres, recording execution as first-class state: jobs pause at wait points, retry on failure, resume after interruption and carry full audit history. Human approvals become routable primitives in the graph.
Talk By: Jacques Nadeau, Founder, colony2.org ;

Chapters

FAQs

What is the 'attention problem' for humans working with AI agents?

The attention problem, as described in this video, is that every time an AI agent pauses for human review, fails and needs diagnosis, or reaches a decision point requiring approval, the human supervising it must spend significant time re-acquiring the context for what the agent was doing and why — what the speaker calls the eight-thing problem of reconstructing the relevant state from an opaque conversation history. This problem multiplies exponentially across large agent swarms because each additional agent is an additional demand on finite human attention. The Colony2 approach treats human attention as the primary resource to be conserved in multi-agent system design.

What is a Colony2 cell and how does it differ from a standard agent loop?

A Colony2 cell is a repo-scoped agent runtime with its own explicit context, defined capabilities, and a contract specifying what it can and cannot do — and agents within it invoke explicit commands rather than acting through an opaque conversation turn. Because every action is a discrete, named command rather than an implicit LLM generation step, each step in the workflow is an inspectable state transition with a clear audit record. This design makes it possible to pause, resume, retry, and review individual steps without losing context or requiring a human to reconstruct what happened from a conversation log.

Why is durable workflow state important for multi-agent systems?

Durable workflow state means that an agent's execution history — every step it took, every decision it made, and every point at which it is waiting — is recorded as first-class data in a persistent store rather than existing only in memory or in a conversational context that can be lost. Colony2 uses Neon Postgres for this purpose, so jobs can pause at explicit wait points for human approval, retry automatically on failure, and resume after interruption from exactly where they left off with full history intact. This video argues that without durable state, multi-agent systems become brittle and opaque — requiring humans to babysit every step rather than intervening only when genuinely needed.

How does spatial context zoom help humans understand what a large agent system is doing?

Spatial context zoom is an analogy the speaker uses in this video — drawn from navigation tools like Google Maps — to describe a text and code navigation model where a human can zoom out to see the high-level structure of what an agent system is working on and then zoom in to the specific section relevant to a review or intervention, rather than reading through an entire conversation history. This approach makes it practical to supervise a large agent system without being overwhelmed by detail at every level simultaneously. Colony2 is designed to support this kind of spatial navigation as part of its context management model for human supervisors.

Full transcript

[00:10] Hey everybody. Um, this is new for me. I've not done a headphone thing like this before. Hopefully you guys can hear me. Hopefully they're not changing what I say into some kind of propaganda for data bricks. Um, I'm here today to talk to you guys about um, really figuring
[00:22] out how to deal with what I describe as the attention problem for humans when working with bots. Um, so a little bit about my background. I like making things. Uh, I've made a bunch of things that I'm proud of. Um, some of the
[00:35] things you might be more familiar with is I'm co-creator of Apache Arrow. I was the co-founder of Dumo. Um, one of the creators of the original project Nessie, which ultimately became a portion of Polaris, um, and a number of other things as well. My interest has
[00:48] generally been in system software in data infrastructure decomposible data infrastructure specifically um open source and then also seam mammals if you notice there are three same mammals up here and if you don't think that Nassie is a seam mammal you're wrong about that
[01:01] um about 18 months ago I started to think the same thing that a lot of people did which is like things are changing what is going on in this space I've been building software for almost 30 years we built a bunch of models for
[01:15] how to build software um I need to immerse myself in what's going on in these new patterns. And so this talk is about what I found and what I'm doing. It is probably one of the few talks that you're going to see today that is not selling you anything or trying to
[01:27] convince you of anything. It's just trying to get across experiences that I've had and some open source stuff that I'm putting out there into the world. Um I would love to have collaborators on. So as I started to work with these
[01:39] different technologies, the cloud codes, the codeexes, the different kinds of loops and tools that you use in in the in the modern uh developer experience, um I also worked with a lot of other developers and we talked about things and one of the key things that I kept
[01:52] hearing over and over again was is that people were tired and it's really brought this question sort of forefront to me which is if models are doing all of this work, why are we all so tired?
[02:04] Um and I think it comes down to the patterns and the fact that we built up all of these patterns over time for how software development was done historically right and so if you think about you know generally the model is kind of like hey we start with some kind
[02:16] of design process then there's this longer period of time which is development then that's followed up with some code reviews and some CI and stuff like that um and if you actually map out the requirement of the primary developer
[02:28] in terms of attention um over time you see a curve that's something like this right which is early on you're working on design and so there's uh focused work and then you probably have some collaboration point where you're working
[02:40] with others and discussing things. So you kind of slow down for attention for a bit and then you get back into focused work again then you then you slow down for again and then at some point you get to a resolution of what you want to do and then there's this continuous uh
[02:52] period of attention where you're doing development okay as a software developer and then once you get to the to done which with most software developers say hey I'm done that actually means that they haven't done the last parts which are code review and CI right and so then
[03:06] during code review and CI you're generally waiting for others you're waiting for a code reviewer you're waiting for tests to done and so there are short periods of attention requirement. Okay. And so what we did and most I saw most organizations do is
[03:19] is that as you wanted to work on different things simultaneously there's a nice pattern of meshing these things together. And so as you completed your first task and moved into that final phase of of of code review and CI, you
[03:32] could move on to the next task and step into that same process again. And the overlap between design and the review and CI was pretty good. They're kind of very complimentary. And so what you got was people who generally had a pretty
[03:45] good experience around attention. They had long periods of attention. Then they had short periods where they might be multitasking between a couple of things. When we introduced agents into the world, right? The model changed
[03:57] substantially, right? And so what we have is we still have a design period. It's different because you're collaborating say with an agent or something like that to do your design. But the development period is largely not something that you need to be attentive to except in random
[04:11] interruptions, right? Like, oh, the agent needs clarification or went down the wrong path. I need to adjust it. Oh, later. Okay, I need to adjust it again. I need to answer these questions. Um, and then the end period, right, is actually a heavier cognitive load
[04:24] because there's more that's been done that you're not as familiar with. Okay? And so you have this kind of different pattern where the big chunks of attention are at the ends as opposed to in the middle. And as good developers,
[04:36] what do we do? We say, "Hey, we want to maximize our attention, so let's do more things at once." And when you start to map that out, you start to layer things in a very different way, right? Because you want the second. So you basically are lining up design periods because
[04:49] that's your major attention period. And what happens is is that the concurrency that you're going to is much much higher than we historically done. And that means way more context switching. That means way more having to reload what
[05:02] context you were thinking about before. Um, and I think that that's the main reason that we're all tired. And it's not really that surprising if we have new tools and new technologies that we're going to have new challenges, right? And so I kind of broadly categorize these challenges into three
[05:15] main categories. The first is sort of the use the human problem which is what am I supposed to focus on right now? Right? As you have more things going on, how do I make sure that I'm focusing on the right thing? when I focus on that
[05:27] thing, how do I upload my how do I reload my context on this thing? Right? If I'm working on eight things, I can't hold all of them in my head at once. And so, I need to reacquire the context for this particular task to figure out what's going on. Um, and then how do I
[05:41] do that in such a way that I don't burn out, right? Like one of the things that I've lived through, I think probably most of you have probably lived through is at some point you're thinking I got to get the agent started before I go to
[05:53] bed so that they can do work while I sleep, right? It's this constant sort of like effort to like make sure that you're maximizing your tokens. The second set of problems is really about coordination,
[06:05] cooperation and concurrency, which is if you look at the situation, most of these patterns were built for what I describe as a single player game, right? I'm working on my local laptop and the same connection point that existed before,
[06:17] which is a poll request, is how I work with others. Um, and how do they how do others see what I'm doing? Because all this thought is happening inside these sessions, right? But how does my colleague see what that is? because
[06:29] generally speaking it's opaque to them. We still think of the diff as the main handoff point, which is weird, right? And then we look at like, okay, well, how do we formalize decomposition? Like, if you're gonna have more things happening simultaneously, you're gonna
[06:41] have more interdependencies, and you need to figure out how to formalize those. Relying on humans to formalize those seems like it's just additional cognitive load. And then there's a concurrency problem, which is I got lots of things happening simultaneously. What
[06:53] do I get? I get lots of merge conflicts. So, how do we solve this? It's like hey lots of things are happening simultaneously and we can still make for progress without a lot of noise happening at the same time. The third set of problems are kind of more
[07:05] associated with the dynamics of agents, right? Agents are a new thing that we have to work with differently. And I think about three kinds of things that are challenging with agents specifically. One is trust, right? What does it mean to trust an agent? I don't
[07:17] know. It's just it's just a it's just a program. It's but it is probabilistic, right? It's not deterministic and you have to remember that. And one of the key examples of this is is that you can ask an agent to run your tests every time at the end of its process. And 99
[07:30] out of 100 times it's going to run those tests. But that hundth time it's not. And that's probably always going to be true with an agent because they're probabilistic. Now the number might get bigger and maybe it's going to be 999 times out of a thousand, right? But it's
[07:42] the question of like are we even using are we using agents for things that we really do want to just be deterministic, right? delusion is about the fact that like context windows are getting much much larger but that doesn't mean that
[07:54] you should be using large context windows right so all the research shows the same thing which is as the context window gets filled up the effectiveness of the stuff in the context window gets drooed right some people call it context rot right and we need to figure out how
[08:07] to mitigate and manage that problem um and the third one is bloat right LLMs are good at generating content something that used to be really hard and expensive before has to become virtually free. And so I actually worked on
[08:20] earlier versions of this deck with agents, right? And what happened over and over again is you get 25 slides of stuff, right? Maybe it's not garbage, but it's not great. And it's just lots and lots of stuff. And so it's lots of noise. And so we need to figure out how
[08:33] we can constrain agents so that they don't have as any more bloat than is than than is desirable. Um, all right. So we need to solve for these new problems. How do we solve for these new problems? Well, I think the first thing is to think about humans as
[08:46] the scarce resource. Okay, I think everybody's focused on maximizing tokens and all this different stuff and the cost of tokens. I think it's the wrong thought, right? And so when we think about this, we need to be thinking about how we schedule humans time, the experts
[08:59] time in the process because experts humans are not going away. Sure, they're going to be used for some less for some things, but they're not going away. And so what we need to do is we need to focus on synthesizing knowledge before we interrupt. Right? So when I ask a
[09:12] when a when a workflow asks a user to do something, we should make sure that we have as much context for that user as possible. And one of the key things that I focus on is this concept of like a single moment interruption. What I mean by that is is that one of the common
[09:25] patterns that happens is that an agent gets to a summary point and gives you a summary of what's going on, but the summary is incomplete for your ability to make a full decision. And so what you have to do is interrogate the agent multiple times before you get to a place
[09:38] where you have a good enough picture of what's going on to be able to move forward and give the actual guidance to the agent. The problem with that is if we think about attention again is that those loops can take five minutes, right? You ask the agent a question, it
[09:50] goes and does something for 5 minutes and now you have the same context switching problem because once something is getting beyond a few seconds, I'm going to go work on something else. I'm going to go check some email or whatever. And so maybe it's not as bad as working on another completely
[10:02] different track of work, but it's still an intention problem. And so what you want to do is you actually want agents to build up context for the user and questions that answers to questions that they probably will ask or might ask even
[10:14] if they that's throwaway work ultimately because the user didn't actually have an interest in that. But make sure those things are readily available so that when the user is interrupted, they can complete their task all at once. The third thing is what I call scaling the
[10:26] scope. Right? Nobody likes a mega patch, right? It's hard to review. It's just difficult. Right now, people like to write me mega patches, but no one likes to review them. In the agent world, we
[10:39] may be reviewing the patch. Some people still like to review patches. Other people are saying, "No, no, I want to review a narrative of what's going on." The same thing exists whether it's code or a narrative, right? If the narrative gets too big, then it becomes too much at once, right? And so you want to scope
[10:53] manage the scope of what agents are working on so that you have a reasonable scope for people to consume. Okay. Um so what that means is basically many moderate size thing manageable size
[11:05] things as to fewer massive things. Okay. So solving for the coordination problem it becomes clear we just need sharded connected workflows at least from my point of view. I'm come from a certain perspective. I've been building
[11:18] databases. Um but these are really long interdependent processes. This is like a distributed system in disguise, right? We don't talk about agents that way, but it is that it's a bunch of processes working together sometimes waiting for
[11:30] each other, people being involved in what should happen with these processes. And so these are workflows. That's all they are, right? And there's lots of ways that people deal workflows already, but workflows should generally be durable. We should have accommodations for long periods of pauses because a,
[11:43] you know, person's out that needs to be able to respond to something. We should record everything, right? because that allows other people to inspect what's going on. Like if someone's sick one day, it doesn't mean all their work stops. It means that someone else can take over and look what's going on. Um,
[11:56] and if someone, you know, needs help, they have the ability to share that with someone else. Um, and then the last thing is we should shard, right? We don't talk about sharding at all with our code bases today, but I think that
[12:08] that's what we will start to think about is how do you actually break these things into pieces and have agents work on individual pieces separately as completely isolated worlds. So the third thing is is like this agent
[12:21] problem like okay trust and like okay we're drooing the the the the the context these the context and the and and the bloat of agents and the main thing is one don't use agents for things that you want certainty right because
[12:34] they're not certain and that's okay like you know like whatever I'm not going to use the person my plumber to fix my electric my electric my electricity problems right the second thing is embrace the fact that the content is
[12:46] free so that means more exploration Right. But it also means being a lot more comfortable with throwing things away. I still have the problem where I'm like I'm the old world which is like hey it was very expensive to create this
[12:58] thing and so I need to adjust it rather than throw it away and start again. Okay. And so getting comfortable with that ability to say and so as a if you put stuff in this in a durable workflow all of a sudden that becomes really quite a bit easier because you can say
[13:10] okay let me step back you know I went through 15 steps of a process. I realized at step seven we went off the trail just to throw the rest of away, put more context in place and go in a different direction with that context. Um, and the next one is you want to
[13:23] limit that context of what people working on. And this actually works very well with the comment about parallelization, right? We want to achieve paralization through sharding. But guess what? Sharding also helps us for managing the size of context. And so one of the things that happens with
[13:35] agents, right, is if they're doing a crosscutting change, they don't necessarily have the ability I hate I hate anorizing them, but I will there um to uh keep in mind the principles of
[13:47] several different components and how they should work together, right? As they trying to solve a problem at this level and they're going through these three pieces to do it, they will often lose track of the the principles that each of those components are trying to
[13:59] maintain independently in terms of how they work. And so we want to say, hey, let's let's shard that so that each of those things can carry its own principles. Let's see if I can move forward here. And so as we were iterating on this set
[14:12] of concepts, something kind of revealed itself, right? You don't know how ideas come up, but it started to think about things this this concept of of cell what we call what I'm calling cellular development, okay? Which is cells are
[14:25] shards, okay? Um that are durably maintained. So this is the the main concept here of cellular development. So what is a cell? A cell is this sort of like little ecosystem. It's a repos scoped agent runtime if you will, but
[14:38] runtime is probably not even the right word. It's this idea that you have a GitHub repository. That GitHub repository also has local memory associated with it. It can include things like guidance, previous mistakes
[14:50] as well as principles that you want to have for this for this scope. Um, and then you can also have a durable job history for that same context. Okay? And these different cells can all work together to solve the problem.
[15:05] The cell is scoped by its purpose. This cell is trying to solve these problems. This cell is trying to solve these problems. And together we can solve bigger problems. Okay? And one of the examples of how a cell is scoped is is
[15:18] that you generally would only have a single tax tech stack in one cell, right? Right? So you're not going to have node and rust in a cell. You may have five five cells that all have node in them or five cells that all
[15:30] have rust in them. That's totally fine because you want to scope things by their purpose, right? And you want us to find different like nested purpose is fine, right? But that part of that goal is is to size the cells to a reasonable
[15:42] size of context to be able to think things. That means that cells can actually create other cells. Cells can merge with other cells and cells can also split if they become too big and need to separate out their purpose. And so how do you solve this from an
[15:54] actual tech stack point of view? So this is kind of the shopping list that I came up with here, which is is that you want workflows, you want deterministic rules that you can run inside those workflows. You need to have some way to have
[16:06] extensible operations, right? So like some operations are going to be like, hey, run cloud code with this prompt, right? And get back the response, right? Other operations are going to be like, hey, execute this GitHub action to make sure it passes, right? You need to have
[16:18] a CLI for submitting and and running these jobs. You need to have some way to loosely couple cells, right? This idea of a cell, like what is a cell? Well, the conclusion that we came to is is a cell is just a GitHub address. Okay,
[16:30] that's what a cell is. It's a GitHub address, a repo that has some stuff inside of it. And you can reference that and say, okay, I want to open a task. I want to open a task for that cell. I'm just going to submit a task to that that GitHub URL. Um, and you need a way to
[16:43] durably just store job execution, including large large artifacts. One of the key things here is these workflows often generate larger artifacts, right? Traditional workflow engines are not really responsible for maintaining the
[16:55] things that are being mutated and moved forward. They're responsible for giving you a framework where you can just execute whatever you want and you manage the the artifacts externally. Um, we want something that's kind of very sort of central is the management of these
[17:08] artifacts and the movement and the what's changing. And so I'm going to apply on top of that my key constraints which come from my experience of how the kinds of things that I've built, right? And so one of those is that I like simple things. I like composable things.
[17:21] I don't want a monolith. I don't want I want to have to subscribe to some giant concept, right? So as an example, right? Like sure early on we have like hey here's a here's a Postgress table that has a list of the cells and you can
[17:33] manage that, right? But then you're like oh now I got to have a Postgress table that does that and like now I've got this whole system around how cells are managed. you're like, you know what, actually, GitHub URLs is just fine. We already have that. It works well for a
[17:45] lot of different systems already. Um, we want to be spec first as much as possible. And this is go back to like, hey, I you know, I worked on the early versions of iceberg. And one of the great things about that and some of the other part is the same way, right? Which
[17:57] is you start with a spec and then you have implementations, but the spec is the thing. And that means that people can be free to define how they want to implement things themselves, right? Um, you need high extensibility because
[18:09] everybody has their own needs for how they want their agents to work. And you want to avoid stateful demons at all costs because that creates a whole different level of infrastructure complexity. >> And so it boiled down into two main
[18:21] components. These are both in open source as of today. Exposed them on GitHub. I've got links uh in a in a slide in a second. The first is what I call SWF, simple workflow. You can think of it kind of like iceberg for agentic
[18:34] workflows. If you think about what iceberg really is, it's a specification for storage. Okay? And it's a certain kind of storage. It's column storage with schemas, right? This is storage APIs for the kinds of things that you
[18:48] want to understand for durable workflows. Okay? It's designed around an API spec, a reference implementation, and a number of different pluggable storage backends. So, you can use the existing kinds of things that you use.
[19:00] For example, we use Neon to run it most of the time, but you can actually run it in the in the in the most scalable mode, which is Neon plus object storage like S3, okay? And it has APIs like create job, lease job, record the next step in
[19:14] the job because we need these things to be reliable at who's actually executing a job. Um, and also suspend and tell, right? So, if this job realizes it needs three other cells to do work before it can complete its work, it has the ability to say, "Okay, create those
[19:26] jobs. Now, I'm going to wait until those jobs are complete." and we can trust that that will work. >> The second piece, I'm going to go quickly here because I'm running out of time. Um, the second piece is C2J. It is the system that allows you to run jobs.
[19:40] Okay? And it runs on top of SWF. Now, SWF is simple enough of an API. It's about 15 uh REST APIs that you can implement one in in a half an hour or an hour by hand, right? And it wouldn't be a super sophisticated great one, but it
[19:52] would be okay. And so, CG C2J is designed to run on top of that. It's a paradigm for how you actually create a workflow and have steps. And the idea behind it is is that you have recipes. A recipe defines what you want to get
[20:04] done. Inside of a recipe, you have operations, state machines, sequences. You combine those together to have a series of steps that you want to complete. Every operation that occurs is persistent. And persistence includes the
[20:17] git a git commit associated with that operation as well as any artifacts that have been outcome from the operation. So as a concrete example, when you're thinking about like working on iterating on design documents, this question comes up which is where should I store the
[20:29] design documents? Some people store them in the git repository with the code um I think that that's probably the wrong pattern because they are moving in a different order and it's kind of confusing to have the two of them together. Not to say you want you want
[20:41] them nearby, right? But they're it's different than a code code review. Um so everything is recorded. Uh so the way that they work together and the vision that we have is is that this is the new stack for how you work
[20:54] with this stuff is is that you're going to have get just like you did now but you need this S SWF you need some kind of agentic common layer for storage of agentic workflows and the execution information associated with those things
[21:06] that is your data that is not locked into any specific proprietary storage system um that you can then build whatever tools you want to interact with that data because it's one of your core uh values inside your organization.
[21:19] So those are the repos. The top four are the things that I talked about. So the first one's S SWF. I think that's wrong. Actually, that should be S swf-go. If you go to the con2 website, it's correct. I forgot to correct it here. The second one is C2J. Um, you've got C2
[21:33] ops. This is individual examples of operations. As I said, they're just little executables. They have input and output that are JSON schema formed. And so you can create whatever you want in any language. There's some Python and Go versions that are examples inside of C2 Ops. Um, and then the recipes themselves
[21:46] are the ways that you combine these things together to solve problems. And in this example, we have an early version of the superpowers plugin reimplemented using recipes there. So if you're familiar with supercell plugin for cloud code, same pattern built in
[22:00] this in this in so same workflow pattern but built in this this metaphor. Um, there's a couple other things there that uh I didn't talk about today that we're working on to kind of think about how to solve these other problems. Um, yeah,
[22:12] everything's open. I'm going to leave you with three things to think about that are problems that we're still trying to figure out. Okay. The first is the redundancy paradox. The redundancy paradox is basically I learned it when I was learning about data centers. And so
[22:24] data centers try to make themselves very redundant. And so they create systems upon systems to solve redundancy. And as they add more systems, things get more complex, the interactions get more complex. And so they actually increase the failure rate because humans can no
[22:37] longer intuitit what would happen if this changes and that how these things interact. Okay. And we have the same problem with agents. The natural tendency is you see if there's a problem with how your agent's working, so you add another agent on top to solve that
[22:50] problem, and then you add another agent on top to solve that problem. And so we get layers and layers upon layers of agents, um, LLM loops, if you will. Um, and that creates a bunch of weird dynamics that we don't fully understand. And so figuring out we need to get
[23:03] through the next 10 years. I mean that takes two years maybe to figure out what are the right number or recursive number of agents that should be interacting and how many different scopes of sessions we should have. The second one is goodart's
[23:15] law if you're familiar with it. It's basically the concept that if you set a metric systems are really good at optimizing for that metric at the cost of everything else. Right? So you tell a robot hey I want to make sure that humans don't kill each other in wars so
[23:27] the robot kills everybody so that humans can't kill each other in wars. Right? That concept happens with agents all the time. How do we do that? If you give it a test suite, it's going to make sure the test suite passes and that that may not exactly want because there's other
[23:39] spirit that hasn't been captured in that test suite. And the third one is actually a I think of it as a UX problem. >> How do we achieve zoomable context? If this big problem is is that I have to
[23:51] move around between different things and when I move to something I need to re remember what's going on with it, how can I do that effectively? What I want is I want something like Google Maps, right? Like you may have a point on Google Maps, but you can look at the
[24:03] world and then you can zoom into whatever level. You can look at the streets. You can look at the neighborhood. You can look at what are the grocery stores nearby. You have that ability to sort of probe at the places where you want to. Unfortunately, that works for spatial. We haven't figured
[24:15] out how it works for text, right? Like if we're talking about text content and I want to zoom into this bullet point to understand more about it, how does that work? Um, and that's something else that we're working on. We have some early prototypes on, but it's a hard problem.
[24:28] So, anyway, that's what I have. Thank you. I went a little bit long, but I appreciate you all staying. I'm happy to answer questions. There's nobody else here for another 20 minutes, but I can't answer questions this way because I have we have no microphones. So, anybody who
[24:40] wants to chat afterwards, I'm happy to. So, thanks everybody.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.