0:00All right. Hey, everybody. Super pumped to be here. I'm Jacob. For those who don't know me, I work here at MotherDuck in DevRel. So, yeah, we're really, really excited to talk about what it looks like to build end-to-end pipelines with AI. And, of course, we have Hugo here from
0:21Orchestra as well. Hugo, you want to say hi to our friends? Yes. Hello, everybody. Very excited. London is calling, so good to be here and looking forward to this. Amazing. Amazing. All right. So, we're going to. . . I'll just go through a little bit of a kind of walkthrough around to give everybody context for what MotherDuck is and then I'll hand it off to Hugo to do what. . . talk a
0:42little bit about what Orchestra is. And then, of course, you know, we will do a demo, which is the whole awesome part of this thing, right? So, let's just hop in here. Yep. This is the agenda, what we're up to. Yeah, let's hop into it. You know, I think one thing that we're seeing at MotherDuck,
1:03which has been really interesting in the last, let's say, six months, you know, specifically since we've seen Opus 4. 5 drop in November, the way that we use data is changing. It has gotten a lot easier. As it turns out, AI is tremendously good at writing SQL and
1:25interacting with data and, in fact, taking things that are semi-structured and structuring them. And all the things that were really hard suddenly just became easier for us to do. And that has led us into some really interesting kind of ideas and notions
1:45on the MotherDuck side. So, MotherDuck is a cloud data warehouse. And what we're really thinking about lately is, what does it mean to be the infrastructure for answers? So, once you have a data warehouse that, like, kind of fits in really nicely with your AI chat that you prefer, whether
2:04it's, you know, ChatGPT or Claude, or maybe even your open Chinese model enjoyer with DeepSeek or GOM or whatever, you know, we're thinking differently about how these pieces fit together. And, of course, you know, as much as things are moving quickly as it relates to
2:26the new world, all of the things that still existed kind of in the pre-AI era still exist, right? Which is, hey, things are expensive, they're slow, it's really complex to manage. You know, what does it look like to build something in the era of AI? And, you know, that's further complicated by, you know, I think this slide is a great example, which is,
2:50once you start tying in AI to your warehouse, they kind of query a little bit differently than humans do, right? They are not running a few queries kind of in a single session to find an answer. They are running tons of queries, a bunch of small ones, just trying to explore the data, understand what's in there. And, you know, they don't really have memory like we do, even,
3:14you know, and there's been a lot of ink spilled about this notion of memory. And it doesn't work yet, maybe in the future. But what that means is every time that it looks at your database, it has to do a bunch of work to figure out what the heck's going on and understand what's in there and relearn it every time. And so they do all of these queries. It's a lot of high-frequency
3:33bursty queries. And they don't know all the traps your humans do about the data. So that brings us to DuckDB, which is a query engine that is very fortuitously built kind of for this pattern. I don't think we would take credit for saying, hey, like, we built an engine that anticipated what the AI landscape would look like in 2026. But I'm very
3:58happy to say that DuckDB fits very, very nicely in that. And DuckDB is the compute engine that MotherDuck uses to run on top of your data. And so I'll just talk about a few of the details here. You know, broadly, there's a bunch of different layers, but it takes SQL, does a bunch of magic to it, makes it run on your CPU kind of massively in parallel, which means it's really, really fast.
4:21We call that vectorization. But there's a whole bunch of things to make that all work. And of course, MotherDuck takes all that really good stuff that DuckDB's building, which is single node and local, and puts it in the cloud and scales it out. And like when we say scales it out and then it works, what does this mean? Here's a chart with cost on the Y and speed on the
4:45X. And you'll see, of course, in the top right, there is MotherDuck, and you can compare it quite nicely to Redshift and Snowflake, for example, around what it looks like for speed and price compared to, you know, what the legacy warehouses look like. And this is great because if you take the same query pattern that you're running in MotherDuck and on Snowflake, you're going to spend
5:0410 times as much. And so you want to obviously use AI as much as you can to make this all work. It's really good at doing this type of work so that you can actually do the hard work that requires a human. And so we believe MotherDuck is nicely positioned for that in the future. So let's hand it over to Hugo. You want to talk a little about Orchestra, Hugo? Yeah, absolutely. Let's dive in.
5:28So, yeah, I think we also probably can't take credit for anticipating the wave of how everything had to be, you know, controlled as code, especially for agents. But it's sort of nonetheless, like, great practice. So at its core, like, Orchestra is an orchestration engine, super easy to use.
5:47Under the hood, everything is declarative. We have our own dialect. But really, what I describe it as is a single pane of glass. So it's not just a platform that's capable of, like, orchestrating all of your workflows, but we can help you with the monitoring, the metadata, the alerting. And obviously, having all of that metadata and lineage is one, you know, it's fantastic,
6:09because then you can surface that to agents as well. I guess one thing MotherDuck and Orchestra have in common is just, like, the massive parallelization and a very, like, serverless nature. So, you know, it's not like you have to run Orchestra on a node, and then sometimes stuff gets too big, and then everything falls over. Everything is serverless. It just runs.
6:34So, yeah, like, a big thing we fight against is obviously, you know, folks building stuff in Airflow. The value proposition I normally say is, well, look, if you're a, you know, large organization, and you want to have multiple environments for multiple teams, what you have to do is deploy multiple Airflow instances, like, have Kubernetes, deploy all of that.
6:58And then even then, to get your context layer, which is obviously a hot topic at the moment, you're then hooking up observability tools, catalogs, you're standing them up separately, like, you're editing your Airflow code to make it even more complex, pushing all of that data into the context layer. And then on top of that, the question becomes, like, oh, well, how do I even serve that to people? How do I run agents? It's yet more infrastructure. So,
7:20what Orchestra is, it's like a unified autonomous architecture you can use to just massively reduce tool sprawl. Next slide. So, yeah, these are the high-level numbers. They're some big numbers. You have to see it to believe it, but we will see it today. So, we can crack on. And, yeah, we've got a ton of awesome customers,
7:45ton of awesome partners. You can actually see the little octopus in the back. Cool. Demo time. All right, let's do it. Why don't you pull your screen up, and I will throw it up on the screen here. Sounds good. But, yeah, I had a lot of fun demoing this, and hopefully you all will, too.
8:09Okay. Let me pull this up. There we go. Thank you, Jerel, for pulling that down. Okay. All right. Sounds good. So, just before we start, I'm going to kick off this skill that I've built, and then I'm going to talk through it. So, essentially, what I'm going to do is I'm going to show us how
8:30I'm going to show us how we can use AI, MotherDuck, and Orchestra to build an end-to-end data engineering pipeline, but completely from scratch. And I'm going to say, like, it's a little bit different to some of the other demos where you might see Claude just, like, generate some Python, and then it moves some data, and then, you know, like, it's just there. This is designed to be a
8:54bit more of, like, a production-ready flow. So, I'm going to talk us through that. So, the first part is obviously defining the skill, which we have here. I'm not going to go into it in the actual skill, but I'll talk through it. So, first component is staging database. We're not going to be taking data and just, like, landing it in, like, in our prod database. We're going to have a staging
9:17database. And this is really important in the context of agents, because if you don't have that sort of, like, sandboxed environment, then agents can kind of do anything, and that's obviously bad. Second part of the skill is essentially to tell Claude to generate a couple of extra files.
9:39So, the first file is obviously the, like, Python code or whatever code you're going to use to actually move the data. But then the second thing is going to be deploying that Python code and deploying this full end-to-end pipeline in an environment that can execute it. So, in our case, that's going to be, like, our sort of pipeline. yaml, which is how Orchestra is defined.
10:06The other thing is we're going to set up a little branch. So, down here, you can see I've got, like, my feature branch. It's pretty small, but it is there. And then, yeah. So, in this case, maybe taking a step back, all I asked AI to do is I've asked it to get the linear cycles data using
10:29Orchestra and the DLT skill. So, linear is a little bit like an issue tracking software. You know, that's what we use. And I've just asked it to go ahead and get that cycles data because I want to kind of see how we're doing. So, that is what Claude has done. And if I take a look on the left,
10:50we can see some stuff is happening. But it looks like we've already kicked off the job. So, if I head over to Orchestra, we'll see that this pipeline is running. So, I can go ahead and take a look at that.
11:10And it's pretty cool. Essentially, what we're going to do is we're going to run the Python code that's going to land data in the staging DB, and then we're going to snapshot it, and then we're going to move it to staging. So, I guess if we just have a quick look at exactly what has happened,
11:33AI has generated two sets of files. So, the first set of files is the Python code that's moving data. We're actually using DLT. Yes, I can. I will zoom in. Yeah, all good, all good.
11:51So, I've created or Claude has created some Python with DLT that is, you know, it's like a pretty standard data ingestion script. We've got some fields. We've got a source. You know, I'm not an expert here, but it works. And it's also been cover. So, it's added things like parameters that
12:14we can use. So, you know, the number of days for the data we need to get, like the name of the staging database, the name of the data set, and that's all running in very nicely. But then the question becomes, like, okay, well, how am I actually going to run this, right? What am I going to do in it? And that is the orchestra pipeline. So, where, like, running all of this Python code
12:36in, like, an airflow might take you, you know, hundreds and hundreds of lines of code. In this case, it's actually just, like, a few lines of YAML. And, again, you can kind of see some of these inputs that we've put in here. So, that's what AI has generated. And now orchestra is running
12:54it. So, if I head over to our pipeline, we can see that, well, the one I had earlier and the latest one have both completed, which is pretty great. And I just want to talk very quickly about what these MotherDuck functions are doing. So, before we head to MotherDuck, you can see that all of the
13:18data ingestion has happened. You can see that everything has been parameterized, which is pretty neat. And then we've done two things in MotherDuck. So, the first thing is to create this thing called a snapshot. And it's pretty cool. Like, Jacob, hop in if I don't say this right.
13:38But a snapshot is basically like, you know, like a historical cross-section of some data. They're immutable, but it allows you to essentially copy data from that snapshot into another table. And then that second step is essentially when you're taking the data that you've just loaded
14:01and putting it into a product. So, that second step uses this functionality, which is copying data from the snapshot into the ProdDB. And you'll see that because we've got this lovely lineage in Orchestra, we're only going to actually promote staging to production after all that data is coming. Fantastic. Yeah. I'll just call out just like quickly, you know, one thing we're
14:25thinking about is because, you know, we do have, or I guess like, because we have this notion of differential storage, which you maybe heard of as like MVCC and other databases. But we kind of think about it a little bit more holistically. You know, we want you to be able to kind of handle these pieces. And you do that with agents because, or as you do that with agents,
14:49you have the right abstractions so that you can do this in a safe way, which I think is like kind of the underlying piece here, which is you can build a nice workflow that lets you safely kind of send an agent to it and then run your tests. And if they pass, you know, you can promote it
15:06to prod. I'll fix my volume. Thank you. Yeah, no, a hundred percent. So, yeah, this is like, this is a really nice flow, obviously, because we now have this as a sort of, you know, like, like its own branch. If you wanted to sort of split this up and sort of run this and staging
15:29and then create your PR and then merge it and then sort of like run the snapshotting as like a result of you merging the code, you could, you could do that as well. But it's, it's really, it's really, really easy. And now I'm just going to head over to MotherDuck and show you what everything looks like. So I'm going to take a little look at the MotherDuck information schema
15:55query history table. You can see that we have done all those things that I said we would do. So we've created a snapshot like we've copied it in. You can use this to kind of like take a look at the snapshots. And then if I have a look at just maximize this, I have a look at the actual
16:16DBs we've got. So, again, you can see here we've got our staging database. And then here we have our production database, which is essentially just like, you know, we're just cloning data from staging, which is almost like a working branch and, and pushing it in. And Jacob,
16:36I remember seeing that like with snapshots, they all happen on the database level. Is that right? Yeah, the granularity of snapshots is, is indeed at the level of database. And so like one thing that's different about MotherDuck is that you will typically have many databases, like maybe like a database by source or by purpose. Whereas, you know, I don't know,
16:59something like Snowflake, you might have like, you know, dev, test, and, and prod. MotherDuck, you will have potentially, you know, 10 or 100 or 1000 databases, just depending on how you want to do that. And that's just because of differences in how we think about what a database is and what it's for, you know, compared to a traditional kind of client server model that you
17:20would see in, in, I don't know, Postgres. So it's a little bit different there. I think like I saw a question that was relevant here. Let me just throw this in here. Why do you, did you need to snapshot? Interesting, my mic is still low. Okay, let me see if I can fix this problem. You want me to take it? Sure, go ahead, take it.
17:47So, like, if you don't snapshot, then what you're going to do is you're going to take this database, and you'll need to copy it into this database. And that means you're not doing a zero copy clone, which means it's going to be slow and expensive. I think that's a short answer,
18:12right? Yeah, that's right. I'll get really close to my mic. Everyone can hear it. Yes, that's right. You don't have to do this, of course, right? Like you can do this in much more traditional ways. But like we're thinking about unattended workflows that are also safe, right? So how do you let
18:31your agent do something in a way that is reversible? And so by using a snapshot, we can always fail back to it, right? And I think that's a critical piece. You know, I suspect that as we go along here with better and better AI models, that we will be looking
18:49at our code less and less. And that's kind of what I'm thinking about. Yeah, so that's basically the flow. I added one extra thing here. So in MotherDuck, they have this pretty cool feature
19:06called dives. And a dive is just a set of like TSX files. So it's essentially like BI. BI is code. But it's pretty cool because it means that as you, you know, as you're basically building out all of your like data pipelines, if you need to have things like dynamic content, like agents are
19:28very, very good at taking some of that dynamic content and just putting it in. So, you know, this is this is an example, you know, it's pretty dense, pretty boring. But just now, you know, I asked it, I asked the agent to update this dive that I created for linear data, which I've moved in. And again, I've not made this dashboard, like I've not, I've not learned TSX. You know,
19:52the AI has done it for me. But you can see we've got a couple of nice bits. So we've got the last updated app, which is showing us, you know, 20. past 20 past 3 UTC. So if anybody is a, you know, skeptical stakeholder and they come into this dashboard and they want to see when it was updated, they kind of have the answer. But we've also got this little thing to the orchestra run. So that is going to take us right back to the
20:17lineage. So if you've got slightly more technical stakeholders that want to see exactly what's happened and when they've got, they've got all that information to. Yeah, that's what we got. Amazing. Amazing. We've got some good questions here. So I'm going to pull a few up here.
20:37First one is, let's start with, well, let's just start at the top here. Let's go here from Nico. I think this is kind of, we didn't really talk about this in the demo, but I think it's relevant to what you're thinking about with orchestra here. How are you thinking about tying it into semantic and modeling layer tools?
21:00Yeah. So that's a, that's a great, that's a great question. You know, we could obviously make the agent not just write Python that lands data, right. We could make it do more things. So maybe if you're learning data in S3 and then you need to load it somewhere, run like a query task. If you wanted the agent to like generate some basic dbt modeling, that's like, you know,
21:23renaming columns or unpacking Jasons, you can do, you can do all of that. So in that orchestra pipeline, you know, if you wanted to have like another, another section, which is just going to present again, if you wanted to have another section that's running your, running your dbt, um, that would be, that would be super easy. So here, for example,
21:48let me throw your screen back up. Cheers, mate. Um, you know, here we're sort of creating that snapshot. We're promoting it to prod. Um, you know, maybe before that you've got some like dbt modeling and again, because everything in orchestra is code, it's super easy.
22:11There you go. And, and what you just showed that interface, you just showed like that is, that is the same interface or not, not the same interface, but the, the skills that you've built out for orchestra also can, can edit those files and, and make new ones. Right? Exactly. So, um, this is all like controlled in get. So you see, it's all code. Uh, it's all bi-directional.
22:31So if you then like do it from the UI, uh, you can go to get hub, which has an extremely slow API these days, uh, because of, because of agents, um, but again, like you can, yeah, I know. Right. Um, but yeah, you've got both places. Okay. Very cool. Sorry. So, so, so like, not only do you have, you know, a nice UI that is easy for human to use, you know, the,
22:56the abstractions exist for you to kind of say, Hey, Claude, like go add this thing or fix it. Okay. Right. Exactly. Yeah. And like, you know, like, like MotherDuck, we have like a CLI. So if you start like from scratch somewhere in code, you can do a CLI command that registers a pipeline in orchestra too. So that's why you see, we've got these little things like aliases.
23:19Yeah. Really cool. Really cool. Um, all right. Uh, let's see. Next question here. Um, um, okay. From Rohan, uh, how many agents are using, how easy complex was this, the setup? This is Claude with one skill.
23:40So, okay. So like, um, that sounds easy. Can you, can you, can you give us a little more detail? Yeah. So, uh, running, running Claude Code locally, um, we have built a skill or like, I built a skill for this demo that's, uh, generating, generating some of that code.
24:03Um, that lives, that lives in your like dot Claude skills folder. Um, trying to think if there's anything else, that's like a bit of a pain. Um, honestly, like it was, it was pretty easy. Uh, one of the things I didn't talk about was like how you need to set up like your tokens. So in this case, cause we're pulling data from linear and landing it and MotherDuck and doing
24:24stuff with orchestra, there would be at least three sets of credentials, right? Like you need credentials to go to your source database. Uh, you need credentials to like land stuff in MotherDuck, and then you also need the orchestra credential to like interact with our API. Um, so yeah, setting up, setting that up is probably, probably, uh, a non-trivial part.
24:46Yeah. But I mean, I think the point is like, once you have the kind of, uh, you know, tool endpoints configured for our security access, um, you know, the prompting is, is fairly trivial, I think. Well, the great thing was right. Like I haven't had to write any MotherDuck skills cause I just used the MotherDuck MCP. Um, and I noticed that when
25:07Claude didn't know what to do, like it can go to the MCP and use the docs. Right. Um, and I think with orchestra, it's kind of the same thing, right? It's like, what do you do with orchestra? You like create pipelines, you run pipelines, you debug pipelines. Um, it's like a nice, nice layer of abstraction. Yeah. I love it. I love it. Um, okay. Another question here,
25:27uh, from Claudia, uh, I guess for questionable services, how do you handle PII data? Is it self-hosted custom cloud set up and you want to take this first? Yeah, sure. Okay. So, um, uh, MotherDuck is, you know, uh, we, we are fully ducked to be compliant. So we do see some customers running some portions of their pipelines kind of in their own cloud and then serving like
25:50data that's been stripped from a PII perspective, uh, into kind of MotherDuck for serving to their end applications. Um, we do, we are, we do also have, um, we're also, uh, in the EU region, um, uh, in eu-central-1, I think, which is Frankfurt, um, for AWS, for example. So if you do have like questions about, or concerns about like, um, where the data is domiciled, you can
26:15always set up a European region. Um, uh, but in general, you know, we see people are processing it before if they really, really care about it. Um, you know, from a, from like a MotherDuck perspective, we do have quite a few like healthcare clients here in the U S and so we have very tight security controls around where that data is used and how it's used, um, by us and how we secure it.
26:36So, um, you know, I think it just depends on what your, your internal compliance policies are, but no, there's not a like, Hey, you can drag and drop MotherDuck into your VPC as of yet, at least. Um, you know, in the future, who knows what the future holds? Um, yeah. Onto your massive notes. Yeah. Yeah. Yeah. You go, you want to take, what about orchestra?
26:58Yeah. So I guess the big difference between like an orchestra and like a older orchestration tool, like an airflow would be that we don't really like want to process or store any of your data. Um, so orchestra is all cloud hosted. We basically push queries down to databases. Like we trigger things that move data, obviously in the demo, like I moved some data, I processed some data.
27:21Um, and in that case, we just like have hybrid options. So running all of the compute in your own infrastructure. Um, yeah, great question. Um, okay. So let's do, do, do, do drop that one next
27:37one. Okay. Um, let's see. Um, Dan has a question. Actually. Hang on. Oh, we'll take this one first. Um, default default database snapshots create storage cost overhead. Um, so the answer is, it depends on how long you keep your snapshots around by default. MotherDuck storage can, uh,
27:58keeps like seven days of snapshots in our storage. Um, and so if those are, if those are, um, if you're keeping them around for less than seven days, they're kind of just like free as part of what you get. Um, you can, uh, we also have, we also have what we call transient databases, which don't include, or I think only include one day of snapshotting or maybe zero days.
28:21And so in that case, you would have some incremental costs, but because everything in MotherDuck is kind of incremental, um, generally as long as you're building your datasets incrementally, um, it's, it's fairly low overhead to use, use the snapshotting functionality. But again, like, you know, uh, I think that designing here's what I would say.
28:41Um, if you design your database to be incremental, it's very cheap to use this type of functionality. If you don't design it to be incremental, maybe you're using like full replace and like really big dbt jobs all the time. Um, which we do see customers do and they say, Oh, that's kind of expensive to run. Um, you, you, you do need to kind of think about it a little bit differently because we do keep all those dips around. Um, and again, there are like
29:04controls you can, you can leverage, you can pull, um, to, to make it, um, behave a little bit differently, but you know, the default is seven days. Um, okay. We have something in here too. Um, from Peter, it was hard to see, could you probably link to the orchestra and linear? Um, Peter, I'm not quite sure exactly what you're trying to get at here. Um, but I'm pulling it up
29:25just, you know, Hugo, if you want to just like, I guess like, Oh, Oh, I think he's talking about like what the, um, GitHub, like you have a, you have a, you had a pipeline, right. Defined for orchestra and linear. Is that right? You just want to, you just want to show that real quick
29:39and walk through it. Let me share this for you. Perfect. Okay. Yeah. So this is like a visual
29:58representation of the pipeline. So the first task is running Python. Um, can show like definition of it. And essentially it's, uh, you know, like this is a form, but on the, under the hood, it's declarative. So what we're doing is we're calling this a script, which is a school like
30:22linear cycles pipeline, but that, uh, that tracks to this, like this script down here. Okay. Got it. So, so basically it's, it's building the script using the DLT library and then DLT has a connector for linear. And so it's fairly trivial to kind of like tie in the keys and just, well, I, I, I actually don't think it did have a connector for linear.
30:43I actually think it just created it using the light. Yeah. Because I, I asked, I asked this on the, on the slack ages ago and they were like, ah, no, it doesn't exist. And I was like, okay, well that's now, um, but it's cool. So yeah, that's the, that like, that's the first bit
31:02Peter. And then the second bit is leveraging like one of, uh, orchestras tasks. So we have different tasks that wrap logic, like authentication, triggering stuff, pulling stuff, error handling. And obviously we have a MotherDuck task. We support running, you know, state-aware orchestration with dbt or MotherDuck too. So Jacob, like you were saying,
31:24might be a, might be a good way to save some costs and all those incrementals. Um, but yeah, this is just running like a, like a snapshot command. Uh, and then you can kind of like see that, see that, um, see that in the, in the thing here. Okay, cool. Okay. Love it. Thank you for sharing that. That's really cool. Um, I'm going to pull that question down. Um, question
31:47here from usual, uh, what's in the skill MD? Is it just a instructions or a bundle of helper schema references? Great, great question is, um, it was quite long. I got Claude to do it. I edited it a bit. Like I found it pretty long to be perfectly honest. This is what's in it by the
32:11way. Um, so I literally gave it very, very, very like detailed step-by-step instructions on how I wanted the flow to go and why, but it didn't take long to generate, but I did think it was quite
32:30long. I think, um, I do think that like there, there's a little bit of skill to generating the skills, right? Like how do you, how do you, it does take a little bit of iteration, but like, I don't know. Um, uh, yeah, I see there's a comment from Ryan here down in the chat here, which is basically like the, like, I'm not sure what's in there, but like it works for Claude,
32:53right? Um, I think like in general, how I'm thinking about skills is like, I'm generally not reading them. They're, they're for Claude and I'm testing them to make sure that they work. Um, do you ever find yourself like going in them and making them more concise? Sometimes, you know, I think, um, I think like in general where I'm finding myself with AI generated text
33:18just broadly is like, if it's for consumption by other AI, I'm not looking at it too closely. I'm kind of just like, okay, like I know this works, I'm going to send it to someone, they're going to give it to their Claude. But if I know that there's a human that's going to read it, I'm like copy editing the crap out of it. Like, I think like to some extent, like,
33:38uh, for me, it's like, I want to respect my audience, right? If you like, hey, like if I'm, I'm not just going to drop slop on you, but like for AI, I'm like, you know what, Claude, you can deal with other Claude slop. Um, it's very funny. Um, but I, I don't, I don't find myself generally refining them too much. That being said for some things, you know,
34:02we, you showed this briefly, actually, there was a MotherDuck dive in your demo. Um, as part of that, there's a skill in the MotherDuck. Um, I'll take this off real quick. There's a skill, there's a skill in the MotherDuck MCP to, um, uh, to get the dive guide, that dive guide, or sorry, there's a tool. Let me read the right words. There's a tool in the
34:25MotherDuck MCP called get dive guide. And that is a skill. And we do really care about that being concise enough. And I think the main reason is, is two things. Hey, if you're serving the skill all the time, you want to kind of think about token usage a little bit. You're not like thinking about it maybe as a first priority, but certainly the second priority. And the second thing is you're running evals on it, right? So like, as we change these small changes to text,
34:46is it improving the ability of Claude to build this object? Right? So what, what, uh, Hugo showing here is actually a bit of react and SQL that you can build with a MotherDuck MCP and Claude. I'm sure that actually you probably could put that skill right into an orchestra pipeline and just like at the end of it, build a, build a dive. Right. Um, which would be really cool. Um, but anyways, this is a feature we have MotherDuck that lets you, lets you build these really,
35:09really cool kind of, uh, BI visualizations. Um, but it's, it's, it's a good question. I think, um, around how we think about it. I think there's a related question. Um, any estimation for the process consumed token usage? Like how I think, I think the real question here is like, Hey, great. You guys are building all these tools. Um, are you thinking about and
35:31measuring? I'll ask, I'll give this question to you first and then I'll answer it. Are you thinking about measuring like how, how efficient your, your, your tooling is in your, uh, software as an orchestra for AI is to use setting me up? Um, I mean, I think, I think definitely, right.
35:50I think this, this process took about 10,000 tokens. So not a whole lot, but equally the output is basically just executing code and doing get commands and doing some bash.
36:11Mm. So I, that, like, that's why I was so, I'm sort of like a little bit unhappy with the skill itself because it's just like, it's way too verbose. Like if I wrote it myself, it would just be a list of like commands and steps. Yeah. It'd probably be like 20 lines. Yeah. It'd probably be 20 lines of code or something. Yeah. Right. And then, and then, you know, inevitably, right.
36:35Like the agent would, would be faster. Um, but you know, you know how it is in AI demo world. Do these things last minute. Yeah. Yeah. Uh, what do you think Jacob? Yeah. I mean, so it's a great question. You know, um, I will just talk about, you know, as we're thinking about, uh, you know, the way, the main way that MotherDuck interfaces with
36:58AI agents today is via our MCP server, our remote MCP server. And so we think carefully over every single word that's in those tool descriptions, like, Hey, we want them to describe and the tool correctly. So it's used, but we don't want to have any extra words in there. Um, and I think like that is a conscious decision, right? You can overload those,
37:20you can not be as thoughtful about them, but we are very thoughtful about what goes in there because, um, ultimately, uh, you know, I suspect, you know, as we showed in that slide previously, like your agents are going to be running tons of queries, which means they're going to be running tons of tool calls. And so if we're not careful, we can easily just like blow the crap out of, out of our context, um, which costs us money, right? Every time we retrieve it, it costs us
37:44money, even gone cash on cash tokens. Um, so that's a, I think a really good, um, or like how we're thinking about it right now. Um, I will say that like on the dives portion that we were just showing, which lets you build BI, um, that's quite verbose from a, um, from a perspective of using cloud and tokens just because it's raw react. And, um, uh, for anyone who's used it,
38:09you know, I think the way that you, the way that you can make this tighter is you use libraries, right? So you use libraries and you use kind of pre-baked components. And I think like that's, that's definitely on the pathway for what we'll build at MotherDuck is like more components, more, um, uh, more, uh, uh, libraries that let make it just easier for AI to use it. And that means that it's writing less code and therefore consuming less tokens and more efficient. Right.
38:33And so you just kind of got to know where it is. Um, did you, did you, uh, did you all ever consider a declarative scaffolding for your BI as code? Uh, I think, you know, I think it, it, it, this is such a good question actually. Um, I think we will probably back into it.
38:53The initial kind of Genesis of it was more like, uh, we were noticing people were just like using our MCP to build visuals with skills and then sharing them with each other. You'd like by slacking skills to each other basically internally. And we were like, okay, we should just like make this a little more prescriptive. And I think, um, in some ways we think about it as like being
39:17totally off the rails as a benefit. But the downside of that obviously is that it is, it is more expensive to run because you can build anything in it and you know, you may have to repeat yourself to build a specific component. You know, if you want to reuse it between dives, for example, that's can be difficult, but anyways, um, all right, Paul brought Paul brought up something. We'll be a little bit less self-indulgent. Um, we'll take two more questions by
39:40the way. Um, you edited a pipeline generated by the agent in your demo. Hugo, did you update the skill MD to include what you inserted yourself? Uh, I didn't know. So you would, you would have to do that. Um, you'd have to do that yourself or you could just like go into Claude and be like, can you update the pipeline? And then it would probably be like, do you want me to update the skill?
40:02Yeah. Right. Right. Right. Exactly. Do you, do you, do you think that this is a related question to this? Do you think about source controlling your skills when you're building like an orchestra pipeline? Yeah, yeah, definitely. Um, I mean, I think, I think for us, like, you know, it was slightly, slightly more early days like on the, on the skills. Um, but yeah, absolutely. Like source control, the skills have versions of them put
40:25evals on top. Um, it's just like when you're actually, you know, building a pipeline that is deploying data and moving data, there are just so many moving parts, right? It's like, am I judging it on speed? Am I judging it on token usage? Am I judging it on whether or not the data actually gets to prod? Am I judging it on like the quality of the ingestion script that I just made? Like, you know, it's, it's, uh, there's a lot there. Yeah. Yeah. That totally, totally makes sense. I think like one thing I've
40:50noticed is like, as I'm getting more into like agentic workflows is that I'm explicitly building my readme for humans and I'm building my, my cloud MD file for my agent, right. Or, or an agent's MD file. And I guess one thing that I've changed in my workflow is like, okay, the readme is going to be super tight. It's designed for humans. You know, um, the, the Claude MD will be like, you know, much more verbose and, and we'll kind of be more
41:14comprehensive, but, um, at the trade off of like not being really interpretable by humans. Um, awesome. Yeah. All right. I don't think we have any, any other questions coming in here. We really appreciate everybody's time. Um, Hugo, thank you so much for the really awesome demo. That was, that was smooth, man. That was smooth. Well, uh, I've, uh, always, always wanted to do a demo with, uh, with
41:37DJ Komatsan. So lifetime, lifetime achievement goal, complete. Um, we'll send you a trophy. Uh, all right. Cool. Thanks everybody. We'll be wrapping up here. Uh, we will be sending it, uh, sending out links, et cetera. Um, so you can see it if you, if you were able to miss, if you missed part of it and, um, we'll catch you on the next one. Thanks everybody. Cheers.