Build an AI Analyst with Claude Code in 50 Min | Sumeet Marwaha

Eight months ago, it was just kind of debugging SQL. Now AI can really start to write that initial boilerplate SQL query and code that helps you then build on to do more advanced analyses. I've set those dashboards up many times in my career and they end up like kind of just getting ignored at some point. Cloud will always read it. Cloud will always kind of start to ask questions. Recreating the way a data scientist actually thinks inside of a company. They're not just thinking of only the data. They're thinking of all the things outside of that. Podco is the first tool that I feel like could actually accomplish that. — Which AI coding tool has the most momentum? Which one's gonna win? — The customers on our platform have already picked it is definitely cursor. Cursor is absolutely kind of brushing it in startup coding tool of choice, but also enterprise coding tool of choice. — So before we get into the cloud host stuff, can you talk about at a high level how AI can help with like typical data tasks? So yeah, here's kind of like the high level view of what I would say a typical analyst does in their role and really how cloud code can start to augment that. You know, I could kind of think super high level and think about what kind of you would do from starting from scratch, but the reality is most people in their current job, they're not starting from scratch. They already have a series of dashboards. They queries they're running. And so at a very kind of starting point, it's actually just monitoring those things, right? And so Claude can actually like run your queries for you and look at them and understand what the trends are and summarize them in a way that you're probably if you're in a role inside of a company like checking those four or five dashboards um and constantly trying to understand, okay, is this trend actually a meaningful change? Is it something I need to investigate? Um because the LLM's can actually like interpret those things themselves, it can actually help you scale that to monitor more than you might typically choose to monitor by spending hours by looking through each kind of dashboard and cell. It can actually do that for you. And I think that's been one of the first kind of real kind of game changers when it comes to folks building their own little monitoring agents uh and dashboards within cla and then you know once you see that trend and think about you know I probably do want to investigate this claude does a great job of building out context either through the actual data itself but also what's going on in Slack um these other tools like linear and tickets that are kind of like being created around that particular topic and cloud can access all that which is honestly the job of a data person right you might want to actually like dive into and actually do that work in advance propose hey it looks like one of your metrics have changed let's go into the customer level transaction level and understand is there something out of the norm happening in those trends so that exploration phase is actually really powerful um if you already kind of know what you're monitoring and what you want to track, you could jump right into number two and actually be really helpful. — And then also uh crafting a story which

not all data scientists are good at, you know. Yeah, this one is, you know, where the it starts to kind of drift from something Claude can do perfectly to where Claude really kind of getting help and kind of guide folks where with the craft part um trying to actually tell a story that changes people's minds that truly like proposes something that makes sense to the business is where you really have to kind of use your uh you know prompting to actually give it this like ability to translate back to you what a good story is. And so what's great is that it can kind of do those side investigations, those deep dives. As you start to craft a story, you might realize there are kind of things you want to investigate and add to, which ends up being, you know, in reality a bunch of comments inside of Google Doc. But you can actually take those and have kind of claude work on those in a pretty quick manner to hopefully fill in any gaps as you start to layer in this story of what happened. And what's great also is that as you start to like propose certain changes, you can start to like look through the codebase, look through pre experiments, through things that have been done to change something similar and actually start to size what the potential impact is. — Awesome. Uh and the last one is just about impact, right? — Yeah. The impact piece is this is what the one thing like I haven't quite seen cla go from end to end in this way that I know is possible, right? as kind of each of these different steps starts to improve like you can imagine the world where you set up kind of claw to do this analysis it understands the code base understands how things have changed in the past and actually goes in and changes a particular button you know in your app to be in a different order then runs an experiment on that and then starts this whole cycle again to understand how that experiment has been successful or not successful why that's not the case how to tell the story and what to change and then propose again and actually implement those change. So this loop of analysis is something that every data scientist is working through alongside the product managers and engineers and I've already seen clot start to augment each one of these uh and I think we all can understand there is a future here where it can actually do all of them um in sequence and kind of continuously do that to actually be this like endtoend product manager, data scientist engineer all at once. Yeah, I've worked with like a quite a few data scientists in my career and um there's like a bunch of stuff that they don't actually want to do, right? Like they don't want to write SQL manually. build dashboards. It sucks dashboards. — Uh they don't want to like they want to do like deeper analysis and deeper thinking but like a lot of the work is just like building dashboards and like you know the PM pay them like hey can you run this random query? So, so yeah, if they can use cloud to, you know, try to do a lot of that work or at least do it faster, like that would help hopefully increase job satisfaction a lot too. — Yeah, job satisfaction, but also the PM satisfaction of being able to get those numbers without having to talk to a data person to go get it. I think that's one of the examples talking to the team and product managers uh here at B seen folks just take a dashboard that exists take all the queries throw it into cloud code have it run every single day or week whenever they're trying to check on kind of what's going on in the monitoring step here and do their own explorations do their own investigations around what's happening and — kind of cuts out the data person which maybe isn't you know great for job satisfaction but what it does do is have them ask better questions Right. And that leads to that work of actually having time to do better analysis, deeper thinking around how to actually improve the product. And that's been really interesting to me to see that stuff start to actually happen here. Let's take a quick example. So like um I think most companies have um like you know every Monday or something or like every Friday uh there's like a superet or something that like generates a chart, right? Or like send sends you an email with a bunch of charts. But like uh with cloud and you know AI, how is that better now? So instead of just sending you a dashboard, it will actually do a bunch of insight analysis. — Yeah, I think there's two parts that make it better is you can kind of customize it really easily, right? You can set up this dashboard to be what maybe a team needs, but maybe there's folks on the team that only want to know certain things or really customize it to be about one type of the users that are using particular product or feature. Um, and Claude can quickly modify, change that, make it very customized to that person's role that what they care about. So, that's one of the things that I've seen do it do really well. Um, and then additionally, it can actually like run that analysis, do the follow-up ask or at least generate the questions on what I think happens when those emails go out. It's like, okay, some people read them, some people really read them, come up with like all the questions. Cloud will always read it. Claude will always kind of start to ask questions and then kind of you can start to see oh like can I actually have Claude answer these right and it'll start to try to answer it too and I think that kind of you know ability to always know that someone is reading it is part of what's important because I' I've set those dashboards up many times in my career and they end up like kind of just getting ignored at some point by a group of people that are getting it because they felt like they should have got it but they actually end up don't. Um I don't think Claude ever feels that way. So there's that kind of like feeling that I've seen a lot where it actually means someone will read it even if it's just Claude. — Got it. And also like your slide, the fact that it has access to more than just the data warehouse. It has like the Slack access and a bunch of other contexts hopefully will help it come with better insights, right? — Yeah, that's that was huge. Like for example, we had kind of an incident uh here and it was affecting some of our metrics and the metrics that were running in this weekly review started to kind of change. it was able to understand there's an incident happening at that specific time uh and that impacted the metrics right it was a data incident so it impact the actual end customer but it definitely impacted why these metrics look wrong but it searched for that um in our Slack uh I was able to see there's some fixes ongoing some tickets being created to resolve that um so it saved me like what have would have been like wait what's happening to the data like I had to go look at specific customers maybe you kind you know, leaving, but turns out there was actually a real reason for it on a Monday morning that — got it. — Started, you know, me the process of fixing that incident. But still, at least um Claude can understand that pretty quickly. — Yeah, that's awesome, man. Yeah, I feel like most companies don't have that set up at all. Like, so yeah, it's great that you and are doing this. — Well, I think most companies have like a data person who's kind of like just doing that, right, all the time, reading the these things, searching, right? Um, but now you can kind of help that person do this. — Why don't we make this practical? Like maybe you can show us how this stuff actually works in CL code. Maybe like let's take like a public data set or something to look at. — Yeah, cool. Let's look at kind of the startup funding round data sets which kind of mimics Brexit's data because they're just transactions, right? Money being moved from one venture capitalist to a startup. And so that's why I'm kind of picking that one. And um I'll kind of go into like how I set it up. Um some of

the pro potential problems that comes with like doing aentic analytics and how you can kind of address that in the setup process. Um and then try to actually show you some of these use cases. How does that sound? — Sure. Yeah, that sounds great. — Um all right, let's go into it. Let's kind of start here. Um, so the first thing I would kind of think about is actually like what is the data set that you're trying to build kind of an MC what I'm kind of using here isn't the MCP framework. Um, and I think the part that you really can start with it's pretty simple. You don't have to get too complicated in how you think about like give the claude code three queries around the metrics in a specific domain within your company and actually start to instruct it to build an MCP around that like that. That's it. That's all you really need to start up kind of what I would call is like a pretty basic MCP. Now, as you add in more domains, things start to get a little bit more complicated, but for us, like that was kind of the initial formation around trying to start this. And so um thinking through this data set here I'll open up um the three queries I have and so you can just kind of look at them. We have kind of using this we call it market data inside of brack these funding rounds. We're just kind of looking at some basic information around the first one here being monthly startup funding trends by industry and stage. Um they're kind of showing the kind of cloud code how to write these queries, what a typical join would be. A lot of it's based off domain name. Uh so that's kind of something that's being established here. We're adding some documentation around what this you know table kind of has inside of it. Um you know why there's two tables, right? One is the funding rounds and one has the actual startups. uh along with how are these kind of funding rounds like named series_a helps kind of give it that guidance later on uh we added a second query to think about the other set of data in here which are the investors so I'm kind of trying to build two to three queries that have each of the tables at least one join together um to kind of show cloud code some of these patterns and some of the key fields inside of the codebase and so kind of looking at that trying to rank the top investors trying to add something around kind of when how often they're funding these customers in their most recent years. Um and actually here's the third query which we have the startup ecosystem healthcore. So this is one where you might actually have some analysis examples. So like two basic ones to really illustrate um how to build some of the metrics within the data set and then I'd say one to try to show how you might actually think about doing something a little bit more complicated um something that's actually like trying to understand the velocity of funding that a particular you know startup ecosystem um is seeing. So that's something that I found to be really a kind of a good uh set of kind of criteria for starting this off. — Okay. So you wrote these queries manually or maybe with some AI's help. — So there's actually like you can kind of reverse engineer them. You can actually go in and search for these tables and see what are the queries being run inside your Snowflake instance um and start to pick from there. So that was that bit of how I started with these because I didn't necessarily want to like sit down and just create queries that are being used because these tables already existed. I was able to really just like scrape them off of what was um already being run in a dashboard or in our Snowflake um instance and then kind of start to like actually ask Claude to document some of them uh which you know doesn't always happen uh in the actual like running of the queries. So that helped kind of layer in some of this. So the goal here is just to maybe give Claw some understanding of how to run queries for these different tables. That's kind of — exactly kind of give it those rails. And so here's kind of where I would start to actually write um kind of the prompt to actually generate the startup MCP. Um we actually kind of go in and say, you know, create a startup funding MCP. Um, and I would say don't use the existing one. Um, that uses these three queries. And I think I would try to kind of also instruct it to do some research, do some research online about ways to set up a great MCP. Um I probably also want to give it kind of like a rough idea of what like these data sets are. Um so this data set is um a overview of the funding rounds uh for startups and includes the investors uh transactions and startup details. Uh I also kind of want to tell a little bit about kind of why we might want to use this. We want to use this to understand what types of new funding rounds are happening amongst our customer set so we can you know engage with them. So it's obviously really valuable to us when we understand someone's getting a bunch of funding to like engage with them and make sure that they are happy on brides. I think I kind of also think about giving it some instruction around kind of why I want to use the MCP framework as well. So like um we want to build an MCP that allows us to build weekly recurring reporting. do deep dive analysis and do a quick kind of help monitor trends within startup. It's kind of it. I think I also like always like to kind of have it think of trying to do an eval set. Um, and then like if you kind of set it up that way, you can then later on, you know, edit and understand what the eval might look like and change that. So here I would actually um say create three eval questions to test the MCP at the end. And I think in this case also because it's a startup funding data set there's some questions it might try to think of that are actually kind of correct not too domain specific to bracks. Um so feeling kind of confident there. So we'll kind of uh obviously go into planning mode because that will actually help us um see how it's going to process and understand this um and we kind of see what the plan looks like and edit it. just for the people who don't understand like why uh why make an MCP for this task. — Yeah. Um — yeah. There's a bunch of I think the core reason I think about why an MCP is you want to be able to have Claude access your data in um a structured way that is somewhat repeatable across folks using claude to do this types of analysis. So without the MCP, you could think of, you know, someone tossing in a query and telling claw to answer a question about startup funding rounds, it's not going to understand there is, you know, a way to do that. There's some documentation that exists that's been kind of developed by the data team and kind of um the folks that have been kind of writing these queries. And so to me, that's one of the values here is the MCP kind of starts to build those rails so that anyone who tries to access this data can start in the right place. I think we always understand that there might be modifications outside of that initial starting place, but so far I've seen the MCP kind of framework help connect to Snowflake in a consistent way to write queries more consistently. Um, — got it. and actually like enable kind of that analysis uh step. — Okay. So yeah, basically they don't have to do all this setup each time if you create MCP. Yeah, — exactly. — Makes sense. — So it's asking me some questions here like should I use all four queries? I mentioned three. Um so kind of do you want to deploy it to production ready? I think I'm just going to say locally need production ready. um saying I should have some alerting so I can actually develop that. Um I don't think I'll do any alerting in this step. Just kind of skip that. Um and then here's kind of the answers themselves. So I always love to have these kind of like unanswered questions come back. Kind of makes me feel more confident about the plan — um that's coming. — Yeah, this is like a new feature, right? I don't think I used to ask all those questions before. Uh yeah, I did set it up uh in my uh user — Oh, yeah. Cloud MD. — Yeah, cloud MD to always ask me those. So, I'm not sure if it's new, but yeah, I definitely saw someone give that tip. Maybe it was on your uh pod and I kind of have added it's been really useful. — Nice. — You might even ask even more to be honest. — And sorry, this maybe is a dumb question, but like how is this thing how is this project that you have the Summit OS connected to Astro database? It's it just you connected before or — I didn't cover that. Yeah. Uh basic I set up the kind of Snowflake CLI. Um so it actually has access via that and then to like ensure it's a little bit more reliable added in the Snowflake pat token and — kind of added that to my cloud. So it's able to access the Snowflake instance to uh view those things. — All right, man. You asked it do a lot. So it's got a big list of tasks to do now. — I know. Yeah, it actually added a little more to than what I thought. But um — yeah, — we'll see kind of how it progresses and I'm happy to talk while it's building um because I did have it bypress permissions on some of like the potential issues that you can come through come up uh that I'm happy to talk about some of the issues that come up when you actually do analysis with AI. We usually kind of feed that back into the MCP and have it kind of address some of those issues. — Yeah. Should we dive into it? — Sure. Yeah.

— So, when it comes to like problems that I've seen doing a lot of analysis with Claude, um there's some specific issues that I think are different than how you might want to use Claude to write a doc or um change the codebase. And it comes to the fact that when you actually write a query, it might return 10,000 rows or two million rows, right? Actually blowing up your entire context window. Um, that's unlike a like kind of what you might think of claw doing when it comes to navigating the codebase or kind of reading docs. Um, it's typically not going to run into that problem in step one. And it actually could one when you actually task a data agent to go solve a problem. Uh and this is where in the instructions that you actually give it to actually write queries, you can actually give it the understanding that's an issue and that you need to manage your tokens as you're progressing through an analysis. Um and the part I want to layer in that's really important, you need to remind it that the previous query it ran had a limit because it might actually just take that table it queried with a limit 1000 and think it's the full table. But being able to kind of give it both of those tips to me has really unlocked um kind of chain of analysis that can lead to a really good result that Claude in just like kind of like prompting without that was struggling to kind of answer. Uh and so that was something that I really kind of learned firsthand trying to tackle some of these analysis questions with quad. — That's a good point. Yeah. — Yeah. Yeah, and I think in that vein in what a data MTP is really good at is you can actually really limit how much of the kind of data set it's actually going to use. That means you know we have these things called core data inside of brack um but the truth is even in that core data table for our customers there's about eight ways we segment the customers and each of them might be necessary for a particular use case. Uh, I found if you start to kind of give it all eight, cloud gets confused, the AI agents get confused on which one to use and might pick a different one for each time it runs through um, an analysis. I found like really tight semantic context. Just having one of those segmentations available also helps ensure that it kind of gets the right answer. Um, and that, you know, as you actually kind of start to layer in more and more of that context, not just doing the startup data domain that, um, we're trying out here, but also the car domain and the banking domain or whatever part of your product that you're trying to add, that tight context is super important. Um, otherwise your kind of explorations will get lost or start to get wrong. Um, you can't just import your whole table into Claude. When you say tight semantic context, you mean just like telling it which of the 12 sources to look at. Is that kind of — Yeah, telling it to only look at one of those um semantic context here isn't what I'm kind of using to call a semantic layer as well. Um so you can actually kind of give it that series of fields, the dimensions and the definitions and some of the use cases of using it. But if you add — two that are basically the same, it's going to get confused. Um got it. And so it's almost like you really just need the one and that might limit some of the kind of possibilities, but it actually ends up getting you kind of a lot further along of something useful in um your engagement with the agent. — Okay. Yeah. Because these tables aren't and columns aren't necessarily labeled well, right? — They aren't. Well, I would put it two ways. Like sometimes they are and people still get confused and there's that. uh and sometimes they're not. And you kind of have to start to think about some of the reasons you want to document your tables is for the agents to actually be able to pick through what um what fields you actually need. And so that kind of comes in two ways. Actually, the column name is super important, right? It'll check that first and just assume doesn't always even check on the actual documentation. So you want to be clear doing explicit naming but then when you do have documentation also ensuring that is uh kind of additionally clear. I think things that used to not maybe matter now matter are also like including things like synonyms. Um because customer segmentation might be you know called motion might be called grouping. Those things actually help the agent when it comes to processing a natural language query actually pick the right field. But you don't want to call two things grouping, right? Because then which one is it going to pick? Um, so being kind of clear about that is some of that tight context. And then kind of the last one that I found to be super useful is kind of what we were talking about earlier with you can't just rely on only the data set at hand

to answer a question. If you have uh other MCPS connected into your cloud code, that can really help craft a well-reasoned plan when it comes to uh why a particular trend is, you know, going in the way it looks. Um, bringing in that context is what claude does better than sometimes a dedicated BI tool where you wouldn't expect to connect in your Slack, your entire, you know, codebase into those tools to run a query. But with cloud cost is pretty low to do that and it actually adds a lot of value. Again, recreating the way a data scientist actually thinks inside of a company. They're not just thinking of only the data. They're thinking of all the things outside of that. um and bringing that to the table when they're writing analysis like cloud is the first kind of cloud code is the first tool I feel like could actually accomplish that. — Okay. Yeah. I love this. Um and it's all it's all about like context management, right? Because like you don't want to bring in too much at once, otherwise it's going to get confused, right? Like even with Slack, you probably don't want to bring in like every single channel, — right? Yeah. 100%. You don't want to bring in everything. Um you can kind of instruct it in that way to kind of look through. Um, for us there's like a bunch of data help channels or we're discussing problems. There's sometimes project channels that actually are super relevant. So, you can kind of give it that prompt as well to look, hey, go look at the project channel for this new feature, understand how that project's going, — uh, and start to write me a query to hopefully build a dashboard around when we actually ship this project, um, how to monitor that. uh and it does it surprisingly does that really well which is you know exactly what every data scientist always wants is to be brought along the project and then given this one of these tasks go the dashboard you kind of had to do that with cloud too — how did you uh how do you connect to slack and drive I guess drive is built in or — uh yeah with both of those we actually use the glean mcp which we kind of added uh and that's kind of like our enterprise AI tool that helps connect to all these apps So you can actually like set that up in cloud code and it can access your drive and your Slack to pull in the contacts. And so I found it to be really helpful to build sub agents for each of the connections. Otherwise, it might not even know if she needs to connect to the glean slack part when you ask it the question. But if you actually build sub agents for each of those um it does it pretty well uh when you actually like kind of give it the instructions. — All right, man. You got to make a GitHub repo and open source a bunch of this the stuff. — Yeah. — Uh let me kind of flip back. Awesome. So we can see here now we're kind of going into MCP that we have actually created that startup funding MCP um and saving it here in this uh OS because I kind of want to — have it uh just for myself. If I was to deploy this we'd move it to our kind of like centralized repository. um you kind of view the tools that we created. So there's something here around just like I've added that context to solve that problem I was mentioning around I don't want to blow up the context window. I wanted to actually be able to like sort through an analysis in sequence understanding the limitations we put on some of these queries and actually report out at the end of every analysis like how that's actually performing. Um then we just have a basic kind of querer that helps translate the tables into SQL queries which is you know very much the most used part of this MCP. Um, and then we kind of have the analyze startup trends, which basically like an analysis tool to help actually bring in some of these like common types of analyses and start to kind of build the rails of um what the sequence of analysis should look like when you actually analyze this data set. So the query kind of and analyzing tool are two of the kind of things that this MCP has. And so we can actually try to use this um right now. So like um using startup data MCP all the most recent series A deals in October 25 and bring rank them by those you think are most likely to get a series B. Uh so I've kind of added a basic part of this query which is tell me the most recent series A deals but I'm also adding the analysis piece which is I actually wanted to have an opinion about what it thinks a series B you know potential indicator is and so it kind I'm just kind of oneshotting here. Normally I might build a plan around this but we'll see if it can do it a little bit more quickly. What how do you think it's going to look at the data to understand series B likelihood like it's kind of trajectory or — Yeah, exactly. It'll look at hopefully I hope it will look at the past deals that got to series B and pick something of a criteria. Hopefully it's just like funding amounts or speed from series C to series A. Um that's where like this analysis funding velocity query that was created hopefully can give it the rails to do that um with a bunch of the kind of more interesting. So it it's already kind of done this here. There's only two series A in October. So first it's presenting to me that Glue AI 20 million series A and Pedal Surgical 10 AI and health tech. Um and it has started to actually rank those. Um, and I can kind of give it some questions here on why I picked that. — Yeah. Well, hopefully I'll just explain why. — Yeah, there you go. Percent rational. There you go. At the end. So, yeah, here's that report. — Um, so glue AI high probability for series A large series A 20 mil, which I guess used to be large maybe. So AI companies in particular are one of the things it thinks will lead it to getting a series B. Um I think that it says close in October. So you gives an expected timeline of a series A domain credibility being one somehow thinks that drives you know um a series B um and actually predicted what it thinks the series B should be. — Yeah. I mean it looks like it's not just looking at the data. It's like making some rational about like the medical stuff taking longer, right? — Yeah. Exactly. Yeah. And I'm hoping it kind of searched some of that within the data set too versus just kind of synthes like kind of coming up with it itself. Um because right we have that data. We have the history of all these funding rounds. It should be able to do that and it actually does do that right based on the series A data. 61% of healthcare companies got to series B um versus 73% of AI companies. and then kind of also looked at kind of the median size of a funding round that ends up becoming a series B is around 20 million. So you kind of see that as why Glue AI is number one because it has that $20 million funding amount. Um — yeah, it's uh it's thinking like a VC whenever it sees the word AI in there is like oh it's going to be series B. — Exactly. Yeah. It's already they're already kind of in the driver's seat even if you know we don't even know what Google AI does. Um from the perspective of the data set it is proving true that those companies do receive series B more likely. Uh so for that the data says it's correct. — How far back does this data set go? Like it's like a year or two or something. — No I think the data set goes back to 2016 even beyond. Uh, okay. So, it's pretty long historically back because I think at some point we had like the Amazon funding in there and it was kind of like creating some issues. So, we've cleaned up some of that, but yeah, we have pretty much all historical funding rounds. Can I ask a question? — Sure. Yeah. — Can you ask it like something about like um you know like whi which AI coding tool has the most momentum? Yeah, — I guess I Yeah. Do you want to define momentum? — Momentum as like, you know, just like, you know, which one's going to win, man. Like which one's gonna Yeah. Which one's going to win? — There you go. Yeah. Why? Yeah, it's good to explain why. — Yeah, I want to always give it the prompt to use the data because from this last example, I worry it's going to just try to guess, but So, here's that um question. So, it's going to pull all these coding tools. — Awesome. Yeah, there has to be like a lot of Yeah. — There's a lot. Yeah, they're starting up all the time. Um, yeah, it's interesting. I'll see what it says. Um, here. — Yeah, as you can see, kind of just those

three queries setting things up. Now, we can start to ask these questions. It kind of is getting pretty solid results using that base set and think of why an MTB matters. Now we can actually have this created for you the PMs that are trying to access this, the engineers this. We're kind of building on top of the same uh initial set of data. — But like those like three or four queries that you wrote is like really important, right? Because like it's basically just kind of reusing and those queries each time to get the information. — Yeah, it is kind of trying to create some new ones too. You kind of see like they're not exactly just copying it over. But you're right, like those three queries, trying to pick kind of ones that have joins in them that have multiple tables, uh, that have some like aspect of an analysis you might want to build upon is pretty important. And that's exactly also where I don't want to just invent them. I actually want to look to see what queries people are running against this table and start to pick from that. Um, got that way you don't have to like kind of create something that isn't actually following the current way folks are quering things. — And um, — the actual MCP uh that you built for Brexit like uh can anyone like can PMs use it and stuff? — Yeah, absolutely. Yeah, the way we built the data MCP is you all you need to do is like authorize or snowflake connect into the MTP and it should be able to run whenever you're asking a data question. and it'll write the query and actually generate you the result and answer and then you can build your own agents to kind of build your dashboard version uh okay set of those queries on a recurring basis. I can kind of show you um at least what I built on this particular MCP a version of that dashboard. But here's the uh answer. — Yeah, let's take a look. — You're looking for um — Yeah, so based on the data driven momentum indicators cursor, no surprise here. Uh huge series A. The valuation is a little lagging. See, I think 400 million plus isn't actually correct. So we can try to maybe investigate that. Believe now they're 10. They're 30 billion. But um kind of the key signal A16Z backing um is solid. Uh it also has some interesting research on why uh you think it's kind of uh a top tool. Um Replet another one kind of number two ranked ahead of I guess kodium windsurf cognition right? Um yeah, one of the issues in this data set is startups change their name and they get acquired and so you kind of lose some of the thread sometimes uh on those shifts, but um these are kind of the top three it thinks are going to win. — Yeah, I believe one or two I'm not so sure about three, but you know one or two are in good shape. Yeah. — Yeah. I think the data we've seen definitely agrees with some of that. Um — Okay, nice. This is awesome. This is fun. Yeah. Well, let's go back to my original question because like uh at companies with data teams, there's always a concern that if you get some random PM like access to like these queries like you know they'll just like run a random query that just like take takes down the whole database or like right so like um and with this MCB stuff it can actually incur a bunch of token costs right if someone goes off the rails. So I'm just curious do you have any controls in place? Yeah, I think that's something where I find like the new thing that cloud release skills actually kind of solves where you can actually design kind of these skills the agents tap into when it comes to building analyses or reporting to instruct it not to do that. And unlike kind of a PM like the skill will follow it, right? It'll be cognizant of the tokens it's using to make sure it doesn't take down the database. um it'll kind of point out the areas where it potentially is making kind of leaps in terms of how it's joining things together — uh and kind of reveal those. So as you know as a PM maybe start to try to productionize something or share it with your data person at least there's some way for that data person to like quickly understand what is the area I need to think about um helping with or fixing. Uh so we found that like actually to be something that is pretty useful when it comes to like creating these skills and we have like I have created a few skills here to um actually help with that like the ad hoc uh analysis skill. Here's like the um data analysis skill I have. Um — Oh, wow. — that like runs a bunch of these kind of context management um ideas, the computational story mapping. Um to think about these SQL queries as like a narrative versus just individual components. Being able to share this skill with a PM and tell them to use that at least gives me some confidence. It won't completely take down the database. — Um and that's something that's new, right? like you can't necessarily always teach someone that logic um and have them follow it every time, but skills you could. — Yeah, I haven't dug into skills, but it sounds so it's not going to let me join like two million row tables together. It's not going to ask. It's not — Yeah, that's like the number one issue where you could just fill your contact window up like with a single query. But with the skills, you can tell it, hey, like put a limit 50 on any of those types of joins. So it doesn't completely take down your database and then have a timeout alongside that to say like queries are taking longer than two to three minutes. Try to rewrite them, kill it, rewrite it to make it a little bit more performant. — Those are the pieces of what I'm really excited about. the self-service aspect of not just sharing like this query and having someone modify it, actually teaching quad code, how to do a data analysis, have that to be something that folks can tap into along with data visualizations, common types of analysis like cohort analysis — um — and so on. So for that it's um even down to like sometimes I was trying to like export this CSV to go do something with it and it was kind of creating a bit of annoyance created a skill to export CSVs [snorts] and now I can kind of tap into that as you try to uh kind of move data around your system. — All right we got to do a separate episode on skills at some point. — Okay. Yeah, skills are super important. But let's take the last few minutes.

Let's talk about some of the data that you already p and that you shared public blog post about. Like there's some pretty interesting data based on Brexit spending patterns, right? — Yeah, absolutely. Yeah, we've been publishing these kind of data blogs for since I think for almost like six plus months and it's been really interesting to see from our customers what's winning. Right? You asked what's the best IDE or kind of coding tool. Well, the customers on our kind of platform have already picked it is definitely cursor. Cursor is absolutely kind of crushing it in like what um is the startup coding tool of choice but also enterprise coding tool of choice. And that mix of being able to like tap into both of those um sets of customers within Brax is pretty rare to see them kind of like succeed across both uh both startups and enterprise and kind of proving why they're on pace for their $30 billion funding round. So for me that stuff starting to show up pretty clearly and they've been number three for a few months now. It's also not like a temporary thing. — That that's awesome. Yeah. And there's some other really interesting stuff on here like well I guess the these aren't like um in a linear scale right probably like the you know it's probably yeah but but still it's interesting to see something like 11 labs on here relatively close to top I guess people are building like voice assistants or something — or — yeah they're kind of the voice assistant of choice like whenever there's any of this like kind of voice added to your platform especially within startups like I wouldn't think of it as much as like that startup is using it for their own internal use cases they're adding those tools to their apps, to their platform, to their products. That's where 11 Labs really kind of like spiked in terms of they're almost always the first choice for those voice um kind of assistant add-ons. Um so it's pretty clear to me that like they've been winning in that space — like customer support and stuff like that or Yeah. — Yeah. I mean we have to look at the element labs kind of like use cases but yeah definitely um succeeding in being that first choice and it's something we kind of saw as well in like the um bundle analysis here — where I can probably see the yeah for voice apps um you know there's obviously other kind of voice apps that are — popping deep speechify assembly AI — but definitely um the 11 labs has been kind of the most consistent uh in terms of choice and where the dollars are end ending up going. I also think like it's very interesting the top two like um — the fact that the fact that open AAI is more popular for enterprise than anthropic because anthropic really targeting companies right so — I was seeing that in the data where in 2024 it was opening across both startups and enterprise they were winning both but starting in 2025 we started seeing a lot of startups shift some of the ship some of their agentic kind of AI products in their apps And that's where in startups if you're doing that a lot of them were choosing claude as the model to put into their production apps. — Um you know that kind of like call it enterprisegrade type model which is you know a little bit kind of more reliable or whatever it is the reasons on cloud has been the choice for a lot of startups. So we see the agentic features within startups products are often times picking claude over open AI and that's where the startup spend on anthropic is going up versus within enterprise — it's a bit more of the like chatbt pro licenses or the enterprise licenses that are helping it boost its rankings here. Um, so we see a lot of spend going to anthropic within startups. Uh, and folks are starting to add Claude as well as like a subscription, but it's usually kind of the second subscription. — Yeah, — Open Eyes is still winning on the chat side. — Yeah, I guess you know enterprises way more than just all the tech companies, right? There's like, you know, Yeah, — there's like uh like all the accounting companies and all the international companies which OpenAI have much better brand a awareness, I'm sure. — Yeah, absolutely. Like if you're one of those companies, you're just signing up for OpenAI because what we see in our data is there was actually five employees already purchasing the pro subscription, you didn't have the team set up. There was, you know, maybe a little bit of security risk there. So you just onboard that entire tool and give it to all your employees because you got to mandate you got to be AI, you know, an AI oriented company. It's like, oh, let's just get in open AI. Um yeah versus startups that are building these new solutions they have a lot of opinions about which model why they want to use that model and uh we're seeing yeah anthropic win out a lot of those choices — but dude I think overall it's like a blood bath man like I think the top five are okay or I mean the top seven but like you know there's like thousands of AI companies man trying to go after these com these enterprises and startups. Yeah, seeing really interesting data like coming through where startups that were launched in 2024 June are really crushing it like absolutely like you know straight line logarithmic growth in terms of the adoption because they were able to build a component of the AI workflow. their agents do really well and so like startups are adding in that specific agent for that workflow um and as a result spending a lot on that and it's kind of interesting we'll kind of release something um probably in December overviewing kind of the industry overall in terms of AI and how those sometimes those specific use cases are helping companies uh gain traction in the space. Well, you should read his blog post on like because I'm sure you see like a lot of AI companies get a ton of traction and then they go down. Maybe when open I c h c h hobbies is fe feature or something. Yeah. — Yeah, it's true. It goes up and down, right? It's like um and that's where checking in on it every month which you do in the Rex benchmark. It's been really interesting. — Uh you know I think Replet's a really great story even though they kind of dropped this month. They weren't really even in this list the first time we created it, but they're kind of shipping new and newer agentic kind of capabilities and yeah have kind of started to kind of enter into the top 10 for startups and enterprise. So really impressive that team and what they're shipping. — Yeah, that is awesome man. And and you know the more agent ticket it is the more tokens it cost. So you know just — yeah more — and that ends [clears throat] up being spent on bre. So we're happy um yeah for that. Yeah, sure. — Okay. All right, man. Okay, that that was a good segue, but uh but let me wrap up with this. You know, people want to scale up on this stuff, right? And it just showed how you can build an MCP to start pulling queries and asking questions yourself like uh you know, if like a data scientist or like a PM wants to get started with this stuff like what are your top three steps, man? Like how can you get started becoming like Summit? Yeah. — Yeah. I think it is that idea that like even as you think about these BI tools that are all selling you this AI workflow, you still have to do the work to kind of pick those core queries, write the contacts, and even if you just end up plugging it into something like hack, which has been absolutely crushing it on their agentic analysis tools, you still need to have an opinion about like what are the queries going into that? what is the context I want to give um the idea about how to think about our data and how to write analysis and the common types of analysis. So it's super important for everyone to really start to add that to the scope of what a data team works on. Um you going to be able to one leverage it inside of cloud code for all of engineering which is great. Um but you're also then going to be able to plug it into these BI tools. So for me, getting those three queries, starting to write context about your specific domain that you care about is the perfect way to build out your data MCP, but also maybe you just throw that right into the BI tools and it starts working better too. Those AI tools within hacks like need that to actually get to the right answer as well. — Got it. So those three queries are more like are they more like questions you have on database or just capabilities that you want the AI to have is there's more capabilities right like that you want — yeah more capabilities like there's a bunch of value to it it's like even just understanding how you want to structure the query what those common joins are but also the components of analysis where you know you want to know what the top startup funding rounds are VCs are that are funding those startups how do you kind of bridge those two together. You don't even need to do that. You just need to give it the components and it can kind of fill in the gaps on how to like join this series of tables to this series tables to find the top VCs finding the top startups. It's exactly kind of what we saw in those examples. Um so having kind of basic use cases plus one larger analysis query — is enough to kind of start the agentic AI journey. — Okay. So the TRDR is like uh the context management is like super important like uh both giving AI the right context not overloading it window and also giving it like the right capabilities to look into your stuff right — yeah that's well said — cool man all right dude so where can people find you uh on LinkedIn or you know where can people find your stuff — you can follow me on Twitter at simma ma and then you know also check out the brakes blog we're publishing benchmarks every single month. So, working on a bunch of really cool things that I hope that you could get a check out. — Yeah, it's really good data, man. It's like way better than looking at all the AR numbers. It's good. It's actually data. — AR numbers, funding round data. It tells you a story, but we're seeing actual spend and that can kind of reveal what actually is being used in market versus the hype around some big number. Yeah. — Cool. All right. So, well, thanks so much, man. I learned so much. — Thanks, Peter. Yeah, I had a blast.