Sponsored by: Insight| Beyond the Sandbox

Summary

Lakebase's Instant Branching creates zero-copy, isolated database clones in seconds, allowing AI agents to safely propose changes without writing directly to production.
The architecture uses pgvector for agent short-term and long-term memory and applies automated pre-flight validations and AI/BI impact analysis before merging approved changes back to the primary database.
Lakehouse Sync maintains a full audit trail and keeps changes synchronized for downstream analytics and compliance, giving teams a concrete Git-for-data safety net for high-stakes agentic workflows.

Chapters

FAQs

What is Lakebase Instant Branching and how does it work?

Lakebase Instant Branching creates a zero-copy, isolated clone of the operational database in seconds using copy-on-write semantics, where branch creation is just a metadata record. Both the branch and the production database read from the same storage pages until a change is made, keeping the operation fast and cost-free.

How does Instant Branching protect production data from AI agent errors?

When an autonomous agent needs to update pricing or records, it writes to an Instant Branch rather than directly to production, where automated pre-flight validations, business rules, and AI/BI impact analysis run first. Only approved changes are selectively merged back to the primary database, preserving data integrity.

What role does pgvector play in the Lakebase AI agent architecture?

pgvector is used within Lakebase's serverless Postgres to store and retrieve agent short-term and long-term memory, enabling the agent to maintain context across sessions. This allows the autonomous pricing agent to recall past decisions and apply consistent reasoning over time.

What industries benefit most from the Git-for-data agent architecture?

The Git-for-data workflow is especially valuable in high-stakes environments such as finance, healthcare, and other regulated industries where agent errors can result in compliance incidents or significant business consequences. This video provides a concrete safety net — not just marketing guardrails — for organizations giving probabilistic AI systems authority over deterministic data.

Full transcript

[00:08] My name is Jared Forney. I'm a data architect with Insight and um I'm going to show you a pattern that I think solves one of the hardest problems in uh AI agent deployment. Um it's how you let
[00:20] an autonomous agent write to production data without losing sleep at night. Right? So, we're going to look at uh Lake Base's instant branching feature and how it creates a safety net that
[00:32] lets agents be truly autonomous while keeping humans in control of what they actually uh what actually reaches production. So, let's dive in.
[00:50] So, um one quick little legal note here, blah blah blah blah blah, not all this stuff is going to work in the future. and you know all that stuff. I'm sure you've seen this about seven times a day. Um so let's start by framing the problem that we're solving. Over the
[01:02] past 18 months, autonomous agents have moved from research demos into production workflows, booking travel, filing tickets, moving money, and increasingly making decisions that used to require a human in the
[01:15] loop. Um, that shift is exciting, but it also is very scary and it changes a risk profile uh drastically. So, when an assistant gets a sentence wrong, the cost is just a retry, right? You're
[01:28] chatting with a chatbot, it messes up. No, no, no babies die, nothing bad happens. Um, but when an agent gets an action wrong, the cost can be a a refunded customer, a compliance
[01:41] incident, or even a major headline. And here's the uncomfortable truth. Today's agents are confident in ways their accuracy doesn't justify. So they will happily execute a
[01:53] destructive action on the basis of a hallucinated tool argument, a misread document, or a prompt objection buried three pages deep in a PDF. So the failure modes aren't rare edge
[02:07] cases. They're predictable consequences of giving a probabilistic system deterministic uh authority. So you've got this probabilistic process. You don't know what you can't recreate the
[02:19] same um result every single time and you're giving it these uh immutable deterministic you know ability to affect change that you know that's permanent.
[02:31] So the question we want to sit with for the next few slides is this like what does a safety net actually look like for an autonomous agent operating in a high stakes environment? um not guardrails as a marketing term,
[02:45] guardrails as a concrete architecture. We'll walk through where today's approaches fall short, what a well-designed intervention uh layer looks like, and how teams and
[02:57] regulated industries are putting these patterns into production right now. So, here's what's happening in 2026. AI agents aren't just answering
[03:09] questions uh anymore. They're they're actually they're taking actions. I mean, that's definitionally what an agent is. So, you have an L&M, an LLM, it has the ability to affect change. It is officially an
[03:21] agent, right? So, they're taking these actions. They're updating inventory. They're modifying prices. They're triggering workflows. They're doing all kinds of stuff in your environment. And that's kind of terrifying for anyone who's been in uh you know, on call when
[03:34] a bad deploy hits production. someone calls you, it's always it's always two in the morning. I don't know why is why why are they always calling at two in the morning? Um the guy
[03:46] they're going to call at two in the morning." And I'm like, "Well, it's better than not having a job and them not calling you at all." Right? So, um so think about a single pricing error. Say an agent sets a $500 product to $5
[04:00] and within minutes you get thousands of orders at the wrong price. That's not a hypothetical. This thing happens, right? So, that's a major monetary impact to your company. The question we need to
[04:12] answer is, how do we give agents the autonomy that they need to be useful while maintaining the safety guarantees that production demands?
[04:26] So, here's the fundamental tension. On the left, we have operational systems, OOLTP databases like Postgress where agents need to act. And then fast reads, fast writes, acid guarantees. This is where the real- time decisions happen.
[04:40] On the right, we have the analytical systems, OLAP platforms like Delta Lake where we verify, where we run reports, train models, and make decisions. Traditionally, these are completely
[04:52] separate worlds. Different storage formats, different query engines, different teams, and bridging them requires complex ETL uh ETL pipelines that introduce hours of of
[05:04] of delay and latency. So, this is a classic problem. My vice president asked me today, "What's the most impressive thing you saw from the keynote?" I said, "It's lakebased for sure." And he goes,
[05:17] "Why?" And I said because this is a problem they've been trying to solve for 40 years. This problem this OLTP versus OLAP the HTAP the L like this is this has been the bane of our data existence
[05:30] for a very long time and it seems like they might have cracked the code right so this is a big deal. Um they call it the two stack problem like you have to have two separate platforms. One to
[05:43] write and read quickly and have low latency and a whole another set of of data to be able to aggregate be able to store in a columner you know with columner compression and to do
[05:57] analytical reporting on. So this the fact that these two things live in two different places has always forced us to move the data around which is pipelines and everybody knows how fragile those things are and anybody
[06:10] who's a data engineer knows how much time you spend troubleshooting and maintaining pipelines like nobody wants to do ETL. ETL should be a four-letter word. So when an agent makes a decision in
[06:23] your operational system, you don't see it in your analytical system until the next ETL run. Right? That's a governance gap. That's a problem. So let me be blunt. We don't trust AI
[06:36] agents with production data and we're right not to yet. So look at the current approaches. Sandboxes don't have production realistic data. Staging environments drift from production within hours.
[06:49] manual reviews uh manual review cues defeat the purpose of autonomous agents. You've just injected expensive human in the loop steps into your process. So now you're running an agent and then
[07:01] somebody has to manually approve its actions. What's the point? Um so feature flags and dry run modes only work for simple predictable changes.
[07:13] So what we actually need is something that gives us production identical isolation that's instant and free. We need the agent to think it's writing to production with all the real data but in
[07:25] a space where mistakes can simply be discarded. That's exactly what lakebase gives us.
[07:38] postgress in the cloud. So lakebase is a fully managed Postgress uh Postgress SQL 17 running on the databicks data bricks platform. It's
[07:50] serverless. It scales to zero when idle and scales up on demand. Scales down. No capacity planning. No cluster management. So we're talking about those environments.
[08:02] You want to create a sandbox environment. What do you got to do? You got to spin up a whole another server, right? You got to duplicate the data. You have to buy licenses. You have to do all this stuff. You gota there's there's
[08:15] a ton of things. You got to set up pipelines to to try to sync the data. It's a nightmare. So, but the key thing is it's you know it's this is wire compatible with standard Postgress.
[08:27] Your psycho g uh psychoppg2 code works, your PG admin works, your ORM works. you could point them at a just basically point them at a new endpoint and then
[08:40] they won't know the difference basically because it's using the exact same protocol. So anything that you're doing in existing Postgress SQL will work exactly the way that it has been. So it ports
[08:52] over really nicely and cleanly and you you should have no problems with migration. So but what makes it special isn't just the Postgress part. It's everything else that comes with being built on the lakehouse platform and
[09:04] that's what I want to focus on next. So three capabilities that make lakebase more than just managed Postgress. First, the lakehouse sync. Your
[09:16] operational data automatically replicates to Delta Lake. No ETL code, no spark jobs, no scheduling. It just syncs. And that means every insert, update, delete in your Postgress tables
[09:29] shows up in your analytical layer within seconds. And I'll show you that in the demo. Second, PG vector is built in. You get vector search without deploying a separate vector database. In the demo,
[09:42] I'll use this for an agent for agent memory. The agent will store embeddings of past decisions and and retrieve them with similarities similarity search. This is one of my favorite parts. So the Postgress SQL there's an extension to
[09:56] the database that adds a data type which is a vector data type. So you know anything about vector databases which I think they're they're literally the core of like how AI works. It's just amazing.
[10:08] Um but it allows that vector data type with those 124 different um dimensions to be um to collect the the feeling the
[10:20] sentiment of some uh text string and then be able to take that and not just do a keyword search but go in and back into the vector database and find something that's cosign similar. So
[10:32] imagine every single little property um if something is royal or fuzzy or hot, right? All of these properties were basically turning those properties into
[10:44] their their um magnitude based on a number so that the LLM can understand well because LM's understand can understand the numbers better. But I digress. The vector database is really
[10:57] cool to me. Regardless, if you did this on your own, you would need to have a separate vector database like pine cone or something else. This is built into Postgress and is as simple as just
[11:10] installing this PG vector extension and making this data type available. So third is the star of today's talk which is instant branching. So zero copy database clones created in seconds with
[11:23] full isolation. This is what enables safe autonomous rights. This is the game changer. Um, I work in fabric a lot and when you want to move a lakehouse from
[11:35] one environment to the other, you can move the lakehouse but the schema doesn't go, the tables don't go, the data does not go. It's just a lakehouse object and it's almost like completely empty and you have to write
[11:49] basically a a deployment script that goes along with the object to then create all that stuff, right? The data doesn't travel with the lakehouse. You have to you have to populate it with
[12:01] everything. This is literally a get like get branching for data. So you could take an an absolute copy. I hate to use the word copy because
[12:13] we're not copying anything. It's the same data. It's a metadata shell game. So we're just taking the transaction log on top of the parquets and the delta table and we're redefining what the definition of that table is by omitting
[12:28] or including um pointers to the parquet files that are in in the delta. So nothing ever gets changed. We're just playing with the metadata that sits on top of the table. So this is hugely powerful.
[12:45] So someone's thinking I could just run Postgress on RDS or cloud SQL. Um I think I touched on this sure but you need uh you need to build all of this out yourself right you need to build ETL pipelines for analytics you need to manage a separate vector database you
[12:58] need to figure out the database cloning which typically u means full physical copies that take hours and cost double the storage. Right? So we're talking about not reinstantiating the data at all. It's the same data all the time.
[13:14] So with lakebase, all five of these come builtin, integrated and governed by Unity catalog and that's the difference. So get style workflows for live databases. Um
[13:28] so I already
[13:40] uh database. When you create a branch you get a zerocopy clone of your entire database. Doesn't matter if it's 10 megabytes or 10 terabytes. Branch creation takes the same amount of time because no data is
[13:53] actually copied. The branch uses copy on write semantics. It could read all production data through uh through to the parent production branch, but any rights go to the child branch only. Production never
[14:06] sees those child branch changes until you explicitly merge them. So this is that metadata shell game we're talking about. When you branch from a production branch in that database, you're just creating a metadata pointer at all of
[14:19] the all of the data that currently exists in that in those in that delta table, right? Then you branch out and whatever changes you make are just going to be added as changes to that parent. So we're not
[14:33] actually reinstantiating, copying anything at all. We're just playing with the metadata. We're saying my new table, my new branch is that other table plus all the changes I've made. Right? And I'll show you a little diagram of that.
[14:46] Um, and also you can have multiple branches simultaneously. So multiple agents each on their own branch in parallel with zero conflict. So this is one of the
[14:58] major motivators for the release of this technology and what unlocks the power of agents. So you heard Ali talk about it this morning. You know the agents are coming for your database. They ran into
[15:11] this problem and they needed a solution. How can I have all these agents running and how do I how do I cordon them off? How do I control them? I got to put them in a I got to quarantine them. So the
[15:25] ability for them to just make mistakes and it not be catastrophic is the key to all of this. Um so here's a three-phase pattern that I used. So phase one branch, right? The
[15:39] agent decides it needs to make changes. So it creates a branch uh one SDK call which is to PG create branch. It takes about two to three seconds regardless of the database size.
[15:52] Remember if the database is two terabytes or or two megabytes, it doesn't matter. It's the same amount of metadata. So it's it's instantaneous no matter the size of the database.
[16:05] Um so now the the agent has its own isolated workspace. So phase two is validate. The agent applies its proposed changes to the branch, then runs a suite of business rules, margin checks, change
[16:18] limits, sanity checks, impact estimates, all running against the branch data. Um, phase three, merge or reject. If all blocking rules pass, we merge the branch
[16:30] back to production. If any rule fails, we discard the branch entirely. The bad change never makes it into production. So this is safe by design, not safe by
[16:42] convention, not safe because we hope the agent behaves. The architecture makes it structurally impossible for unvalidated changes to reach production.
[16:59] Now, uh
[17:12] production or worst case you're relying on manual review which doesn't scale. So with instant branching the clone is instant and it's free. It's always production identical because it's
[17:24] literally literally reading from the same pages. We didn't copy the data. So there's no ability for it to drift. Um so validation is automated. Isolation is
[17:36] guaranteed by the storage engine and not by convention. So the cost difference is dramatic. A full copy of a one tabyte database costs one terabyte of storage and takes hours. A branch of that same
[17:50] database costs nothing until you modify the data like we talked about in the branch. And then only the changed pages, right, will carry storage costs. So you can branch a one tabyte database,
[18:03] bring it over, no cost. When you start to add new records, modify, you do, you know, some cred stuff to it, then you're only going to pay for the the
[18:16] basically the data that you've added to that to that to that child branch feature branch. So for the engineers in the room, here's how it works under the hood, right?
[18:28] Okay, this is what I was just talking about. The produ the production branch has pages A through H. When we create a branch, we don't copy any of them. We create a metadata pointer that says this branch reads from the parent.
[18:42] So when the agent modifies data on pages C and F, only those modified pages C prime and F-prime, which are the original ones, are stored separately. Everything else reads through to the
[18:54] parent. So it's saying my table is that thing over there plus whatever I've changed. So branch creation is um is nearly instant regardless of the bit
[19:07] database size. It's just writing a metadata record. Storage cost is proportional to the changes made not to the database size. And read performance is identical to production because the page cache is uh is shared. So and merge
[19:21] is the reverse. apply the changed pages back to the parent. It's fast because we know exactly which pages were modified. There's one other thing I want to talk about. So that page sync actually goes
[19:33] in reverse too. So when you modify a table in a postgress SQL table and you set up CDF which is a change data feed, it automatically syncs to your Unity
[19:46] catalog table, right? So you magically just have the same data available to you for analytics. You can actually do the reverse. So there's another process where you can actually do reverse ETL.
[19:58] So say you have an app that wants to provide to the user their average product purchase price. Well, that's something you would do in in an analytics system, right? Not in the
[20:12] operational trans transactional system. So you can make this stuff available the other direction as well. So, think about that. It's uh interesting. There's a really good paper I read on the plane over and it's uh lake base for dummies
[20:25] and I'm a dummy. So, it was perfect. Um but uh it it had a really good explanation of all that. So, um let's see how this all fits together and the pricing agent architecture.
[20:41] Here's my diagram. I'm very proud of this diagram. Um, here's the uh here's the end toend flow of the pricing agent that I developed for this demo. So, the market signals come in and this can be
[20:53] like competitor price changes, demand spikes, inventory alerts. These land in a signals table in the lake base. The pricing agent picks up unprocessed signals, queries its PG vector memory
[21:07] for similar past decisions, and calls Llama 3.370B foundational model API to generate price proposals. So, it collects all the information it needs. It's like, hey, we
[21:21] heard that our biggest competitor lowered their price, or we know that we're really low on inventory, so we should jack the price up, right? uh which is kind of dastardly but you
[21:34] know we're all trying to make money here. Uh and then the other one is like you know if um the there's a really really high demand for
[21:46] this product we can also increase the price. So we're trying to make decisions based on what we did on what we're feeling from the from you know the market and we want the LLM to include this in its decision- making. So the key
[22:00] part instead of writing proposals directly to production the agent creates an instant branch right applies the changes so all these this these prices that it's come up with um it runs
[22:13] validations against th those prices and it only merges if everything passes those validations. So after a successful merge, the lakehouse sync automatically replicates
[22:25] the updated data to the Delta Lake, making it available for BI dashboards and analytical queries. It also updates the agents memory by recording the decision in the PG vector database as an
[22:37] embedding for the next pricing agent to use as context. So the agent gets smarter and smarter as this goes on, right? It's constantly writing its memory to the Postgress SQL database and this uh
[22:52] then the entire cycle from signal to validated production update runs in under 30 seconds.
[23:04] So let me walk through the 10 steps in detail real quick. Those are the 10 steps. I'm going to do a summary. Steps one through three are the is the reasoning phase. The agent gathers signals, retrieves relevant memory, calls the LLM. The LLM
[23:18] gets context about current prices, margin floors, competitor positions, and past decisions. It returns structured proposals with reasoning. Steps four through six are the action phase,
[23:33] but safely. So, it's going to act safely. Create branch, apply changes, run validations. The agent is autonomous here, but contained within it within its own branch. Steps seven through eight
[23:45] are the decision points. Did all the validation rules pass? Then we merge to production. Right? Any blocking rule fails and we reject. We do not merge and then we discard. So no
[23:59] partial applies. No well most of it was fine and we did it anyway. So this is this is the fail safe. Steps nine and 10 are cleanup. So we record the decision whether we decided
[24:12] to with with a passed or failed and we we write that to memory for future reference. We mark this we mark all of our signals as processed and then um so that the next time signals come in they
[24:24] will then we'll see the only the ones that are unprocessed and then the agent learns from every single run.
[24:37] So on the left are our blocking rules. Any failure means the branch gets rejected entirely. Margin check um is no price can go below our cost plus the minimum margin floor. We set these per product category
[24:50] typically around 15 to 25%. So match max change check. So this is the the maximum delta. So you'll see the absolute delta in any direction. So if the we're
[25:03] proposing an increase or decrease of 30% or more, then it's going to it's going to stop it. So this will catch all of our catastrophic errors. No negative check. So this is just simple sanity.
[25:16] Prices must be positive. We're not selling things for negative money, right? Um competitor sanity. If a competitor is selling below our cost, we don't match it. We're not in the race. We're not in a race to zero. Like so if
[25:29] our competitor for some reason their cost is lower than ours, they're able to beat us, we're not going to sell it for for less than we we can get it for. So on the right are the warning rules. So
[25:41] they log information but don't block the merge. So revenue impact estimation, how many products are affected, how this compares to the historical decisions.
[25:54] But the key insight here is that these rules are on the branch, right? on the child feature branch. So against that branch data, so we're not hypothetically checking, we're verifying the actual state of the database after changes are
[26:07] applied. So nothing has really been changed, we're just letting the agent play around. So the last piece of the puzzle is the lace lakehouse sync that I was talking about. So once changes merge to
[26:20] production in lakehouse and lakebase sorry they automatically flow to delta lake tables in unity catalog products price history market signals um validation results they're all available
[26:32] in delta tables in this uh schema that I'll show you. This means your BI team gets updated dashboards within minutes. Your data science team can train on the latest pricing decisions. Your
[26:44] compliance team has a full audit trail and uh and it will be able to tell about what changed, why it changed, which agent decided to change it, which branch was used and which validations passed
[26:57] and have the ability to roll back to the older branch. Right? All of this without any ETL code, no scheduling and uh none of the we'll get that data tomorrow. It's like just there within
[27:09] minutes, seconds to minutes is what they advertise. So
[27:29] So here's the road map of what we're about to see. Seven steps all running against a live lakebased instance in Azure East US2. We'll start with current products. Inject some market signals to trigger the agent.
[27:41] watch the LLM reason about pricing, see in an instant branch get created, run validations against it, merge to production, and confirm the data lands in the Delta Lake. So, the entire flow
[27:53] runs in under a minute. Um, let's go do it.
[28:13] All right, let's see this in action. I'm going to switch to a live datab bricks notebook connected to a real lakebase instance running in Azure EastUS2. Everything you're about to see is hitting a a live serverless Postgress
[28:26] database.
[28:38] We're going to run uh some startup here and get the configuration loaded. So, first let's look at what we're working with. We have 50 synthetic products in our lake base.
[28:51] Things like electronics, clothing, homegoods. Each has a current price, cost basis, and margin floor.
[29:04] Notice we're connecting via psycho GP2 with a JWT token generated by the datab bricks SDK. This is a standard Postgress wire protocol. So any tool that speaks post P postgress can connect here. Look at the margin floors. These are the
[29:18] guard rails we've set. The validation rule enforces price minus cost divided by price greater than or equal to margin floor. So the agent must maintain category specific minimum
[29:31] margin. Now let's simulate what triggers the agent. Market signals arrive. A
[29:45] competitor has undercut us on several products. We also have a demand spike on one category.
[30:04] We just inserted six signals in production. These would come from price monitoring feeds, demand forecasting models, or inventory systems. The agent will pick these up as unprocessed signals.
[30:17] Notice the signal types here. Competitor undercut means someone is selling cheaper. Demand spike means we could potentially raise prices. The agent has to reason about what to do
[30:30] with each one. So here's where it gets interesting. The agent queries unprocessed signals,
[30:42] checks its PG vector memory for similar past decisions, and sends everything to Llama 3.370B.
[31:03] Look at the reasoning. It's not just matching the competitor price. It's considering our margin floor, the demand signal, and what it did last time in a similar situation. This is why memory matters.
[31:17] So you can see here it's a process six price changes across six products. So Homehub mini smart display when increase by 7.3%. Um or it increased by 7.3%. The sparkle
[31:30] clean multi-ervice spray um is this signal is showing that it's up by 6 and a.4%. So these are all this is the memory of things that happened last time.
[31:53] And now here's a critical safety step. Instead of applying these changes directly to production, the agent creates an instant branch.
[32:19] You see that took about two to three seconds. We just got a zero copy clone of our entire database. The agent now has an isolated workspace that sees all production data but can't affect production.
[32:31] Notice the branch name, the run ID um is the run, you know, notice that the name includes the run ID prefix. So we
[32:43] can identify this run ID later. We have multiple agents running simultaneously each on their own branch with zero conflict. At this point the branch endpoint is active and ready. Next we'll apply
[32:56] changes on the branch and prove production is still untouched.
[33:16] So now the agent applies its proposed prices but only on the branch. Then it runs our five rule validation suite.
[33:43] changes applied to the branch. So if I queried production right now, still untouched. Um let's validate that. So five rules are running.
[33:59] Price is greater than cost. So we never have any items that are below cost. Margin floor. Every item must satisfy the margin floor. The max 30% change, so no extreme single step moves, so we never go up or down
[34:12] more than 30% in any in any direction. Minimum $1 dollar sanity, so no absurd floor of violations. And uh portfolio impact is less than 20%. So we it's an
[34:26] aggregate guardrail for this run. So we make sure that uh we never impact the whole portfolio by more than 20%. So you'll see that all block rules have
[34:38] passed. If any had failed, say the agent tried to drop a price by 40%. The branch would be discarded entirely. So no partial applies, no oops, roll it back.
[34:50] The bad changes simply never reach production. This is a core valition. The agent gets to be autonomous, make decisions, take actions, but within a
[35:02] safety net that's impossible to bypass. So now we're going to if that validation passes up here, we're going to we're going to merge.
[35:16] So we know all validations pass. The agent merges the branch back to production.
[35:31] successfully merged to production. Decision stored in the agent memory. So, not only did we write to production, but we also write this decision back to memory so we can pull it up next time that uh we run this process.
[35:47] So, and just like that, production prices are updated, signals are marked, processed, and the decision is written to PG vector memory. We also have a full audit trail in price.history pricing.pric history
[36:00] showing exactly what changed, why, and which branch run generated it. The entire cycle from signal arrival to validated production update took under 30 seconds. And at no point was
[36:13] production data at risk. So one more piece, Lakebase automatically syncs this operational
[36:25] data to Delta Lake via Lakehouse sync. Let's check our Unity catalog tables.
[37:05] So here's the same data now in delta format in unity catalog price history validation results everything available for BI dashboards ML training compliance audits no ETL code required this is what bridges the
[37:19] OLTP OLAP divide we talked about lakebase handles the operational workload delta lake handles analytics lakehouse sync keeps them in well sync.
[37:32] A quick analytical query that we have here. Average price. Um
[37:57] So, average price uh change per category, number of products affected, total estimated revenue impact. This is the kind of query your BI team runs and it's already available seconds after the agent made its decision.
[38:10] You'll be able to see this data living over here in Unity. All right, I'm falling asleep. So, what it shows is that in Unity catalog
[38:22] you're able to query that data immediately. All right, let's see this in action. I'm >> Let's listen to it again. All right, key takeaways and next steps. You guys go want to go get a beer. I can sense it.
[38:35] key takeaways. All right, let me adjust my screen here real quick. Three things, three things to remember today, right? First, safety first. Instant branching gives you production
[38:48] safe agent rights. The agent can never accidentally modify production. Changes go through the branch, validate, merge, or they don't go through at all. Right? So, it's structurally safe, not
[39:00] procedurally safe. Second, zero overhead. These aren't expensive full copies. Zero copy. Zero copy means no storage duplication at all. No infrastructure cost, no operational
[39:12] burden. Create and discard branches freely. They're essentially free until you modify the data. So third, full governance. Because Lakebase syncs to Delta Lake automatically, you get a complete audit trail from operational
[39:25] decisions to analytical insights. Every agent decision is logged. Every change is traceable. Everything is governed by Unity catalog. So this pattern works for any scenario
[39:37] where an AI agent modifies production data and you can't afford mistakes. So if you can't afford mistakes, you got to build some kind like this. Um, pricing agents is a good time, like I showed
[39:50] today, inventory management agents, another example. Uh, recommendation engines that write personalization data, content moderation systems that modify live content. Um, it's also great for
[40:02] high stakes automated workflows beyond AI like financial transactions, healthcare records, or compliance updates. Um the common thread here is that you know if oops let me undo that
[40:14] is is acceptable because of the downstream consumers um audit requirements or SLA commitments then this is your pattern. So if you can't make mistakes um I would find a
[40:26] pattern like this to follow. So I have a GitHub repo here if you want to look at some of these notebooks that built the stuff. Um, this is the lakebased documentation. I'm sure you
[40:40] guys can uh have seen that. But in the instant branching guide, they also tell us to to implore you to complete your surveys. Um, please do that, I guess. Or else. I
[40:54] don't know what the else is. Um, so do we have any questions? Are you guys all itching for a beer? >> Any questions?
[41:06] Okay. >> Itching for the beer, >> huh? >> Thank you. >> Sorry.

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.