Building Autonomous, Always-On Agentic Systems on Databricks
Summary
- This video explains how to move beyond reactive chatbot agents to build always-on, event-driven agentic systems that continuously monitor data, reason through exceptions, and act autonomously using Structured Streaming, Model Serving, Lakebase, and Agent Bricks on the Databricks Data and AI platform.
- The OODA loop framework — Observe, Orient, Decide, Act — is presented as the design model for autonomous agents that respond to business events in real time, illustrated with a supply chain anomaly detection example featuring two live demos.
- Key patterns include multi-agent supervisor and parallel execution architectures, stateful task queuing and high-concurrency routing with Lakebase, durable execution for long-running agents, and human-in-the-loop escalation for high-stakes decisions.
Building Autonomous, Always-On Agentic Systems on Databricks

Agentic commerce could drive up to $1T in retail revenue by 2030, but the real opportunity spans every industry. Most agentic systems today are still reactive, relying on chat prompts. True transformation requires always-on, long-running agents that monitor data, reason through exceptions, and act autonomously.
In this video, we’ll walk through how to build asynchronous, event-driven agentic systems on Databricks using a supply chain example. Learn how to move beyond chatbots to resilient, system-to-system workflows by orchestrating Structured Streaming, Model Serving, Lakebase, and Agent Bricks.
Key takeaways:
• A scalable design pattern for long-running, event-driven agents
• Always-on anomaly detection with streaming + ML
• Stateful task queuing and high-concurrency routing with Lakebase
• Multi-step agent reasoning with tools and safe execution
• Evaluation and human-in-the-loop escalation for edge cases
Talk By: Krishna Rupanagunta, Senior Director, Databricks ; Sathish Gangichetty, Lead Solutions Architect, Databricks ;
Chapters
00:00Introduction: beyond chatbots to always-on autonomous agents01:10The OODA loop: observe, orient, decide, act for AI agents03:02What makes an agent truly autonomous: tight, durable loops06:01Always-on supply chain: the first agentic architecture pattern07:07Multi-agent patterns: supervisor, loop, and parallel execution09:11Architecture: Structured Streaming, Lakebase, Agent Bricks, MCP12:09Demo: real-time supply chain anomaly detection agent16:08Human-in-the-loop escalation for high-stakes decisions17:12Marketing use case: personalized campaign agent21:00Durable execution and state recovery for long-running agents24:04Dynamic scheduling: outer and inner agent loop patterns26:09Key takeaways for designing always-on agentic systems
FAQs
What is the difference between a chatbot agent and an always-on agentic system?
A chatbot agent is reactive — it waits for a user prompt before taking action. An always-on agentic system continuously monitors data streams, detects anomalies, and takes autonomous action without human initiation. This video shows how to build this second type of agent using Structured Streaming on the Databricks Data and AI platform for event detection, combined with Agent Bricks for reasoning and action.
What is the OODA loop and how does it apply to AI agents?
The OODA loop — Observe, Orient, Decide, Act — is a decision-making framework adapted in this video as the design model for autonomous AI agents. It describes how agents should continuously monitor events, build situational context, choose from a portfolio of actions, and execute those actions in a tight, durable loop.
How does Lakebase support stateful agent workflows on Databricks?
Lakebase provides a lakehouse-native database that handles stateful task queuing and high-concurrency routing for long-running agent systems. This video demonstrates using Lakebase as the state store that allows agents to maintain context, queue tasks across concurrent requests, and recover from failures during extended autonomous workflows.
How do you handle high-stakes decisions in an autonomous agentic system?
This video recommends designing human-in-the-loop escalation paths for edge cases where agent confidence is low or potential consequences are severe. Rather than blocking all decisions, the architecture allows the agent to act autonomously within defined boundaries while routing uncertain or high-impact decisions to human reviewers.
Full transcript
[00:08] Hey, thanks everybody for coming. Um quick disclaimer before we start. This is not going to be about coding agents. Uh what we're trying to do here is talk about agents that can uh help in business workflows. So, that's you know, let's get out of the way. We don't want
[00:20] to talk about coding agents. Quick intro. My name is Krishna. I'm part of the AI specialist org. Satish. >> Uh hey guys, my name is Satish Annamalai. I'm a practice lead for AI/ML in retail, CPG, and travel. We talk to a lot of customers and we
[00:33] tend to observe a lot of these uh in the wild. And what we try to do is try and bring this into a single talk and give you the architecture patterns. Uh hopefully you find this interesting. Let's start it here.
[00:45] >> Yeah, we have a few slides and a and two demos. And what we want to do is go through that and what we really leave time at the end so that if you have questions, and we hope you'll have questions. Um you know, feel free to you know, hold
[00:57] on to your questions till the end and then, you know, we can spend some time on questions. Okay, so just to get started, right? Um I'm a big, you know, history buff. Uh study military history. So, love to have a conversation after this.
[01:10] But one of the things that, you know, the picture that you see here is there's a pilot who fought in the Korean Vietnam War. And one of the key things that he observed was that the the planes the the pilots
[01:24] that did they tend to do well in air-to-air combat are not the ones who are flying the best planes or who have the best weaponry. But who are who are behaving in a combat situation in a certain way.
[01:36] And he came up with this term called the OODA loop which which got adopted across um you know, multiple disciplines in in game theory, in in management consulting, and so on. Um the reason I thought, uh you know, we
[01:49] thought this could be interesting to start with is we see a lot of what how we behave, how we want agents to behave in real life situations in a similar fashion.
[02:01] Any typical action that you want to take needs to start with an observation because there are events that are happening around around the agent. The agent needs to be able to observe those events.
[02:13] Once you observe those events, this next step logical step is an orientation. How do you orient the agent how does the agent orient itself to the situation around? How does it become situationally aware? How does it get the
[02:25] context? And once once it does that, we want the agent to be able to decide among a portfolio of actions what's the best thing to do and then go out and take that action.
[02:37] And then continue in that in that loop. And what we're going to talk about today is how do we you know, how do we think about agents that work in this kind of an environment, right? So, put it to the next slide.
[02:49] So, really what we think when we talk about an autonomous agent, so that's a it's a system and that's a key word we'll come back to later that that observes, orient, decides, and act in a tight durable loop. The tight and
[03:02] durable are also key and we'll double click into that. Without necessarily waiting for human prompts and that's the key here. We've all built chatbots agents that can interact on a on a Q&A
[03:14] basis, but what we really want here is agents that can operate independently and inject humans into the loop on an as-needed basis. Yeah.
[03:27] And why is this important? So, let's you know, look at three you know, examples. So, the first one is is what we see a lot these days, agent to commerce. So, these are you know, think of these as always-on supply chains.
[03:40] There are shopping agents that might ping your supply chain with a business request for for a shipment. And the agent needs to be able to respond that in an in real time
[03:53] asynchronously as well because that's a task that you want to set the agent off and it it it it goes, completes the task and and provides a response. And these agents need to be always on. Because you know the
[04:06] the shopping agents can work can wake up, you know, present an order at any point in time. So So in this scenario, we want agents that can work in the background which are always on. The second case is, you know, let's take
[04:19] an example of personalized marketing, right? So this is um again agents that can, you know, think of an agent that can work a campaign life cycle end to end. So you you give it a campaign objective,
[04:31] it starts off a campaign, it executes a campaign over the life of the campaign, it's looking for some signals, um some events and if based on what the event is, it might need to pivot. And
[04:43] when it pivots, it needs to wait and for a for a period of time to see the impact of a change in, let's say, a campaign channel mix or whatever. Right? So we want the agents to be durable here. So durability is an
[04:57] important um requirement here. So that's, you know, example two. Example three, you know, is a more systemic approach. So uh so I I grew up in the world of supply chains, sales and
[05:09] operations planning for anyone of you who's who's done that before or has been involved with that before knows that this is easily one of the most complex processes in an organization. It is again something that needs to run
[05:22] over an extended period of time, starts with a human objective, it could be a business goal, and then over a period of time there will be a series of agents which need to uh reason, act, and then
[05:34] keep on repeating themselves um over an extended period of time and checkpointing intermediate and final goals all along the way. So these are, you know, some of the scenarios that we see out out in the wild of of agents.
[05:47] Now with that, you know, I'll hand it over to Satish to talk about Oh, yeah. So, let's let's take, you know, before we get into the demo, want to set up, you know, what an always-on supply chain looks like, right? So, imagine,
[06:01] you know, a B2B retailer, they get a large order. Now, a large order could be an outlier. A typical order can be run through with your with your standard processing systems. Let's say there's a large outlier order, which is what a
[06:15] signal-driven activation needs to think about in the observe phase. And once um that external event, which could be a large order, comes in, then the agent needs to pick that up, things need to
[06:28] think about what is the state of the supply chain. So, that's the orient piece, right? It needs to reason about the the available inventory, the network policies, and so on. And then, the next step is it'll it'll have to
[06:41] decide on what's the best course of action. There could be multiple, you know, fulfillment strategies possible. What's the best option to take? Make that decision based on some guardrails, some business criteria that are set up. And then, once it once it
[06:54] does that, um it needs to go back and act on it, which is essentially trigger out um a fulfillment order to an execution system. And then, come back after a period of time and measure the impact of that. So,
[07:07] that's sort of an always-on supply chain, which is running end-to-end. Now, with that scenario, let's get into how it actually works in the demo. >> Yeah. Okay. So, before we get started, I just want to make sure that everybody is grounded on this reality in Databricks.
[07:21] Like, how do you compose agents on Databricks? A lot of these primitives are things that you guys probably used on Databricks. So, what makes agent possible? Of course, you need a runtime that gives you a reasoning loop powered by models,
[07:34] memory, tools, and resources. But then, the first part is like, how does it think? You have a model, the orchestration layer, and the runtime engine. All of that stuff comes from Unity AI Gateway. You pick your poison
[07:46] pattern. The more popular ones are things like, you know, supervisor pattern, but you can also run loops if you want. Uh and then the agent frameworks, you can pick anything that you want and then use uh MLflow to trace
[07:58] them. When it comes to memory and state, the answer here is Lakehouse. Uh state for both managing agent state, but also for managing workflow state. You know, if you haven't heard about workflow state,
[08:10] we'll talk about that in just a second. This is going to be super important for all the durable properties that you get to see in the demos. The demos don't cover like all of the scenarios. It's just to highlight a few of those durable properties that you you
[08:23] want to think about as you you know, as you think about okay, I want to deploy a long-running agent in a particular line of business task. Here's what you want to think about. And then finally, what it does are MCPs and
[08:35] skills, right? So, these are things that are, you know, back to Unity Catalog. You get to see the same thing in your or Unity AI Gateway. Uh you've probably heard about Ali talking about this in the keynote this morning as well. So, then cross-cutting across all this
[08:47] is going to be trust and governance imposed by uh guardrails imposed by Unity Catalog, Unity AI Gateway. Observability, we talked about MLflow. And there's like a billion agent frameworks at this point that MLflow
[08:59] allows you to trace. Uh evals come through MLflow evals. And then cost and rate limits through Unity AI Gateway. All of this is inside your Databricks workspace. You already have access to this.
[09:11] And this is the foundational primitives that we're going to use to show you the thing that Krishna was talking about in the supply chain use case. And then secondly, we'll do the marketing use case as well. Okay? So, the first one
[09:23] is the always-on uh autonomous agent for supply chain. Uh sick. Yeah. So, before we go into the actual demo, I want to show you this agent loop of what it's doing. So,
[09:37] think about this. We're going to have a UI and the UI itself is manifestation of this workflow that we're talking about for the always-on agent. This UI can be probed by a human, you know, a task
[09:49] upstream or another agent. It hits a fast API endpoint and then it creates a task in Lake Base, which manages the state of this particular task. An always-on worker picks it up in the background. So, why
[10:02] we do this? We because we want to decouple the front-end client from the back-end process. The process can take forever if you want it. Uh especially if you have human in the loop, it's going to take a long time. And then you pass it off to the agent and the agent can use the tools, the
[10:15] role, the goal, the backstory, and all that stuff, and um uh and the skills for it to dispose of uh decision. And what in in in here, what we're trying to do is we're trying to show you
[10:27] a simple criterion to decide whether or not we want to route to a human being. And that criterion being confidence. Like, how confident are you in the decision, agent? But in reality, it could be a whole whole a bunch of use cases, a bunch of rules that you run,
[10:40] maybe things based on cost, things based on some business policy that you determine, right? So, if if you're uh if you're sure about that, just go ahead and make that change in the auto management system. If not, go ask a human being. This case it can be wired
[10:53] up to Slack, Teams, whatever uh to make the journey simple here. I'm trying to show this through the lens of the control tower UI. We'll get to that in just a second. And also notice, show of hands if you heard about Genie ontology
[11:06] this morning and in any of the talks. We're going to use the Genie MCP uh here as a part of it. What it allows you to do is allow you to take advantage of all the assets that you've painstakingly curated in Unity Catalog. These are
[11:19] first by first party, like, you know, objects like your tables, your functions, your skills, um and practically anything that Unity Catalog can take, but also external uh tables through federation and
[11:31] whatnot, right? So, this is what we're going to do. We're going to actually try and write all this all this all the traces into MLflow as well, and you'll see uh that manifest in the demo. So, I'm going to launch the demo. And for simplicity's sake, there's like
[11:44] a lot going on here. Uh I want to highlight a few things. This is all of this is like deployed to a Data Works app. And there is the back end running on, you know, fast API and all that. Um we'll share the code with you uh later on, but my point is
[11:57] and notice the agent loop at the top, it's still a workflow. What happens is there's like a bunch of scenario parameters. This could come from, like I said, another human or it could come from another agent, but could come from
[12:09] a real-time stream processing workflow. At any given point that we have any out uh outlier, what we end up doing is we trigger this event. As soon as the event triggers, what you see on the left side
[12:21] here is Lake Base accepting the workflow and then releasing the client. In the back end, the agent starts running. It, you know, pulls a bunch of different functions, and you see also pulls Genie
[12:33] MCP, uh also looks for things like, "Hey, what inventory do we have on stock right now? Are there any open orders that we have access to right now? Uh what about the demand signature? Uh
[12:45] this upstream uh thing is telling I should say actor is telling us that there is going to be a spike that we need to prepare for. And what can we get from a supplier reliably?" And based on that, it is going to figure out a few
[12:57] actions. One is are we able to pull or, you know, pull in some of the orders? Or do we need to expedite a few things? Or uh what is whatever the disposition is, it's going to try and figure that out, right? So, you can see it's it's taking
[13:10] some time. At the bottom, there is this elapsed time as it goes through this part right now. So, as it works through these things, I want to also highlight that notice this is just an example. In a real-life scenario, you're probably
[13:22] going to have News MCPs or like maybe for that region or weather MCP for supply chain for example. These are events that you want to figure out like uh
[13:34] insights into at the time of and then finally you get a decision that's disposed of. Takes a little bit about like you know a little over a minute but if you look at the reveal decision part you get the auto approval because it's
[13:48] like super confident about this and the reasoning behind that and it saves that to agent memory. There's also an A2A uh you know uh endpoint that you can actually probe. This uses Agno by the way on Databricks.
[14:01] It's all traced into MLflow tracing. Here's a trace ID. We can go into that in just a second but this is not life is not always going to be the simple. You're going to have situations where this is again I'm
[14:13] trying to program this in a way that it auto generates this a human in the loop situation. So this is a scenario for that. Let's go through that one more time. This time around with human in the loop. When we do this once again
[14:26] the workflow gets accepted. There's a task task ID that gets generated and then use on a based on the task ID a worker is disposed of dispatched off and this worker now does the same thing that we did last time
[14:38] but except this time around what you're going to see is that the outcome from the agent is going to be lot less confident. Because it is not confident about this this thing it could go ask a human hey what do you think about this?
[14:50] This is what I think. Do you approve of this or not? And notice like we talked about the action itself. One of the actions there is if the human approves it is going to go and make the order on behalf of the user on behalf of the human in the order
[15:03] management system. All it takes is an MCP that you hook up to the like you know to the agent framework and now you're off to the races. The big key takeaway here is if decoupled the front end whatever is calling
[15:15] to from the back end where the brain functions and you're constantly giving this brain access to context either curated through the Gen Ontology or based on some logic that you think is appropriate that encapsulates the
[15:28] business logic here. But also you can see Okay, by the way, right now, as you can see here, it's saying, "Hey, would you want to approve this or not?" It did that in 70 seconds. But I can this this is a this is a
[15:42] failure point. This is the whole point here is we want to show you that some of these demos are not not demos Some of these projects can fail if you don't think through them properly. For example, this human in the loop stuff if you're doing a workflow agents, the
[15:55] human may not even see it for multiple days. But what happens when the entire container goes down? What happens when you know, the human never disposes of anything? You know, there are there are things you
[16:08] need to worry about, but in this case at least I go approve of this. And now instantly it goes through this and shows me a decision that was made. A review was required. Here's the reasoning. And the same thing follows follows follows, right? So, the idea there is
[16:22] that the event is that the human needs to approve of this, but almost all cases in most business cases the event is going to be time-based or some kind of business events-based.
[16:35] As an example, when you talk to your manager in a one-on-one meeting I'm just trying to make this super simple for you to map onto mental model standpoint. When we talk to your manager, you hold
[16:47] that in your head context, and then later or 2 weeks later, you you converse from that point on. The thread picks up from there, right? So, you need to do that with your workflow agents across all of the events that you end up
[16:59] seeing. That's the whole point here. But let's let's keep going. Like right now, we have the scenario where the disposition happens instantly and you are able to say, "Yes, I approve this." or "No." But in the second use
[17:12] case that we're going to see in the marketing use case Uh, a real need, right? So, if I'm, let's say, trying to shop on e-commerce site and you're trying to engage me, the equation there is I don't really
[17:25] expect to be controlled by your technology, but in reality, that's what you're trying to do. You're trying to get me to behave the way that you want me to behave, and increase my chances of converting through that
[17:37] funnel. So, that means what message do I give them, when do I give them, becomes super important. So, we'll say we'll see that in just a bit. >> Just to add to that, right? So, the the when piece is super important in this scenario, the second scenario we're
[17:49] going to look at, because temporality becomes a an important requirement, because there are decisions that that need not be made in the in this instant or right away. There is a certain waiting period
[18:01] that you need to think about for making a decision. So, for example, in in the case of campaigns, like I was saying earlier, you the agent figures out a pivot to the campaign. Let's say a channel mix is not working or a certain messaging strategy
[18:13] to a customer is not working, and they want to change that messaging strategy. Once that change is made, there is either a a period that you want to wait before you want you want to re-evaluate that strategy. So, there is a time element
[18:27] that you that the agent needs to think about, and that's where the notion of durability comes in. So, let's take a look at this. All right, so we'll launch the demo. This is through the lens of one user, because it makes it super simple, because otherwise, if I were to show the same through a workflow, it
[18:41] becomes really really hard, right? So, let's call this user Cindy, because that's what Claude likes to name all the user users. I don't know if you tried it. Cindy Chen is the name always. But, my point is, like in here, you're going to go you know, in this in this
[18:54] example, we're going to take the role of a company called Fluttershy. You know, no prizes for guessing what this company could be, and Cindy would go in here and purchase photo books for her cat, Mr.
[19:07] Mr. Whiskers, yeah, Mr. Whiskers. And then the idea here is that she would a picture of a cat. And now she has like momentary matches like for based on the cat how the cat looks.
[19:19] Maybe I'll select this thing this product. It goes to cart, but let's say this is like 11:30 in the night and then Cindy falls asleep. She doesn't convert, right? There's like a bounce
[19:31] event that happens and what happens in the background is an event gets triggered. And Durex now needs to I mean our process now needs to figure out the ID of this person and then figure
[19:45] out what product they left behind. These are all tool calls by the way. It shows sequentially because it's easy for you to absorb, but it can differ based on a customer not to another customer. The idea here is, you know, any a particular
[19:57] customer could be enrolled in multiple campaigns and the and we need to be able to figure out what the right campaign is to trigger so that this person can re-engage in this process of converting. We need to also exclude this person if
[20:10] there was like active complaints or something else that's going on with customer service, right? And notice what happens here. At this point the agent's like running this at like 11:58 or whatever the time is in the night time and it determines,
[20:22] okay, so this is not the time we should contact her. Watch this thing at the bottom. It takes the workflow state. It takes the agent state. Process that into the database. And it goes to durable sleep for how
[20:34] long that is. Of course, we cannot be watching this for 8 hours, so I made this between, you know, 15 or 20 and then it goes through and passes the entire agent state into the subsequent agent which then goes again and compose
[20:48] of this email. But notice what happens if you do something like this. If there's durable sleep, it's possible that Cindy could have woken up at 2:00 a.m. in the morning and click that button, right? So you need to re-ensure that there is no goal drift that
[21:00] happened. So when you start again, you need to have everything that the agent did, but also corroborate that is this the right thing to do continuing forward, right? It was all happening. So, the whole idea here is what would
[21:12] have taken a marketing team, you know, if you imagine this as a workflow that spawns off these kind of agentic runs in the background. Now, you're able to really do interesting things to re-engage
[21:24] customers, So, that's the idea here. Um that's our second demo, but now what makes agents durable? There's a case for
[21:36] autonomy mandating durability because of all the things that we talked about, right? So, it's not just the agent state, but it's also the workflow state. We talked about the whole fire and forget injection pattern, you know, fire it off and, you know, we'll pick it up
[21:48] in the background and we'll do the things that we need to do. Oftentimes, you might for long-running agents especially, depending on the use case, you might have to make your little tool calls durable. You might have to checkpoint the tool calls.
[22:00] Nobody wants to be in a scenario where something runs for 2 hours and something fails, and then what you have to do is like start from scratch again. You know, it's like cost implications, quality implications, you know, are we going to go down the same path? All
[22:12] those things uh matter, and so you try and do this one time, checkpoint everything, uh depending on the use case again, and then keep going. We talked about Gold Drift. We talked about guardrails. We actually even showed you the human in the loop
[22:24] example. Uh on the right side just shows you some pseudo code basically saying, "Hey, you can persist this entire trace into MLflow." Uh and then fire off based on an event.
[22:37] Uh we use DBOS in the background for workflow durability. It's an open source package. You can use it. And then we don't have any prescriptions. It could be DBOS, uh re-re-restate or temporal. Any of those things, you
[22:50] know, whatever you want want to use is good. We actually have our own product in the space that's coming. Uh it works really well in the space. It works gels well with lake base. Um you know, I'm not going to spill the
[23:02] beans for product right now, so but it's coming. Uh The idea here is once you the the key thing that makes all of this possible is Lake Base. The fact that you're able to persist and
[23:15] make these choices for your use case uh depending on whether it's going to be atomic checkpoints for every agent tool call or the workflow or just the task, you know,
[23:27] that's that's down to you. Krish >> All right. So, So, if you now take a, you know, step back and zoom out a little bit, what are the you know, some of the you know, the meta pattern that we're
[23:40] seeing in these kind of implementations, right? So, first is you know, think of this as, you know, an outer loop inner loop kind of a, you know, format because one fundamental factor is that every one
[23:52] of those agentic loops, you know, are expensive because you're calling LLMs, LLMs equal to tokens, tokens, you know, you know the story there. So, we want to be mindful about when to invoke the what we call the inner loop,
[24:04] which is where the you know, the agentic um you know, workflow kicks in. So, one pattern is, you know, have an outer loop which is deterministic and which is actually looking at, you know, the environment outside, looking
[24:17] at signals and figuring out, you know, should I pay attention? And make that call and once it does, then you invoke the inner loop which which actually kicks off the agentic loop, right? So, you know, two loops, two time scales,
[24:29] that's you know, sort of principle one. Um the outer loop is, you know, think of that as, you know, the attention manager which is try which is looking at, you know, when should I pay attention? And that also is is self-tuning because over
[24:41] time you can you can adjust those guardrails as to when you want to call call your inner loop. Yeah, the second thing is, you know, the obvious reason why you want to do this is, you know, your gatekeeper, your
[24:54] outer loop could be a deterministic function where, you know the the cost of computers is is significantly you know lower as opposed to bringing in a reasoner at at every point in time. Um the third piece that you want to
[25:07] think about is a dynamic scheduler because over time you want you want the outer loop to learn and make sure it's calling the inner loop for the right scenarios. Yeah.
[25:20] And then you know the element of self-tuning because you're looking at the outcomes. Every one of these business decisions needs to be tied to a KPI that you can you can instrument and measure and use that to for this entire loop to, you know,
[25:32] continuously improve. >> Yeah, I think you know there are three things I would highlight, you know, when you're thinking about these kind of like long-running agents. Make sure that there's a background mode. I'm not talking about coding agents. There's already, you know, loop engineering
[25:45] that's happening where you can run things in the background. Think about this for your business process agents as well. You want to make sure that you fire off a request and then this thing happens in the background for however long it takes. Um it might mandate human in the loop or
[25:57] not, but the first step there is to make sure that your client's not hooked up to like the server in this like coupled way. Secondly, durability is a design choice.
[26:09] You know, we showed you two examples of how that manifests. Uh it could be in in you know, like I said, in the task level, the workflow level, or the agentic loop level. Finally, observability is a not is not a
[26:21] choice, especially if it's acting on your behalf. It's acting on the user's behalf. You want to make sure exactly why it did what it did. Uh and not to mention that it actually runs for extended periods of time, right?
[26:33] Um so yeah, but the big takeaway here is this. I think the punchline here is this thing that's coming up. So we are thinking about you know, hey, what does all this mean in the context
[26:46] of you know, the humans versus um agents in in in a business workflow scenario, right? So, if you think about, you know, how let's say a supply chain planner, how you know, a campaign
[26:58] manager operates on a, you know, on a on an ongoing basis, they bring a certain set of skills, use a bunch of tools. These tools could be dashboards, reports, and so on. They have They have memory. Memory could
[27:11] be individual memory, could be organizational memory, which is which is what is called the tacit knowledge. Um and the context keeps changing based on, you know, external signals like, you know, the weather events and so on and so forth. And then
[27:24] um it's usually a coordination problem. It's not that, you know, an individual is operating towards a campaign or towards a supply chain problem. Um they're coordinating across multiple multiple actors
[27:36] uh all trying to hit a durable goal. It could be like a business goal as to, you know, order OTIF in kind of for a supply chain order or a campaign goal, and so on. So, all of these put together, what
[27:48] makes a successful business process? And if you want to translate that into the world of agents, >> Yeah, I mean, it you see the same thing happening here where you can, you know, capture the, you know, collect the
[28:00] skills, uh figure out the goal for the agent, give it the appropriate tools, make sure that is able to manifest this durable goal, um you know, architect for durability, ensure that it's able to remember what
[28:13] it did in the past. Then, you give it the context dynamically depending on, you know, what context is useful when. And then you can orchestrate it based on the appropriate use case, whether it's a loop or whether it's like an actor
[28:26] critic uh setup or whether it's just a traditional react agent type thing, right? Uh the idea here is that you can actually you know, use these agents to create massive economic value. We are at the
[28:39] early stages of it. You're only probably seeing, you know, some of these blogs being written publicly by the large labs, if you will. But now I think over the next one or two years it kind of will see
[28:51] agents evolve from being just simple conversational agents to workflow agents that are capable of doing meaningful things that can deliver value.
[29:04] I mean ultimately what you're trying to Yeah. >>
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.