0:00Hey everybody and welcome. Thanks so much for joining for our webinar today. So I'm really excited to be interviewing Patrik Devlin. He's the CTO and co-founder of Hazel. We're gonna talk about a huge variety of things, a lot about their AI powered platform for consumer brands and also the architecture behind it. So we'll go as deep as you guys would like. Patrik, do you wanna say hello?
0:24Tell us about your background. Yeah, thanks for the intro. Yeah, super excited to be here. We've been a user of MotherDuck for quite a long time. So it's nice to finally talk about how we're using MotherDuck, how we're using DuckDB and what's kinda coming in the pipeline.
0:49But yeah, as for myself, yeah, I'm the CTO and co-founder here at Hazel. I've been working on Hazel for the past two years. My background is really as sort of an IC, software engineering, doing work front end, back end, some data stuff as well.
1:11And yeah, I kind of use that to work with my co-founder, Clint Dunn, who's also a data guy. So it's been helpful having a partner who understands the data stack. But yeah, that's about it. Fantastic. Well, sweet. Well, I'll give a quick rundown of where we're headed and then pretty quickly we'll jump in.
1:36So first things first, we're gonna have a look and see what Hazel is and how you can use it and some of the AI features around it. Then we'll talk a bit about what's under the hood. We'll talk about the data side. Around here, we like to think that AI and data are really, really connected. You can't really have AI that gets the right answer without data. And if you have messy data, it's no AI can really solve it.
1:59So we think they're really related. After that, we'll talk a bit about maybe more of the traditionally AI side, which is the context. But that turns out is also a bit of a data problem as well. It turns out that context comes back to your data too. And a key thing as we're talking, please ask questions. It's our favorite part. You can pop them in the chat. We'll ask them as we go,
2:24as they fit in with what we're talking about. And we'll have designated time at the end. So keep them coming. That's really my favorite part about this type of thing is to make sure that you guys learn what you're looking to learn. So with that, I'll turn it over to you, Patrik, if you wanna show us a bit about Hazel. Great, okay. Yeah, so I'll share my screen. All right.
2:48Let's see here. You see this all right? Yes, it's coming across great. All right, nice. So this is sort of the Hazel homepage. We went into, we started building this. We wanted it to be a very familiar experience. So you'll notice a lot of the controls
3:12are similar to what you would get at a chat or a Claude. I think the real magic around Hazel is on the data side. So we'll jump into that. And I do have kind of this secret feature we've just released.
3:36MotherDuck has just done some really cool stuff with introducing PromptJev into their product. So yeah, it's a great use case for our customers. So we went and plugged that in and we'll break the fourth wall a little bit here because I was trying to figure out how to demo this.
3:59And I realized, what's the best place to start? You kind of ask, hey, what can I do here? What would be a good use case? And then I realized our demo account really doesn't have any sort of like text-based, long form text-based data.
4:22So it came up, Hazel came up with its own kind of classification concepts. And then actually, let's see here. So what long form test can we classify this tool on? It's like, we don't have any. So then it suggested actually connecting
4:45some other sort of vendors. And then finally, I was like, okay, what can we do here? We don't have any of that data, but we actually do have some interesting things like email subject lines in here. So one thing to know is that this demo account is all barbecue related.
5:09My co-founder's from Kansas, so we went with the burnt ends. And here's an interesting use case. So we actually take PromptJev and we tag, create these classifications around that email subject.
5:32And then we actually merge that back into all of the, around 10 million emails. And now we can start to sort of categorize and understand open rate, click rate for emails at a classification level that you're choosing.
5:55So here's some other ideas that Hazel came up with for you guys. So we can see if we can test one of these out. So let's see, mark cancellation reasons as control or not. Ah, churn analysis. That's an eternal question for any company. Love that. Exactly.
6:20And while that's thinking, I probably have a question or two for you as well. Just to be sure, I'll make sure we're prompting correctly here. Oh yeah, that's okay. We're in demo land, we can be picky with what we ask. So while that's thinking, I'd love to hear a little bit about kind of Hazel overall, sort of what does the product help with,
6:44who are the people that tend to use it, and kind of the vision for Hazel and who you're building it for. Yes, yeah. So Hazel is sort of a vertical AI solution for consumer brands. So we think about it as like an AI coworker, an AI operator. We're still playing around with the verbiage there.
7:08But what our sort of stance is, we spent a lot of time sort of on the data stack and making sure this foundation of different types of dimension tables
7:29and different types of fact tables is all set up and also has the right sort of like context for an agent to work with. So this kind of prepackaged solution, you come in, you can connect different types of integrations and once that data syncs,
7:52your agents kind of set up and ready to go. So you have this like full understanding of what's underneath. And then the tricky part is like, okay, well, all these brands, they might sort of have different ways to calculate metrics, different ways to describe things.
8:16They might have their own type of language that they use. And so how do you like over time sort of capture that through the process? And so we spent a lot of time on the sort of like context layer and memory as well.
8:39So that as you use Hazel and as like a collective, not just like a single person, as the entire brand uses Hazel, can she actually become smarter over time? And can my conversations influence your conversations?
9:00Which can be a delicate, like a delicate problem because you don't want to sort of introduce any like security issues there. But there are sort of like nuggets of information in each person's conversation that can be helpful towards, you know, Hazel's understanding of the brand.
9:25Oh, that's really cool. Yeah, I can imagine that, you know, I'm in DevRel, which is under marketing, but I can't call myself a full marketer, but it's a pretty data-driven industry, you know, to understand how well a brand is performing, to decide what to do next. So I can absolutely see the data connection there as well. I also know that, you know, people will be and do, you know, just ask a vanilla AI some similar questions,
9:49right? Like, hey, Claude, what should I do differently in my marketing? Can you talk a little bit about, as you're building this vertically focused AI product, what are some of the ways that you're differentiated there? What are the, what's the domain expertise and kind of that specialization around consumer brands that you guys bring? Yeah, yeah, yeah. So, like I mentioned,
10:11my co-founders has been head of data in some of these brands and- Oh, wow, great. Yeah, and so he brings like a lot of expertise around, you know, how to think about, you know, different types of data. And we've kind of taken that, some of that knowledge and sort of plugged it into,
10:34you know, Hazel's best practices. So, you know, things around different types of, you know, LTV analysis. That's lifetime value for us mere mortals. Yes, yeah, yeah. But yeah, so the idea is we've kind of pre-packaged Hazel
11:00with this sort of context layer that's tailored towards consumer brands. And the other thing, the other bet we sort of took was you need, you need to be able to sort of sit on top of, like raw warehouse, like a raw warehouse data set.
11:25And what I mean by that is like, we don't do a lot of sort of aggregation at the end layer that you would typically see if you were building for, you know, Looker or some other type of BI tool. And the reason why is because Hazel and the agent is becoming so good at pulling insights, you know, across data sets.
11:51And so we actually just kind of create this sort of like open canvas for Hazel to operate in under. Don't make us, we don't make too many assumptions on how things should be used, but more so how data relates to each other.
12:13And I think by using sort of taking this bet on DuckDB and MotherDuck, which was pre-GA when we started, we were really excited about this notion of how we can supply, you know, a large set of data
12:34to a user in a really like quick and fast manner. So sometimes, you know, Hazel might run through, you know, 20 queries checking itself during that time. And, you know, I don't think that's exactly,
12:58I mean, it is possible, but, you know, you're not getting a lot, you're not getting the same type of performance as you would if you went to like a BigQuery or Snowflake, for example. Yeah, I think that the way I like to think of it is if the high level pre-aggregated table could have answered the question, you're already done answering that question six months ago, right? The interesting questions for right now are in the details.
13:22And so going down to the raw data is important, and then making sure you can do that with it being fast and without breaking the bank. I think that matters a lot. So you've had this demo chugging along a little bit and answered it pretty dang fast. And then I kept asking you follow-up questions. So yeah, what has Hazel found for us? Let's see, yeah, let's see. Okay, the trend comes mostly from change. The share of cancellations we can act on rises
13:47from the list that rises, not change. If the new cancel flow, moving house, not using enough, stop appearing. Let's see. Let's look at what classification.
14:09So it seems like we ran three things through PromptJet. One was classifying each cancellation reason as controllable or not. Applying the tags to every cancel session. Trending the controllable share of cancellations by quarter to check the cancel flow menu change.
14:32For context, this data is coming from like a subscription platform. So if you're ordering something from a brand click the subscribe, and then you have to go through, you know, after you've gotten your 20% discount and you wanna cancel, you have to go through the cancel flow
14:55and usually there's like two or three questions. And so this is what we're trying to understand here in this thread is what is actually like driving that cancellation. Love that. And it's using Jev, which is very, very new. So maybe we could zoom back just a little and talk about Jev. I think it's great that you were showing us
15:20how you were building a demo. And I totally understand because Jev came out like one or two weeks ago. So it makes sense that you don't have a 5G demo for a brand new way of using AI. So maybe tell us a little bit about Jev, a little bit about what is appealing for that in your product and then just what it felt like to implement it in a week or two.
15:44Yeah, yeah, definitely. So, I mean, Jev, we deal like our dataset deals with a lot of opportunity to run sort of this classification model on top of. And we also do a lot of sort of segmentation
16:08for the marketing side. So you can think, okay, hey, I have, you know, I wanna create a new sort of email segment. Hazel can use Jev to sort of, one, identify like what those segments should look like, but then also, I was gonna write here,
16:33output as, you know, some sort of like spreadsheet, which then can be, you know, uploaded into the external system. And so, you know, we see this as potentially like driving a lot of the different type of like email campaigns outside of like sort of conversational BI. So yes, you can use Jev to sort of segment
16:58and understand your customer base better, but also, can we start to like impact external systems? Yeah, that's my favorite part is to not just understand, but then go take action, go, you know, increase brand awareness, increase real revenue. So that's awesome. I just wanted to say thanks, everyone, for your questions that are coming in. They're really great. I do see those there. We'll get to the data side in a little bit.
17:21And I think your questions will fit in really well as we get to that piece. Well, sweet. Well, was there anything else you wanted to demo of Hazel? Right, right. So I think one other, I did want to touch on, you know, this concept of artifacts, but in particular, we have implemented MotherDuck's embedded dives,
17:43which are very, very sweet. And I was particularly excited about this because I was looking at using the DuckDB sort of WASM SDK for a long time and didn't totally have an avenue to do that.
18:07And then, you know, this embedded dives concept was released. So we plugged that in. Hazel, you know, if you know dives on MotherDuck, Hazel builds, or Claude, or whatever sort of AI tool builds the JSX. And then, you know, it's plugged into, you know, whatever sort of MotherDuck warehouse is sitting on the backend.
18:32And this becomes a really great avenue for us to not only support a lot of just your traditional BI use cases, but also give users the flexibility to, you know, create them as they want. And, you know, we see a lot of people will do their like initial exploration and then, you know, come in here and say,
18:55okay, I've validated a lot of this information. I've validated how this, you know, queries are running. Let's submit this into something that's like reusable. And so these become sort of like relics or artifacts for Hazel that also can be referenced in chat if there's sort of any type of conversation
19:18you want to have on top of these numbers, but also just as a way to, you know, come in and get your, you know, get a quick look at your dashboard. I love that. Yeah, here's your top level dashboard you look at all the time. And then if you see a spike, good or bad, you can then follow it up with a chat and say, hey, I'm looking at dashboard X, and it's going to be able to go pull the SQL
19:42that powers it, and then go get the next level analysis for you. So that's pretty slick. You also briefly mentioned DuckDB Wasm, which is pretty sweet tech. And I see it in action here, you're doing some super fast slicing and dicing. Yeah, talk a little bit about that. Yeah, I mean, that was the part that drew me.
20:00he really drew me to the tech is the fact that we actually kind of create this like we pull in this local copy of this data set. And so as you're filtering, as you're sort of slicing through this data, which one, these these filters are sort of controlled and written by you.
20:22So you describe, you know, what filters you want. Hazel has some general like best practices around around what people like, but really, you know, you can kind of be creative and add whatever you want.
20:36And so as you're as you can see here, as you're clicking through these different types, we're actually just pull or filtering that data on on the browser. So that's that's particularly interesting because you get this incredibly fast experience once you sort of preload that data set in.
21:01Yeah, I'll echo that a little bit. You know, I I love playing around this stuff. Some of my favorite as well. You can have even millions or tens of millions of rows you bring down locally. And because you actually run a whole database in the browser, which really no other mainstream tool does right now, they're running still somewhere else. And so that means you could slice and dice basically as fast as you can click on it, which is just pretty sweet.
21:28Well, thanks for showing those. Yeah, I'll stop sharing for a second. What's next on the agenda? Yeah, next up. So that's that's kind of our look at our demo. If you guys have other questions about the Hazel platform, pop those in. We'll answer those. I think one question that folks had around the platform was around the actual prompts that people are using in your platform.
21:51Do you track that and use that for other kind of ways that they can look and see, like, hey, what data sources are we using? Or maybe you guys use it internally to figure out how to how to help brands more stuff like that. Yeah, yeah, we so we have Langfuse set up.
22:11We tried some other observability and kind of telemetry tools, but ultimately landed with Langfuse. It's been great. I think as far as user observability, we do not showcase the exact like queries that are being used.
22:34And that's that's mainly because one, there's the user doesn't like know how the transformations are being created on the back end. So the queries actually like aren't super meaningful.
22:49And honestly, like going having users like go and, you know, look through a bunch of hundred lines of SQL is, you know, it's not it's not a great experience. And so actually, can you can you build that for us in a different way? It's kind of the angle we took. I think you're ahead of the curve. I think all of us, even data people are looking at SQL a little bit less.
23:14I know I'm writing it a lot less. I think especially with your target audience of like, I have a brand. I want to improve my brand, my revenue like they may not be in the weeds of the SQL. And I would say probably not. So that that makes a lot of sense. Right, right. Yeah, definitely. You know, we're not selling as technical users.
23:34And so I can see if we was a more technical product, you know, it could be useful, maybe make it available sort of in the side there if you want it, but not a part of sort of the main experience. I bet you could prompt your way into it if you really asked that. Hazel, right, right. Well, fantastic. Well, well, maybe we could dive into the data side a little bit.
23:57And so as you're building this platform where you're you're exposing a data warehouse to an end customer. To a lot of people, that sounds mildly terrifying, right, because the historical way of doing that is you have one big warehouse and everyone has to fight over it or you have to keep it up all the time, even if no one's using it. Or maybe it takes, you know, minutes to spin up all kinds of craziness. So I'd love to hear a bit about the data side of what makes it work.
24:22All right. Right. I do. Let me pull up the architecture. That'd be awesome. OK, OK. So I wrote this first and then I was like, OK, let's have Claude add some particles to this and make it freaking cool looking. Gussy it up a bit. All right.
24:42So I have this sort of architecture that I run you through. Great use of tokens like. Oh, I love it. I love it. So here we start.
25:02There's really like six steps to sort of funneling this consumer brand focused data to our end users. Claude even created this nice little tour for us. So I guess we can we can use that.
25:19But you through our platform, you go through and you connect to different sort of vendors and, you know, you might need to create an API key or two. Some of it's OAuth. But at the end of the day, we're looking to sort of capture a lot of the commerce ecosystem.
25:40So at platforms, we take in a lot of support stuff, email and SMS, which can be pretty high volume. And obviously, you know, your Shopify's and things like that. And so then the ingestion, this part is interesting because we initially started with using sort of this homegrown DLT system.
26:05And we realized that there's also Fivetran being sort of a tie in in the sort of ingestion space just has so many connectors already built.
26:24And so we moved to this kind of hybrid option where we run Fivetran for things that are already on there. And we save DLT for any custom stuff that's really not supported by Fivetran. And, you know, there's there actually is quite quite a bit of that sort of consumer space.
26:49It sounds like another really key value thing, like getting to the data is often, I think, really the hard part. And if there's a certain data source that consumer brands care about desperately, you know, the average, you know, data warehouse provider didn't have a connector for, like, all right, that's pretty sweet. Right. No, definitely.
27:08And, you know, sometimes it may take an email to someone to add your API key. I guess that's part of our offering at the end of the day. Oh, yeah. Oh, yeah. Whatever it takes. Whatever it takes. Whatever it takes. Exactly.
27:26I think the other sort of advantage of having this hybrid system, too, is we can control what's sort of spend on Fivetran. Fivetran is, you know, row based, calculated by monthly active rows. And so we actually took some high volume connectors that were on there and just move them into DLT.
27:48And I think over time, we actually can absorb more of it into our own system just because it's more cost effective. But it's this constant sort of balance between, you know, velocity and spend. I love that you have both options, because, yeah, there's a spectrum there. So you get to pick the best. That's cool.
28:10So this next spot, we sort of land everything into our raw data lake in S3. We're doing some experimentation with DuckLake. So you guys have me on next year. We can talk about that.
28:30But right now, it's a high partitioned S3 data lake. And each org that we support, or our customers, has their own partition, has their own section. And here in steps four and five, this is where MotherDuck comes in.
28:54We do all of our dbt transformation. I think we have some like 700 models right now and growing. And this takes you through your kind of typical sort of medallion type of transformations.
29:14Again, we stop at this sort of raw, closer to raw layer than most. And the idea there is around pushing a lot of the intelligence onto the agent to understand how things should be tied together.
29:38And then the next step here is around isolation. So we have this sort of single warehouse. We can't just expose that to every user. So here we isolate the data. We give them their own sort of MotherDuck catalog.
30:00And that is also partitioned by service account. So no service account can access anyone else's data. And that actually has, not only does it have this sort of security benefit, but it has some interesting benefits around compute sizing.
30:23So you may have one brand or one org that requires a lot more resources. Maybe they need more read scaling than other orgs.
30:36And the service account architecture, this like hyper-tenancy, which I'm really excited about, gives us a lot of the flexibility to sort of toggle that granularity on a per brand basis. That's awesome. And I'll pop up a question that you've mostly answered. I just pop it up in case there's a couple of details there to tie into as well. But thanks for the question, Michael.
31:00Can you talk about the multi-tenancy and the data isolation for different users at the MotherDuck level? And then I think the next part would be kind of how Hazel ties into that logic. So I assume that's related to kind of the service account side of things. OK, yeah, so just to clarify, data isolation for different users at the MotherDuck platform level.
31:26OK, so on the MotherDuck side, we have a service account per org. And the service account is named after the org ID.
31:42And then on the Hazel side, you know, you have your users, users belong to orgs.
31:57And I think one of the things I learned some of my past jobs was always pass the user ID and the org ID around the system at sort of every layer.
32:14Because there are places in your sort of code base or some of your logic that may need to go out. In this example, make a request out to MotherDuck.
32:27And so when you have this like org ID as this really like native part to your code, you can always use that to access the credentials or access the service account here.
32:41So. So just to back up a little bit, you're in Hazel request comes through our API gateway that gives you your user ID and your org ID.
32:56The org ID is used to access the look up the read write or the read on the credentials associated to that service account. Yeah, I think that into the first part. Yeah, I think it's great. I guess the whole thing. Yeah. Cool. Yeah. End to end. Love it. Well, fantastic.
33:20Well, we got a couple other great questions from the audience. So maybe we'll jump into a little bit of Q&A. If you guys were thinking about a question, pop it in. We've got some time to tackle them. So I think this is top of mind for a lot of folks these days. When you have an A. I. centric product, how do you balance the A. I. costs and also the speed of the querying?
33:40So maybe this is an A. I. cost question for maybe your model usage and then also database cost question as well. It's a very data heavy A. I. use case that you have. Yeah, yeah. That's a great question. I think we've I mean, we constantly run into this. We're doing a lot of costs, you know, optimization ourselves. I think.
34:05Compared to. Compared to our dbt sort of transformation spend, the cost of Hazel running queries is actually very, very small on the MotherDuck side. So that hasn't been a huge concern. Really, the concern is around sort of token costs there.
34:27And so all of our query tools both have. Limits on how much data can be returned. You know, if you if Hazel queries, you know, a couple couple of thousands of rows, you're going to pay the piper on that one.
34:48And so we actually have three, three or four different bands of limits. And we transform the response of the query tool depending on how much data is in there. And so some so it's not always JSON.
35:06Sometimes it's like a TSV tab separated value. Sometimes it's just your traditional key value pair. And we keep that pretty low. And then we give Hazel.
35:28We give her the other tools to actually look at the broader data set. So a lot of the prompting is around one, like. Make sure Hazel's writing aggregates or your agent is writing like more aggregations so that the amount of data is not coming back. But also, you know, we support on our end. We support sort of spreadsheet creation.
35:51And it's not like we're having Hazel query it and then stream all of that data into the spreadsheet. Hazel is actually just writing the query. That is sort of the foundation of that spreadsheet. So Hazel writes the query and then we go and execute that and stream it into the spreadsheet.
36:12And so that's a way to actually support these like larger volume workloads without having to funnel it through your agent. Yeah, I mean, select star from giant table, putting that as tokens. That sounds mildly terrifying. So I love the great rules that you built up.
36:32And yeah, poking the agent towards pre-aggregating and then giving it a tool for bulk exports and stuff, especially spreadsheets makes sense. I will say TSV has a special spot in my heart as well as a format. It's like CSV but better. You can tell you've seen a thing or two if you're using TSV instead of CSV. Right here. Love that.
36:57And I think I'm really glad to hear that the kind of like end user facing AI data use is not, like the querying at that end is not the big pain. It's really about just like transforming it, getting it ready. So I think that's just one thing hopefully we've taken off your list of having to worry about is you can have a big computer for your computer and then you can have small ones for each user.
37:19Or if you really want a big one, like you said, that everyone has that, you know, those 10% of customers. Yeah, absolutely. Well, sweet. Let me pop in another kind of scale related question as well from Steve. So curious about the scale of data that you're querying at MotherDuck. And you can kind of answer that however you'd like, but how would you kind of categorize your scale? Interesting.
37:43So I, let's see. I think probably the largest table a brand, a customer has access to is around sort of the event data coming from their email platform. That is probably around anywhere from 500 million to a billion rows.
38:08I think I actually have some notes here on some of the size of data. Oh, nice. Let's see. Let's see. So each from that sort of architecture diagram, each org database would be anywhere from up to a terabyte on average.
38:32Granted, it really depends on the customer and how large their sort of shop is. But we do deal with some like pretty, pretty large, pretty large data on the email event side. And then sometimes those are super small.
38:51And we've had to tailor our transformation, our data pipelines around sort of specific sources that are producing like a heavier volume.
39:07As far as like, you know, Hazel working with it, I haven't really noticed a difference from like a query speed or latency. I think we're probably not even pushing the boundary yet. So. Nice. I mean, terabytes, not nothing.
39:28I think that's, I think the other part of this, too, is you've split this and made it a manageable problem. I think that fits with the story of, hey, end-agent querying is not a problem for a couple of reasons. One, it's a MotherDuck. But two, also, you've compartmentalized it to where each agent only has to worry about, you know, a terabyte, not, you know, the whole thing altogether. So. Right, right.
39:48I think one, another note on scale that might be interesting is, let's see, we did through MotherDuck last 30 days, we did 5. 75 million. have a lot of queries. Wow. So that's around 190,000 a day coming through this system.
40:09That's awesome. Yeah. Hammering on it. But that's great. I mean, when data is a big part of your product, that's what you want to see. Sweet. Well, good questions from everybody. Thanks for keeping those coming. I'll ask another one. So we had a question about the Wasm side. Is there a ceiling on data? I could take that a little bit.
40:36Most of the time on Wasm, when someone's creating a dive, most of the time when you're visualizing it, it tends to not be very large in general. Because even if you're doing your cross filters and your charts, I don't run into this much. But I've stretched the bounds up to somewhere in that 100 million row range. You could probably be more comfortable in maybe the 10 million or 50 million
41:00if you really want super snappy responses. But you can actually do quite a lot, especially once you get into customer-specific data. It starts to be a very good fit for bringing that to the edge. And I think dives will do that basically under the hood automatically for you. And the way it works is you ask it to create a cache or a local copy or a temp table,
41:24and it'll just create a temp table. And then all the filters become instantly fast. So it's one of those, we like to joke, everything is one prompt away. In this case, the one prompt is, do it locally and make it fast. And you get it. That's 2026 for you, man. It's a great deal. Let me see then. All right. I think we had a couple other questions.
41:52One came in here around DuckLake. You mentioned that you are looking at it a little bit. So maybe we can talk about that just a bit. And we haven't talked about the future. So a couple more questions, then we'll talk about the future. Cool. Yeah. So we are using DuckLake. Currently, our data lake architecture is
42:15split in between two. One is sort of less innovative, I guess. We built it before we built it before open table formats were really starting to take off. And
42:38we got into this position where we run this append-only data lake. And we're just accruing too many small files from syncing. And our solution or one of the solutions was to
42:56look into DuckLake and leverage some of the sort of natural capabilities of that through compaction, but also using the catalog to speed things up as well. And so I don't really have, we haven't used it enough to have a huge opinion.
43:20We haven't had issues yet. I think there's a lot of promising stuff that it offers. And I think for us, we do deal with a lot of small sort of data syncs, as well as the kind of large ones. And so the data inlining feature is particularly
43:41interesting as well as a fast way to kind of move data through. Yeah, absolutely. And that's one of my favorites. I'm very biased. I'm writing the book on DuckLake. So I had to put this book up. I didn't know that. That's cool. Yeah. So we've got the chapters written. We're releasing them as we go. So we're up to five of them out there. And inlining is where, yeah, instead of doing everything into tiny parquet
44:05files, you can put them into a database temporarily and then flush them out to a parquet file when they get big enough. So it's a really nice way if you have data coming in really constantly, you want that low latency, but you don't want to hit exactly what Patrik was talking about, where you end up with a lot of tiny files and that's still not fun even on object storage.
44:26It's good at a lot of things. It's not good at tons of tiny files for sure. Well, awesome. Well, thanks everyone for the questions. Keep those coming. I think there's a couple more we'll get to here in a bit. I think maybe a couple of questions. One is sort of, as AI has changed a ton very recently, what are some of the things that are the biggest changes that you've seen at Hazel and the biggest things you guys have done in kind of response to
44:50everything that's changing in AI? Yeah, yeah. I think, let's see. From when we started working on Hazel, I think there was, we spent a lot of time like working on managing what context
45:11is injected when, and that was mostly because the context windows were much smaller. And we also felt that the models were not following directions as well as they are now. They sure weren't. They were definitely not. And so we did a lot of work in the beginning to
45:32really like steer Hazel in the right direction. And now I would say we build a little bit differently. Obviously you still need to pay attention to how much context is being pulled in, but it's able to kind of parse through that information a lot better.
45:55So we're not spending as much time on that. So I think that's been a big change. Sorry, what was the rest of the, what was the rest of the question? Oh, that was it. Yeah, what's changed? So yeah, the model's getting, needing less direction and also, yeah, being able to handle more context. So that's absolutely perfect. And then I guess I'm curious, as you're
46:18looking to the future, what are the things you're excited about from the platform side in Hazel and then also, yeah, on the AI side? Right, right, right. So we have this kind of, we built the Hazel around this like chat experience because we knew it was familiar. I think one of the exciting
46:39things, and you're seeing a little more movement towards it with, you know, the release of Dots and Rockbot, but this concept of like this background agent or this ambient concept. And yeah, I'm excited for like kind of the next phase of AI to actually be a little more proactive.
47:05Maybe it's finding stuff about your business and it's coming up with plans to fix it and it's notifying you about it versus, you know, you having to, you know, go in and actually pull that, those nuggets of information out. And so that's something we're really excited about and looking
47:25into a lot is this like ambient nature of Hazel and how she can be more proactive. Yeah, I love that. The, like the AI teammate approach to, I think it, is it Grokbot or Muse? I need to, I think it's Grokbot, but that's a different mentality for me. I have not thought about it that way, but you guys already have an AI coworker. So you guys are ahead of the
47:50game thinking about that. Hopefully, hopefully. Yeah. Yeah. Very cool. Well, fantastic. Well, I haven't seen any new questions come in. Was there anything else you wanted to tell folks about, about Hazel? No, no. Thank you guys. Thank you guys for listening. This was super fun. You know, I've been, I've been working on this for, for two years. And so it's nice to be
48:13able to talk about some of the stuff we're building. We are, we are hiring for, for software engineers and data engineers. So please reach out on LinkedIn if you're interested. I would love to, love to chat with you. And I think maybe we can provide a link to our, our careers portal,
48:38if possible, Alex. Oh yeah. That'd be great. I could find that. And yeah, I think the, you can tell you get to play with fun tech. You can tell that it's, it's AI, but actually useful, right? It's not just, you know, I have this little chat window off to the side. It's, it is very core and central to the product. So really exciting stuff you're working on. And
48:57I think the data side is pretty fun too. No bias there. But yeah, if you have that link to the careers page, I'm still looking for that. I don't know if I've sent it to you yet. Let me, here we go. Where should I post it? Oh, Slack is fine. Or you could post it either way.
49:21There we go. Sweet. We'll definitely have a look there. Really appreciate it. They, they were very, you know, Hazel was super early on MotherDuck before we allowed people to pay for it. Right. This was in beta, right? That's true. That means that they're adventurous there. And that's the type of place you want to be. If you want to learn how to use AI, you can't go somewhere where you can't install anything on your laptop where like, I went to a conference recently and
49:43like, there are still industries like that. And this is where you get to actually use the bleeding edge and have it for a real thing where customers get to benefit. Totally. Well, awesome. Well, thanks everyone for your questions. Thank you, Patrik, for your time and quack on everybody. Thanks so much, Alex. Appreciate it.
