Sponsored by: Fivetran | Open Data Infrastructure: Built for agentic AI

Summary

Fivetran and dbt Labs have merged to offer an integrated open data infrastructure platform combining data ingestion and transformation, built on the open table format standardization driven by events like Databricks' acquisition of Tabular.
Open Data Infrastructure separates storage from compute, embraces open standards, and keeps data portable across clouds and engines — preventing platform lock-in as AI workloads scale in complexity.
AI is increasing demands on data infrastructure for fresher data, more diverse formats, and multi-engine support, and this video argues that a semantic layer and dimensional models are essential prerequisites for reliable AI workflows.

Chapters

FAQs

Why did Fivetran and dbt Labs merge?

Fivetran, focused on data ingestion, and dbt Labs, focused on data transformation, have worked together for many customers for over a decade, with their tools frequently used in combination. The merger creates a unified open data infrastructure company that can offer an integrated ingest-to-transform pipeline built on open standards.

What is Open Data Infrastructure and why does it matter for AI?

Open Data Infrastructure is an architectural approach that separates storage from compute, adopts open table formats, and keeps data portable across clouds and engines, preventing vendor lock-in as AI workloads grow. This video argues that without an open, interoperable foundation, organizations face repeated replatforming costs as AI use cases evolve and new engines emerge.

How do open table formats change how organizations work with data?

Open table formats like Delta and Iceberg are described in this video as a profound shift in data management — one the industry is still in the process of fully realizing. They enable organizations to read and write data with multiple engines, share data across platforms without copies, and maintain portability that was not possible with proprietary storage formats.

What role do semantic layers play in AI workflows according to this video?

Semantic layers and dimensional models give AI agents a governed vocabulary of business terms and metrics, preventing them from misinterpreting raw schema structure. This video describes avoiding MCP server sprawl by routing agent queries through a semantic data layer, ensuring that AI experiments and production agents draw from curated, well-defined data products.

Full transcript

[00:09] Welcome. Nice to see you all. So, my name is George Fraser. I'm uh CEO of Fiverr uh and DBT Labs. >> Hi everybody. Tristan Handy, uh co-founder of Fiverr and DBT Labs. >> And uh we, as you may have heard, our companies recently merged uh which we're
[00:22] very excited about. Um and we think, uh together we have something really unique to offer the world. Uh and we're here to tell you about it. uh this concept of open data infrastructure what we mean by that um uh what it what it means for you
[00:35] and the ecosystem and what we can do as part of that uh so let's get into it yeah that's us
[00:47] Fiverr and DVT labs have been uh separate companies working together in a lot for a lot of customers for a lot of years uh we've been at this for over 10 years and um very often used together Uh
[00:59] and starting last year we started to talk about and work on the idea of uh combining the companies into one company. Um and we think uh we think it makes a lot of sense. A lot of our customers thought it made a lot of sense. Uh data ingest is always what 5G
[01:12] has really focused on. Data transformation is always what uh DBT has focused on. And uh they they go together uh like like peas and carrots like uh Bob Mia said to us. And I really think that u it was two years ago here this
[01:28] week uh with the acquisition data bricks acquisition of tabular and the like clear industry standardization and pull around open table formats that open data
[01:40] infrastructure really kind of took shape in both of our heads independently and and really like we started kind of coming towards this idea um over that year and then and then the year of uh working on the merger
[01:53] Um so so really like um open data infrastructure and all of the the things that we see for the promise of it uh is not is not possible without the innovations coming from you know these
[02:06] the you know the snowflake and data bricks events and and the things that happen inside the the wider ecosystem. >> Exactly. Open table formats are really where it all starts and they're a really profound change to how companies manage and work with data that I think people
[02:19] are gradually realizing just how profound it is. Um so a little agenda for today. We're going to talk about the uh impact of AI on data infrastructure. What is uh the what's happening in AI and what we can all see will happen in
[02:32] AI mean for how you manage your data. Um we're going to talk about uh our approach um how we see ourselves fitting into the future of data management. Um we're going to talk a little bit about
[02:44] some of the great new stuff uh that we've announced in the last couple weeks. Um, and we're going to talk about how real customers are using these tools to solve great problems and do great things. >> Sound good? >> Let's do it. Yeah. >> Yeah, let's do it. All right.
[02:57] >> Okay. So, uh, does anyone here feel like you need to be convinced that AI is a big deal? >> I didn't think so. >> Come on. There's a kagon out there somewhere.
[03:12] uh data points are actually from uh our state of analytics engineering survey that we did um now it was I think we originally did the survey about 6 months ago now and so I would actually say that
[03:24] probably each of these numbers will have gone up since then. Um you know we need to be doing monthly surveys at this point. Um but I think unsurprisingly um data leaders care about using AI for
[03:38] productivity gains. Uh data leaders are also concerned about and I think that this is a concern within data that is unique to the wider world of agentic coding but uh concerned about the impacts of hallucinated data.
[03:52] How do we minimize that? And how do we uh design areas of our systems and set customer expectations so that we the bar is not always set at 100%. Because
[04:05] probably we're not going to be able to take advantage of all of these benefits without it some level of of incorrectness that but the question is like for what use cases and for what level of uh SLA do we need to hit? And
[04:17] then um I think that a as we're going to talk about with agents um certainly uh we are going to see increased spend on compute. Um agents suck down a lot of
[04:29] data and uh they're going to drive up compute because of that. Um so we're already seeing all of this play out in in the real world in in practitioners hands um every day. >> And we've seen this at Fiverr. I mean
[04:42] earlier this year we saw our data warehousing costs, compute costs started to grow 10% a month uh because of the adoption
[04:54] and update our DBT model. Um and there were benefits of this. The analytics team was getting more done than ever, but uh 10% a month growth is uh a real problem. Uh anyone who's uh started an
[05:07] early stage company will tell you that's the magic threshold of tripling each year. >> Uh if you're going 10% a month, you're on track to triple uh for the year. Uh and that that can be a problem because
[05:19] the baseline of that number is not small. >> Yeah, tripling every year on your your warehouse spend is not what you want. The um the question though is how do you uh create efficiencies to allow this
[05:32] type of innovation to continue to happen without quashing the innovation but but uh not not seeing that kind of increase on your on your bill. >> Yeah. So we've been building uh the what
[05:45] is often termed the modern data stack for 10 years. Um it works great uh for solving all kinds of problems. People the classic problem you solve uh with Fiverr and DBT and tools like data bricks is building reporting um building
[05:58] reporting for your internal uh management team uh building operational dashboards to help the sales team work every day to help the customer support team work every day you name it. uh to
[06:12] fundamentally to understand what's happening for human beings to understand what is actually happening in the company. Um and the data stack was built very much for humans as an audience. Um but uh we can all see that uh AI agents
[06:27] are the new primary consumers of data. Uh even if that's not totally true today at your company, uh we can all see the writing on the wall that this is where it's going. That the main query of the database in the near future are going to
[06:41] be AIS. >> And what does that mean? >> You're going to make me hit the button. Okay, we only have one clicker. George is really running the slides here. So um so yeah, what does that mean? Do are you
[06:54] ready for that? or do you trust uh agents to uh have exclusively positive impacts on your data platform? And and I think that we can all see a world in which this goes well and and is is
[07:09] actually much better because we as data practitioners live the reality every day where our task lists are not done. Um there has never been a data practitioner who's like, "Oh, I've answered all the
[07:22] questions. I've made sure that all the fields have documentation that I just like that the the task list never ends. And so the idea that um deploying intelligence via agents into your data
[07:34] stack that that's a very compelling thing for all of us who've been living in this world u the question is are we really ready for it? Um we talked about cost before. We need to make sure that as agents continue to uh ask things from
[07:48] our data platforms that we have ways of both controlling and uh delivering efficiencies so that cost curve doesn't go quite so aggressively north. Um we need to make sure that whatever the
[08:01] access control strategy is and sometimes the access control strategy is uh agents have the same uh properties as humans and we can use our existing systems to do that. we just have to make sure that
[08:14] we're we're doing it well. Um but but sometimes I think that that's not going to be the answer. Uh but we have to make sure that we can see what agents are doing that they have access to only the data that they need. Um and finally,
[08:29] are we futureproof? And this is a very big one. Um it it used to be that major platform shifts and as a result major technology realignments inside the
[08:42] enterprise happened I don't know every decade something like that now the the frequency with which we are being asked to evaluate new technology
[08:54] and how do we align ourselves with strategic vendors I mean it is happening at a breakneck pace and it it is almost um hard to make those decisions because by the time you walk through a consensus
[09:07] decision-m process inside of a large organization like the reality on the ground has changed. So you need to be able to adopt new technologies at pace and I think the only real way to do that is with uh open standards.
[09:21] >> So what is this idea of open standards in the context of data infrastructure? Uh we've spent 10 years talking about the modern data stack and now we're talking about open data infrastructure. uh what is that and how is it different?
[09:35] Um open data infrastructure uh means that um the uh the data doesn't just serve uh looker, it doesn't just serve BI tools and dashboards. It can serve
[09:48] any workload. Uh and that means it starts with open table formats. Um, it it means that you can access your data from the data platform you use today,
[10:00] but you're also going to be able to access that same data from the data platform you adopt tomorrow for the purpose that doesn't even exist yet. Uh, and it means that you have the ability to optimize and control costs like
[10:13] Tristan said a moment ago. Um this is a little diagram we made of how we see the open data infrastructure stack and how fiverr and dbt can help in each layer of the stack. Uh critically uh open data
[10:27] infrastructure means every layer is ideally standardsbased and interoperable and so you don't have to use fiverran or dbt in order to use open data infrastructure and you can make independent choices in every layer of
[10:41] the stack. So this is uh something we can help you with, but it's not fundamentally something that we're selling. Um at the bottom, it all starts with uh open table formats. If you take one thing away from this talk, it's um
[10:55] build your data stack on top of open table formats. So that uh if you want to consume the data through a different mechanism, you don't have to do a migration. Um we're a lot of years now
[11:08] into the adoption of open table formats. I think we can safely say they are now mainstream. Uh we've done a lot of work at Fiverr in particular to make it easy to adopt open table formats. If you set
[11:20] up a data lakeink destination in Fiverr, it works exactly like uh sending the data directly to data bricks, directly to snowflake, directly to BigQuery. That means um we deliver a replica of your
[11:33] source in your data lakeink. We do updates, we do deletes. We are not delivering some sort of change feed and then asking you to go and reconstruct the present state of the world in the compute engine. We do that at the ingest
[11:47] phase. Um and we register all those tables in the catalog of your destination of choice and in end cataloges of all of your destinations of choice. So our goal is to make it just
[11:59] as easy to adopt open table formats as it is to adopt a walled garden close system like we mostly have been for the last 10 years. So that even if you only really intend to use the data from one
[12:12] place right now you can still adopt open table formats as the base of your data stack just for future proofing and it has an additional benefit which is you will save ingest costs. Um the way we implement open table formats at Fiverr
[12:25] is we actually perform the ingest into the data lake including those updates and deletes and table maintenance um behind the scenes in a specialized service that we've uh been building for the last 3 years that because it is
[12:38] designed to work together with fiverr data pipelines is extremely efficient so efficient that we don't even charge for it separately. Uh those compute costs are just included in the same price you've been paying for your connectors all these years. So if you migrate an
[12:51] existing fiverand data pipeline from delivering directly to data bricks or directly to snowflake to delivering to a data lakeink and then having the compute engine query the data lakeink uh the ingest costs for you will just disappear
[13:04] on the day that you do that. Um and as a result we're seeing a lot of growth of that as a destination. >> Okay let let me do some uh product marketing experimentation live on stage. You ready? Okay. >> You know I love experiments.
[13:16] >> Yeah that's true. Uh George tries to design an experiment. Anytime there are two humans in the room and want to do the same thing, he makes them do it in two different ways. Um so uh I have uh
[13:28] this is a good slide. I I think that it might be a little too complex, right? When you have a stack slide, once you have like more than four layers, it starts to be a lot. So here I've been experimenting with different ways to
[13:40] describe open data infrastructure and the way that we think about it in our heads. Um, the way that I, and I'm gonna stand back in the back of the room and accept feedback as everybody leaves the room. Um, the way that I think about it
[13:52] is you now have three big types of platforms that are a part of your data infrastructure. You have your systems of record, that's your Salesforces, your SAPs, etc. You have your data platforms
[14:05] that are primarily responsible for storage and compute, and then you have your intelligence providers who are providing tokens. And these are your like biggest uh platform investments.
[14:17] They're your strategic alignment, etc. We want to sit in between all of that as the connective tissue between these platforms that makes the data move, that keeps track of it, that makes sure there's metadata and context and
[14:29] semantics on top of all of it. So that when you make decisions about these platforms, you are not locked in. you can make a decision and then say actually but also for this other team
[14:42] over here we want to make a different decision or next month we want to change uh change that. So uh having the connective tissue separate from these three big platforms I think has a lot of a lot of benefits >> and that word context is really
[14:55] important. Uh the two things that are really new in this diagram are that context layer and that model layer because that is the new data consumer in the data stack. Uh if you take one thing away from this talk, it is that uh you
[15:09] should use the same data stack that you've been building for years to serve analytics to serve as context for AI. Uh and we'll talk more about why that is um and uh what are the why that's a better
[15:22] way than building a spiderweb of MCP servers talking directly to every single system of record. Um uh but first we want to talk about some of the important things that are happening in uh DBT
[15:34] world that we've announced in the last week. >> All right. So DBT has been around for a decade at this point. First commit to DBT was in March of 16 and uh we
[15:48] officially hit 1.0. I believe it was five years ago. So we do not do major versions uh lightly. This is the second ever major version upgrade. Um, and it
[16:01] is a very significant upgrade. Um, DBT core with this upgrade stays in the like in full Apache 2 open-source uh, universe. Um, but it is being rewritten
[16:15] with uh all of the technology that we've been working on for the last uh 24 18 24 months uh with what we've been calling the DBT fusion engine. And so uh we are
[16:27] pulling a big chunk of the fusion technology written in Rust for much higher performance computing um and we're giving it to the entire community uh under the Apache 20 license. Um, so
[16:42] anybody who is using DBT core today, this is a Oh, all right. Thank you. Um, anyone who is using DBT core today, this is a strict upgrade. It is uh
[16:54] significantly faster, more responsive in your in your local workloads. Um and uh there are a bunch of features that we will be building on top of this where uh
[17:07] core will be kind of the gateway to uh new functionality and will provide you that kind of seamlessly in place without having to think about any type of migration. We've in the past we've uh
[17:21] always had this hiccup where in order to pay for features that we built on top that might actually be uh nice additions, you had to actually move versions of DBT which is a big lift. And so here uh the way that we've designed
[17:34] the strategy is that DBT core 2 provides a lot more out of the box but then it plugs in nicely with uh commercial offerings >> and even though it is a breaking change, it is a very small breaking change and
[17:47] there are auto migration procedures. In fact, I was arguing with the uh marketing team yesterday that we should just do like a genius bar at DBT summit in September where they will just upgrade you to uh DBTB2 there. just like
[17:59] bring your laptop, we will migrate your production instance. We'll see. Um, so we have a lot of other cool new stuff uh coming out right now as a as a combined company. I think the coolest one uh that
[18:12] if you are a DBT user, you should adopt today is DBT state. Um, DBT state is a global cache. Uh what it does is it keeps track across all of your users
[18:26] both humans and uh in production in CI um who has built which versions of which models against which versions of which data and that means that if somebody uh
[18:39] runs a model where the SQL text is the same and the source tables are the same or are within a small freshness tolerance that you configure instead of rerunning that query it will go and find
[18:53] that table and clone it uh and uh at a cost of zero. This can save as much as half of your total DBT compute bill uh in your uh data platform. That is a very
[19:07] big number for a lot of heavy DBT users. Uh you know the the the benefits of this are very large. It can be adopted very easily. It is compatible with both DBT cloud and DBT core. A lot of people I
[19:20] feel are not hearing this uh when I say it like you can use this even if you are a DBT core user. Um you do not have to sign up for DBT cloud in order to use this feature. Um it is a paid feature.
[19:33] However, I guarantee you it will be less than the uh money that you will save. We are basically selling dollars for 50 cents here. Set it up this week uh because it will save you a lot of money. Uh yeah, it it turns out that um when
[19:47] when we talk to customers about this uh people are very happy to spend money to save money. It's a good good value proposition. The um the internal so we've now deployed this in over 100 uh
[19:59] customers but um you know I am always partial to our own internal use case. Um you know our data platform spend in the grand scheme of things is not so big. Uh but we're we were just shy of seven
[20:12] figures. Um, and we saved I by implementing state we saved somewhere around $400,000 a year and that's real money for us. Um, we turned that into
[20:24] two FTE headcount. Um, so it's a big deal. Uh, the second really exciting thing uh that has just come out is DBT Wizard. Um, DBT Wizard is uh an Aentic coding harness. Technically under the
[20:36] hood, it's actually a fork of codeex. It's a CLI tool. Uh it's also in uh DBT cloud uh in in the web UI. Um and it is purpose-built for working with DBT. So
[20:48] uh what that means is it has a bunch of skills and tools inside of it that make it better at working with DBT models uh than any other harness. Um it it has it has contextual information on what is in
[21:02] your model uh what uh uh what the lineage is between all the different elements of the model. Uh it has the ability to run fine grain actions against that model. Um try it. Uh it's
[21:16] uh it's bring your own key. Uh so you can use your existing anthropic or open AAI key to use it. Um so it's effectively free. um you should have a better experience working with DBT models uh with this harness than with
[21:28] anything else. Um >> the nice thing about state or sorry about wizard is that um we and and this is an experiment that I uh I did not think it was going to go this well. Um I
[21:40] kind of believed six months ago that everybody was going to standardize on generic harnesses. We were all going to either be using codecs or we were going to be using cloud code. It turns out when you make a harness that is purpose-built for a specific task, you
[21:54] can fine-tune lots and lots of elements of it so that it performs better on that set of tasks. And so, uh, we are able to do incrementally better than clawed code, uh, in actual like successful task
[22:08] completion. But what's actually maybe more interesting is that we're able to do it in a s significantly more context efficient way. So uh you are using 80%
[22:20] fewer tokens um in the process which directly translates to uh your your uh token bill going down. >> If you're getting a theme here, we know everyone's costs are exploding. Uh and
[22:32] uh I think we are one of the few vendors who's really trying to figure out how to save you money because we don't sell tokens and we don't sell compute. Uh and the last thing uh that is new that we're promoting this week is what we're calling agent schema. Agent schema is
[22:46] really a pattern. Um, we've uh we've put up a specific uh spec of how to do it. But agent schema, it's the simplest context layer in the world. Uh, what agent schema is is it says uh instead of
[22:59] adopting a proprietary uh context catalog server with its own API with its own users and arbback. Um, what are we trying to do here? We're trying to give a map of metadata about what's in the
[23:12] database, right? Uh what's a great place to put data? A database. Uh just put your context in a set of tables in a special schema. We suggest agents as the name. Uh and uh you will discover you
[23:26] can set this up in an afternoon. Um you can have uh conversational analytics and background agents working off of this uh context map uh by the end of the day and
[23:38] they work great. uh it's compatible with any harness because all you do is build a thin skill that says to understand what's in this uh data platform go look at the schema called agents uh the details are in our GitHub repository uh
[23:51] and on a website we put up for it we publish GitHub actions for um populating agent schema from uh uh DBT models from uh look ML definitions because there's a lot of Looker users out there who have
[24:04] their dimensional model encoded in look ML uh and for OSI and We are in fact working on a PowerBI action though it's not done yet. Um so this is the simplest context layer you will ever see and it
[24:17] is ridiculously effective and it is compatible with every system because it's just tables. >> Um so uh speaking of context uh a lot of people are thinking about this question
[24:29] where should your agentic context come from and we have opinions about it. >> I have opinions about it. uh and um I want to start by explaining this concept of shared context versus personal
[24:41] context. So if we think about you know context that you want to go into an AI agent if all the different sources of context they kind of split into two categories.
[24:54] Uh there's one category uh that I like to call personal context. These are data sources like Google Drive and Gmail like Slack. Um, these data sources, they're very personal. Uh, they contain a lot of
[25:08] sensitive information. Uh, individualized permissions are very important. You don't want to give everyone at your company the ability to have their AI agent read all of your emails. On the other hand, curation not
[25:20] that important. Like just a feed, just searching all of your emails as a undifferiated list. That actually works fine for this kind of context. For personal context, you don't need to
[25:33] build a big DBT model to curate that data. You can basically just point the agent straight at the underlying collection. There's usually only one collection in individualized personal context. On the other hand, there is a
[25:45] different category of context, shared context. These are systems like Salesforce, like Zenesk, like Postgress, uh your production database, right? Uh like your ERP, like your financial systems. Um here the importance of
[26:00] individualized permissions is actually less. Uh that may sound like a somewhat heretical statement. People love talking about permissions in enterprise. However, if you look at how people
[26:12] actually use these data sources in classic business intelligence scenarios, typically they have just one domain that everyone in the company has access to. They scrub out the really sensitive stuff and then they have one domain that
[26:25] has things like the progress of all of your opportunities, the location of all of your inventory and then sometimes they have a couple of others. Maybe there's an HR domain, but the individualization of permissions is much less in shared context. At the same
[26:38] time, the importance of curation uh is much higher. You can't just point an AI agent or a person for that matter at your entire Salesforce schema and expect it to make sense of it from zero. Uh the schemas are very complex. they need a
[26:50] lot of curation in order to be usable and that curation is companyspecific. Uh and so uh our take is that for shared context you really want to build that the same way you built your data stack
[27:03] for analytics. You want to centralize your data. You want to curate it maybe with DBT and then you want to point the agents at that. And if you take only one thing away from this talk, it is that message is you should build your context
[27:17] data stack for shared context the same way you did for business intelligence. And you should use the same tools and the same people at your company, the data team should take this on as part of their scope. And we have done this uh at
[27:30] Fiverr uh over the last couple years. We have an internal tool uh that is built on top of the exact same data platform that has been serving analytics for Fiverr for years. The uh core schema
[27:42] that it queries is actually called transformsbi. The destiny of all schema names is that they will eventually be wrong. And this one is now wrong because it doesn't just serve BI anymore. Uh and you can ask it all kinds of questions
[27:54] about what's happening at Fiverr. You can ask it uh classic structured questions um like uh the uh you know percentage of revenue uh going to this
[28:06] activity or that activity. But you can also ask it unstructured questions about things like call transcripts because all of that data uh is in the same data platform. Uh I I feel like I often have
[28:20] to remind people that databases are great at storing text. Text columns they work. You don't have to build a new system on files in order to deal with text. We have had long text columns
[28:32] since the 1970s. Uh I I sometimes swear it's like uh people operating uh relational data platforms think that like we still have a 30 character limit or something but in fact you do not. You
[28:45] can put very long text blobs in uh databases and they work great. The nice thing about um going to your data stack instead of going direct to the source for some of these long text fields is
[28:58] that your data stack has all of this infrastructure set up around it already. And it has the ability to perform uh AI functions on top of these these large text fields. And so one of the most uh
[29:13] like clear uh ways that we've seen value out of this pattern as opposed to the MCP direct to source pattern is in Gong calls. So this last bullet point read
[29:25] called transcripts and reconstruct the why behind their use cases. So there's kind of two different ways you could do that. You could install the we use Gong. We could you could use the Gong MCP server. You could have it go out and get the right transcripts and pull them in.
[29:38] uh or you could load Gong data into your data lakeink and then you could model it. And so all of the transcripts you could say summarize these transcripts
[29:50] within you know 500 words. And it turns out that the signal to noise ratio is such that you can really reduce the amount of tokens by about a factor of 10 to 20 in uh transcripts without losing
[30:05] any signal. And so all of a sudden when you actually ask this question summarize give me an answer uh you have to pass only 5% 10% of the tokens into your
[30:18] model. So again significantly better latency and and much lower cost by using like mature infrastructure. So real example of doing this from three weeks ago uh we were at the Fiverr uh
[30:32] exec team meeting Fiverran DBT the first combined meeting and we were talking about data links and we were talking about who is using data links at Fiverr and uh in the meeting I asked my
[30:45] conversational analytics agent hey what is the breakdown of customer types adopting data links at Fiverr and these were the specific things people were talking about in the meeting, you know,
[30:57] is it digital natives, is it small companies, big companies, and it found it it used agent schema. So, it went and discovered uh as it does every time it starts what's available in the database
[31:10] by inspecting a bunch a set of tables uh that describe the rest of the database uh in agent schema. And then it wrote a bunch of SQL queries and came back with the correct answer. uh and it told us
[31:22] hey it's uh revenue weighted it's pretty even between it's pretty proportionate um between commercial and enterprise and it's slightly biased towards digital natives but not very much um but then I
[31:34] asked another question I said okay like who are the top 20 data lake customers and what percentage of revenue do they account for like how concentrated is this and it came back with that answer this is still more of a classic
[31:46] analytical question we're getting more narrow this is no longer quite as dashboardy But it's still very much uh you know a group by aggregate type query that it's writing here. But then I asked
[31:58] it a very different kind of question and this was this was the real question from the meeting and the real answer. Uh I reformatted it a little for the slides but this is the real thing. Um actually the same conversation that I had this in. I asked it to reformat it. Uh so I
[32:12] ask for each of these top 20 customers go back and read the call transcripts leading up to their adoption of data links and try to reconstruct the story of how and why each of them adopted it and it did. Uh and now we are totally
[32:26] out of the realm of classic analytical queries. Um this is very much an unstructured question but this was answered by the same data stack the same agent schema the same tables well
[32:38] different columns uh were used to answer this question and this is what is so cool about AI agents for working with data is they can actually do things with unstructured data
[32:55] so uh I think we talked about this uh uh a little already dbt state it's great you should use it if you like money. Um, typical savings are 30%, they can be higher. Uh, for some customers who are heavy DBT users. Um, anything anything
[33:08] else to say about DBT state? You should use that. >> It's it's three clicks. >> Yeah, just cancel whatever talk you're going to after this and set up DBT state if you're a DBT user. >> Um, and it's not just us uh using this
[33:20] stack. Real customers are doing this uh right now. Um we are seeing customers like ramp who are using context from their data stack to actually drive their coding agents. So this is not just about
[33:32] conversational analytics the same data stack that powers classic analytics conversational analytics can also power agents that are taking action and need to know things about what's happening in the business before they take that
[33:44] action. Um, OpenAI, uh, longtime customer, uh, has, uh, built a very similar, uh, Agentic, uh, analytics, uh, tool to the one I just showed you, uh,
[33:56] that answers questions based on the data in their data platform. Um, and, uh, one of our favorite, uh, partners, Infinite Lambda, has been able to do really fast migrations um, by using patterns like
[34:11] this to convert people from old school old school. I mean these people who are still trying to get out of the modern data stack kind of skipping a step and going straight to open data infrastructure um heavily using AI to do migrations. Uh if you're still on terod
[34:25] data I I recommend you talk to them. Uh they are great for that kind of thing. >> If you're still on Cobalt I recommend you talk to them. uh the the migration the the efficacy of long-running agents
[34:37] in migration is is truly astounding and it's it's a really interesting question of how is this going to reshape enterprise data over the coming 5 years because we've always kind of accepted that there you know legacy tech debt is
[34:52] there to stay kind of indefinitely and and that may just not be true anymore. Yeah, we we uh internally at Fiverr did an absolutely massive project to clean up all of the regretted decisions in the
[35:04] interface that sits between our 700 connectors and the platform that they all run on. Uh and we were actually able to get it done in less than a year with about 10 people on the team and just a
[35:17] ton of coding agents. And that's that's still still sounds like a long time and a lot of people but the sheer volume of code that we are talking about boggles the mind uh that we were able to get it done without causing any downtime was
[35:30] amazing and only possible because of AI and that started you know over a year ago. So that was the previous generation of AI that we started with. Um you want to talk about trust Justin?
[35:43] >> Uh well where are we? I think we're we're basically we're basically at the end, but I really appreciate everyone coming to hang out with us. Um I think that even though there are a few components that we need in order to uh
[35:56] give access to our data links to uh agents uh by and large the infrastructure that we have been building over the last decade uh is very much the infrastructure that agents
[36:08] need. just need to uh make sure that we are curating context that we are uh giving them access to that context in a way that that makes sense. Um and so uh yeah with that we've got a
[36:20] >> got some QR codes yeah for you about all these things which you should adopt >> and uh we'd love to hang out with you at the uh DBT labs and five train booths later. >> We're right next to each other so come by and say hi. All right. Thank you
[36:32] 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.