He Left Robotics to Replace Your Data Team｜Alex Reichenbach @Structify AI

Your company has thousands of dashboards, but none of them answer the question that you need.

And every time they ask for a different thing, it takes the data team. I used to lead data team so I know the pain. We can coin a new word

vibe, data engineering,

and I think that people are used to vibing being just like.

Half asset, like it's not really a high quality product on the output.

5% per step is 40% error rate for 10 steps.

Mm-hmm. If our pipelines are 2% more accurate than our competitors, it makes any bank that doesn't use us, uh, use our competitors instead negligent. I'm gonna say something that you might disagree with

It's easier to teach someone who knows the business processes, how to data engineer than it is to teach a data engineer the business processes. It took me probably a month and a half to build the first version of that using our platform. it took less than like a couple of minutes,

The biggest thing that is preventing more people from, from becoming users is just their self-belief that they can do more than what they have been trained to do in the past. Data pipelines and your experimentation interact at the speed of [00:01:00] your thought, but, hopefully with a higher degree of accuracy, I want everyone to feel like they have the power of the Citadel data team behind them.

Hey everyone, welcome to Two Side ai, and today I'm sitting down with Alex Ricken Bark. today we're diving into data sets on demand. Alex, welcome. Welcome. I'm glad to be here. Yeah, thanks. Before we jump in, could you tell us a little bit about yourself and what you're building?

Yeah, of course. so my background is in computer vision research. I worked briefly at a Yale lab doing, single cell RNA research directly after that, I worked at a company called Magician, in South Bay. building robots and teaching them how to see the world. most recently, I'm, one of the founders of Stratify. we're the AI data team for every enterprise. This means that regardless of where your data sources are, we're able to connect to them and interact with 'em. So [00:02:00] you're able to chat with your data. How old is stratify? it's about two years old. you guys raised around, earlier this year, right? Yeah, from Bain Capital and eight vc. It was just over a $4 million round. Congratulations on the recent race. Thank you. Yeah, thank you. Tell me a little bit about your founding story. I remember you mentioned that you are a robotic engineer. How did you go from a robotic engineer to a founder solving data problems? I got sick of waiting for the hardware team. no. generally, my, my background was always in ML and ai and so I enjoyed, solving those types of problems. Those appear in so many different sectors that it's such a transferrable skill. I did it, yeah, computer vision work at the early days of petition. And then, directly in the early days of stratify, we did a lot of web scraping and document processing work. And so those were also vision models. And we used to use like the early vision language models, things like,lava and like the five, five models outta Microsoft and fine tuning those for, enterprise client use cases. So that was like [00:03:00] the early days of stratify, before we got a nice more, platform ties, uh, set up. Yeah. did you run into any personal, data problems or in mm-hmm. You know, space, that's why? Yeah. Yeah. one of our earliest customers was a family friend who, run a pretty, like a small bank. And they, they realized that they were basically unable to keep track of all of the deal flow through their pipelines because their data engineering, which is terrible. and so they called me up and they said, Alex, I can't afford a real engineer. Would you, help me out? And during the day I would work as a robotics engineer and at night I would help them with their problems. and so that was like the early days of what I went, wow. This is, The data tooling is very mature, but its ability to interact with AI products is incredibly, new. and so there weren't great ways to do that, and it became obvious how painful of a process it was when it should have been a very simple one. one of the first things that we built for them was automatically tracking, portfolio companies in which you go scan, millions and [00:04:00] millions of websites for all of these investment firms. and it took me probably a month and a half to build a first version of that. and most recently I've rebuilt it for somebody else and using our platform, it took less than like a couple of minutes, which was just a very, oh, this took so long. I remember how painful it was originally. So it was a very nice, catharsis moment, seeing it all, come together. Was it in 2023? it sounds about right. Yeah, originally. that's when the oms, the hype just started, right? Yeah. so you're one of the early adopters and trying to integrate AI workflow into something, right? this problem still exists 'cause I was just talking with another company and then they asked me, is there a way to script, portfolio companies, like new startups? I'm like, oh, you just told me you have a three minute solution. Introduce you guys. Send us to them. I'm excited to talk to him. Oh my goodness. yeah. there's a, if you ask it to, pull in, [00:05:00] Edgar does a lot of private market filings from the SEC. Ask it to pull all that data in and then enrich it with the website information of all of the filings. And it's going to pull in, it's gonna take probably, a little bit of time to run, but it'll pull in hundreds of thousands of companies and then enrich them with all the information on the web about them. So it's fun to see. That's so cool. And I wanna know that, if I were to do this let's say use, tools like Scraper API, I probably will give some direction. So I want you to scrape this specific website, which is filtered information. So you're saying you guys can go out and just scrape the SEC filings and so go directly to the data source To grab the data. Yeah. Yeah. It'll telling, tell me more. Yeah. Yeah. we're a generation platform, so it's gonna go, every time you give it a task, it just needs to find a strategy to do. so in this case, do I have to tell you the strategy or, it depends. So it will try to figure it out if you don't give it [00:06:00] one. I like giving it one because I find that part the fun part. It's like how do I get the information that I want and then after I have the strategy, it should go build it for me. So like in that case, the strategy was go pull in all of this filing information from the SEC and then look at the websites, in order to try to figure out who raised what. so I like just with that information, it's going to go read the docs for the SEC, figure out how to interface with that. It's going to write the code in order to pull in those documents, that it's going to pull those documents in, figure out how to interact with them, once it's able to interact with them, that it's going to, start enhancing with all the website information. And the end result is, you just get a fully code pipeline of, this is the, almost the ETL pipeline that is automatically created. So rather than having it be something like Manus, where it's always a gentle and somewhat unreliable, if you get it to work once, then just stick it on a refresh loop and you're gonna be able to get it to run in perpetuity. I love that. I feel like I need it too. I can think of so many use cases and I do have questions more about this, but I do [00:07:00] wanna clarify one thing. when you are announcing Shopify, you You framed it as dataset on demand, which I introduced you at. Yeah. can you explain what does that mean? yeah. it's just the feeling that, you can get whatever data you need to make the decisions you want. and so I like the, there's so many places that we interact with data, especially in larger enterprises these days. Like you're gonna have, hundreds of snowflake tables. You're gonna have some big query tables. Maybe we acquired a company last week and they have a bunch of files in a Dropbox. Exactly. so you just don't know where anything is. Then you also have, things online as well, or APIs that you connect to, data's all over the place and it becomes very, unwieldy to try to connect to these sources and use them. and so we try to make it so easy that, the head of rev ops at some company could just go into their slack, say at stratify, find me this information. and it will get returned to the slack in line almost immediately. it's, I think just the feeling that you'll always have the data that you need at the time that you need it. There's sort of a, a [00:08:00] saying that I liked, which was,your company has thousands of dashboards, but none of them answer the question that you need. Which is very much the feeling of, you always are overwhelmed with all of the toolings, but none of them Actually get you the answer you want. Exactly. I also noticed that people have very nuanced requests sometimes and one dashboard have a thousand derivatives, and that's how it just goes bigger. I used to lead data team, so I know the pain. every time my business partners ask for a different thing, it takes the data team. Yeah. we are at one data scientist match, 6:00 PM it just doesn't work. it's just not fair. Not fair. And that's if you even have a data team, because there's, you were lucky enough that your data team was internal. There's some organizations, especially in legacy industries that use external, like BPOs or business process outsourcing. For their data engineering work. And it just becomes, I was talking to a customer that, they, they just bought another company and they used all of their data engineering credits. So they're allocated by hours, basically all their credits to imbibe that [00:09:00] data from another company. And they're just like, we can't do any data engineering work this quarter. we've just run out of credits and there's nothing else we could do. so for them it was utterly miserable and they ended up turning to us. it was just fully a drop in replacement of Stop asking your data team just come to us. Yeah. Sadly, I feel like I feel bad for the data science team. Yeah. Lot of unfortunately. Right. tell me more about this. I'm curious because,you know,this year is very hard to find jobs like for mm-hmm. I have, I intern, I have people who used to be MLEs data scientists. And, they're looking for transmissions or they got laid off. All kinds of situations, but they all tell me it's very hard to find jobs this year. Yeah. And you are the yeah. we're part of the problem. I would say if they're, if we're good data scientists, send them our way, we do, for some enterprises do FTEs, which means that, we act more as an AI upskilled BPO for them, such that we're able to have most of our responses triaged by ai. and then [00:10:00] any response that's sufficiently complicated goes to one of our FTEs. So we do end up hiring data scientists. so if they're incredibly good and they're looking for a job, send them our way. what do they do these days? sometimes it's usually just like the, it's literally the strategy thinking it is. some CRO or COO has some data set that they want and they don't know how to get there. And RA, I doesn't immediately think of a good strategy to do so either because it doesn't know of the APIs that exist, doesn't know Enough about the business problem. and so their operator talks to our FDE and basically comes up with a strategy on how best to get this information. and then the FDE on our half just knows very well how to interact with our product, and then they're able to translate that strategy into something that, gets the data set that the client wants. Okay. I think it's probably the fun part, which is just the strategizing. I agree. I agree. I don't think we should frame it as like data scientists. You're outta the job. It's just your roles are redefined. You're gonna be more of the deeper thinking, [00:11:00] which is really good, and which Yeah. I think is missing for many years. I always ask, what's the conclusion? Where's the conclusion? The other side of that is, people, I've seen people act as data scientists who. Don't have a data science career, like they've never done it before. They know some of the language 'cause that they've operated in, the spreadsheet finance world before, or they've operated in like a sort of the academic world, but they've never directly done data science and they're just truly delighted with having the power to do it themselves. Whereas previously they need to go try to learn or just not do it. Yeah. I know how that feels. It's a long story. I feel, I've been in data for so many years. I'm like, ugh. Yeah, someone gotta solve. So What is the core problem you think you're solving? Yeah. we're stratified, we're the AI data team. if we make it easy for anyone in the org to access the data they need when they need it. Yeah, I see my team being replaced. I actually, we actually need The help. We built a text to SQL engine in 29 [00:12:00] 3 when the LMS just came out and we were thinking Text to SQL can partially solve the problem. But there's more to it, right? Yeah. Texas sql, I feel bad for especially all of the NLP work, the natural language work that was done pre 2020, so much of it has just been replaced by LMS of I, if people are using ngrams for text prediction these days, it's not very good. Like at all the people that we're doing like very heuristic based document prediction or document extraction, it's. Nice. Not as good as a visual language model. I don't know if you remember the days of the species and NL TKs? yeah, exactly. but it happened before, like with, histogram of oriented gradients used to be used for image classification before CNNs came around. And so it's just always the toolings, the tooling switch over time. We just continually get better at it. Yeah. the data pipeline's really long as, we have the ETL data engineer, we have annotation, we have analytics, modeling, ml, data ops, now, AI ops, AI ops, [00:13:00] whatever. So it's a whole big pipeline. Where do you think, s stratify is fitting into This pipeline? Yeah. my favorite place that we put into is, legacy industries that are attempting to scale and have realized that, They actually need a data team where they didn't have one before. I think that trying to sell into companies that have existing data teams is just not a good sales process for us because usually,they're happy with their data team.ask me, it's so hard to sell to data team. They're the wrong people to sell to. Yeah. Yeah. sell to the six PMs. 'cause they hate us, right? Because we have this one queue of tickets and then yeah. we can't deliver, we're working on stuff overnight yeah. , Those people are actually the end user. So the PMs, I know we, we've targeted, at one point we tried to sell to heads of data and I realized that was a terrible sales process for us. not to me. Yeah. So now we, it depends. It actually really fundamentally depends on the head of data [00:14:00] because. the COO sees the pain point. They need their data, and the data team is usually backlogged because they have so many requests coming in. Sure. Yeah. the head of data, two sides, either they're seeing that they want to eventually become a larger role. and like they're just thinking about how do they get to the next step. And they see us as a block to that and they don't like that. but the other side is, I've talked to heads of data that have like equity in the company, for instance. They care about how the company does. and for them, all they're saying is like one of the heads of data that decently large bank was just like, I have hundreds and hundreds of dashboards that I manage. I'm thousands of tickets behind. I have ownership of this company and I know I'm costing this company the bottom line. I would like if you can help us not be critically behind. I would love that in a second. So if they have buy-in to the org and the orgs how well it's doing, then they'll like us a lot more. Yeah, as the head of data, I need something that accelerates the team. However, the team can be very resistant of a new tool that potentially [00:15:00] replaces. Yeah. So there is a learning curve. Dbt. Think of DBT query. You have to write your own queries, right? Even for text to, products, you have to prepare your data really nicely. You have to do the method to make it work, right? It's garbage in, garbage out, so it doesn't work. And then did this data scientists will come to me and, they will complain. This tool doesn't work. They just come to next week the first objection. I don't have time to test this thing. I don't have time to this new thing. Second, it does not work, Yep. And do you face that too? Or you have a shorter learning curve? Yeah, we have the LLMs make it such that you have a much shorter learning curve. because we can do a lot of the translation. So like early customers to us, they generally interacted with just the slack, so they go at startify and the Slack in asking natural language question. whatever, if they asked in a foreign language works well too. I haven't tested that as well, but like regardless it is a thing that we all speak. We have some language [00:16:00] that we can use, and if it has questions, it asks follow ups in those same languages. So if I have three different user tables among, three different sources, it sometimes happens. I can ask which one you're interested in, right? Or I can just take my best guess. And so I think that there is a funny thing around LMS that it has actually lowered the efforts to adoption, of some of these tools. this actually came up like I was using linear the other day, and Linear has a Slack integration similarly. and I still don't really know how the graphic interface for linear works. I just do all of my interactions through the Slack and it means that I don't have to have as much of a learning curve. Yeah. Nobody wants to use those dropdown lists anymore, right? The buttons and the dropdown list and stuff. Yeah,I know what this is called. we can coin a new word like, Vibe. Data Engineering. Vibe. data team. I, there's a certain amount of that's true. I think that we dislike trying to fit into the vibe toolings because we put a lot of effort into our accuracy [00:17:00] and I think that people are used to, vibing being just like. Half-assing, like it's not really a high quality product on the output. Yeah, it does. Starting to have this kind of connotation of lower quality. Yeah. Even though we all use this a little bit. It's very much true. it might just be straight a marketing thing. I think it, it feels like that experience when you're using this, like you're just, your data pipelines and your experimentation interact at the speed of your thought. which is a very fun feeling to have. I agree. but hopefully with a higher degree of accuracy. I recently talked with the investor and then I told her that, okay, I'm building all these things. It's pretty fast. building all the, pipeline or whatever I'm building, And the first sentence she said back to me. Is it all vibe coating? Yeah. It, Betsy, you move a lot faster until you, you reach yourself into a little bit of tech debt. Yeah. I think that is something that I like about, data engineering though, as compared to general vibe coating because vibe coating in general, it is such a large surface area, [00:18:00] you can work across an entire code base. and it's very hard to put that all in context. Like part of the stratified platform is you iterate on these little blocks, much more like a conventional ETL diagram. and it's because they're separable with very defined interfaces between them. So if I'm trying to debug the first set, I can just iterate on that over and over again, and keep the entire part in context that matters. so you're like any end like dragon and drop you so I can create those. no. We. I'm happy to bring up an example if you wanna see it. yeah, can you walk me through an example? Yeah, sure. I'm gonna bring up talking about speed of thought earlier. Okay. There's a pipeline that, let me see if I can track down where it went. there's a pipeline I made earlier today, which was just, can you connect to all of the bills that the House and the Senate has done? take out all their sponsors and co-sponsors and figure out which senator has the least productive record, in the house. I was like, curious what that was. And I ended up, working almost immediately. [00:19:00] I actually worked after two prompts. wow. Where did I put it? this is something I feel like we're enabled, our curiosity is now enabled. If you Wanna do something like this, now it's possible before I have to, yeah. Where do I get this data? such a pain. Quit. Yeah, I would've never done it. It just would've not been worth the time. So workflow toolings, a lot of them look the same. we are code back. So all of this is, tour complete nice code. in this case I'll show you literally the prompt that I used. I was just thinking out loud. I wasn't thinking I was presenting this, so I said, just can you pull in every bill for the last year, grab all the sponsors and co-sponsors and make a graphic about the least productive senators and house members for this year. and just, I was like, thinking about those things, it grabbed the sample data 'cause it thought that was gonna take too long. and then I, worked after that, I think. yeah. Okay. And then, yeah. Yeah. So then I got 250,000. Where is it? ah. [00:20:00] There it is, 225,000 rows from different sponsors to different bills in Congress for, the 118th Congress, which is the most recent, directly from congress.gov from their API, which I didn't really know existed, but I wanted to figure this out and connected that data, grabs all their sponsors, aggregates the data into all the senators and the house representatives, and then makes, nice graphics about this. So in this case, like the least productive, Senator. we have Adam Schiff here for this year. I think he came in halfway through, which doesn't, not the, the nicest comparison. And then here we have, Marco Rubio as sponsoring or co-sponsoring 778 bills, which is an absolutely incredible number of bills. But the premise is I just, I spend maybe two minutes thinking about this. I processed multiple hundreds of thousands of bills and just answered a research question that I would've not had otherwise. And this is a silly example in the 'cause this doesn't directly apply to, stratify. [00:21:00] but when you're working with your customer data, your payments, data, all that, it just becomes so easy to pull it all in and get the information you want out of it. This is useful. You reminded me. This is a voting time. I know. Alright. one of the things I also wanna do is regarding the coding time coming up is I want to do, do you know what Omnibus Bill is? It's like the spending bill for Congress. I want to pull in all of the spending and figure out where it all goes and make nice graphics around that. but I don't think the one for the series app yet, and then you can tweet about it. It'll be interesting. Yeah, a lot of our, our go-to market strategy is around these public links, so we have just started posting a lot more of them, which is just, little bits of research that we've done in different subsets showing how easy it is to do, interesting research queries using us, And then getting people to click on those and convert. if I'm a user, do I have to, do I need to prepare my data in any ways? the one thing that we don't particularly do a lot is Excel. Beyond that. No, we're good. So I put it in a [00:22:00] CSV, put it in. Anything you want, really, if you uploaded a text document, it would probably figure it out. yeah, we're very good at interacting with incredibly unstructured sources. So like you put it into a zip file and upload it, we will unzip it and figure out what's inside, PDF as well, PDFs as well. Yeah. And you're using VMs to extract the tables in the pdf. Okay. Yep. Yeah. Yep. I used to like work, with, Wells Fargo and they're dealing with a lot of the compliance filings, those documents, like a thousand pages long and with tons of data and very difficult to extract at the time what we were doing. Yeah, we were definitely using a lot of NLP approaches that just, we did a lot of re rejects to wash the data, but you know how it goes. it's okay Yeah. one of the, similarly, there's an m and a customer who, their goal is to separate whether documents are relevant or not relevant to a case. and they were previously just doing it manually. that's how you do it. That's how they've historically done it. They [00:23:00] were testing around just doing OCR and seeing what happens. And I came through and I went, this is a terrible approach to this problem. You should be using us. and now they, they're starting to scale it up and it's just incredible to see the joy in their eyes when they're like, oh, I used to spend days and days of manual separation here and annotation on these documents, and now it's just all automatic. Yeah. Yeah. I also talked

with a finance team they also have a lot of pain points. Maybe you can help, as well. they do everything in Excels and building hundreds of tables. Mm-hmm. they pull data from system and the system have update or refreshing problems that could cause downstream, consequences.And then those numbers have to match, And that has to lead to some sort of board deck. you don't want the data to be wrong. Yeah. And this process, so manual that I just hear, my friend complaining about it, this is very error prone Can you guys solve that seems like a future stratified customer right there. It needs to be,Um, I mean. [00:24:00] When I see there's a couple of problems. So the first one is they need to be able to integrate with wherever this data is being pulled from. there's some refresh loop issue on that data source. They need to be able to transform it through several steps, and then they need to be able to create a, some aggregative metrics or visualizations, which can be put into a board deck document that accurate representation. Right. the nuances. finance people always tells me that there are more nuances to it because people asking for small tweaks here and there, so it's not a template that just repeats itself all the time. Maybe it repeats itself 80%, but then there's 20% what if the human does some small tweaks and then you forget to change some formula and then you have downstream data don't match. yeah. Yeah. I think what tends to happen in the finance teams is you're ending up passing around in Excel and doing your minor tweaks, and then that gets passed around and you have an unforeseen lineage of where did this come from? what I like to try to get finance teams to do is keep the entire pipeline. So [00:25:00] instead of just like exporting from a database, tweaking my little Excel formula, sending it to someone else, they tweak their thing passes on and on. I like keeping the full pipeline so that, if you're wondering how this thing was calculated, because if I have an Excel file, I'm like, oh, Dave sent me this. Who got it from Cheryl? Okay. How did this whole thing happen? with us? Like it starts with, oh, there's a database, Paul. So that's where the original source comes from. This is every single transformation. And so rather than having, aggregated, modifications over time that are on tracked track, every single step is tracked. So you can see where your data came from source to finish, regardless of when you see the pipeline. Can you ask questions if your platform can just let the financial analysts ask these questions directly. or do the verification automatically. this is like low hanging fruit and shouldn't like, use so much of the human time To work on. Yeah. I'm with you on it. I agree. I, it pain to me, when I see teams still doing it manually, I, so let's say if a customer like that and reach out to you and tell you that I'm crying with this pain, can you [00:26:00] help me? what happens next and how long Is the turnaround? the first pain point people tell me is, I don't have time to learn something new. Yeah. Even this is a pain, I'm just gonna suffer through it every quarter, every month. Yeah. Yeah. the thing that we do is, generally if someone came to us and started doing that and they're in the financial sector, we would probably go through compliance as a first step. That's what always happens first, which is just a security questionnaire. Making sure that everyone knows that like we're soc two compliant. You went through our HIPAA now, so that's hopefully going to allow us to deal with more PII medical information as well. 'cause there's some medical sector interest. beyond that, they talk with one of our strategists. so one of our deployment strategists. These are the,reemployed data scientists, which are learning to strategize with these people. and then for a quick pilot we'll figure out how to turn them around. Something to show that we can solve the pain point without them having to learn it. so that's generally what we'll do for, if they have like more than 40 people, that's the better process for them. if they wanna onboard entirely themselves, then my guess is we should show them how to [00:27:00] set up the Slack connector. and then they should just interact with us in natural language. if you guys were to do a pilot, they still have to sit with you, right? to show you what the process looked like. it depends. SoI'm gonna say something that you might disagree with Okay. So it's, I think it's easier to teach a, in this modern day, given tools like stratify, it's easier to teach someone who knows the business processes, how to data engineer than it is to teach a data engineer the business processes. and so the business person who knows the processes well, when they interact with our tool, they're able to set up their own data pipelines. And then I like that more when that happens because we don't need, it takes so much time for us to understand the intricacies of someone's business. Like it is so complex as to why, they care about this deal more than that deal, even though it's the same amount. And there's just so many different levels of why this column is important and this column is not. And they're both named basically the same thing. and it becomes. It happens because these businesses grow over time and there's not as much, central planning. And so it's,[00:28:00] it's just what happens in any large organization. and since our agents are able to navigate this data, it means that these business people can make their pipelines reflecting of the business logic without needing to explain it to us as much. so that's always a nice, it was a nice feature that I wasn't expecting to come out of it. I was, but as we get better, it's just what ends up happening. Do you know how I feel about this? I always think this is product managers building products by themselves. Your team. my impression, I don't know this, if this is your observation, my observation, I feel product managers, they have an idea, they have a vision and they send their blueprint to the engineer team and engineer team will give you something, a product that's 20% off. So they all wait. Yeah. Be because lack of domain knowledge. Yeah. it's tough to know. I also think that, it is, I don't know if there is a thing that will make the PMs happy. Like I think that they have a thing in their head and any instantiation into reality [00:29:00] of the thing that they have in their head is worse than what they think that they had. true. And so this, I don't know how much of it is the miscommunication to the engineers versus just,the, from going to thought land to reality is a tough journey. I dunno. But either way, it's now the PM's responsibility, if there's an issue with it, they can iterate with it. that's a good one. That's a good one. I'm not a pm I'm not engineer, I'm the data scientist, so I'm like in the middle. but I do both things. now people, I feel like we all have to wear more hats now. I have to be the PM for what I'm building and be the engineer. so yeah. So it's, it, I think it's, I'm not here to pirate hat. I'm wearing as many hats as I can. Okay. now you are the, you are the pirate. My podcast. So another new hat. I think that is true. There's a weird feature of AI that it is shortening previous job cycles. So like what you were working on takes less time and so you have more time to do [00:30:00] other things. But the roles that we have pre-established, no longer fit how long it takes to do a thing. And so you find yourself just doing related jobs? Yes. I, it's a weird, it's a weird thing. Yeah. Yeah. Result of that is what you're exactly saying that just people end up wearing so many different hats. Yeah. Yeah, because if I wanna build something, I wanna go faster. I'm just gonna go ahead and do it and then even send it over to the sales team and then can you sell this for me? And then they were able to sell it, right? And then I can come back to the engineer team. Now you have to build it. You don't have excuse 'cause we sold it. Yeah. There was a very funny, customer story that I got, which somebody, I pitched the engineering team on something and Jerry Tang said, it's gonna take 10 months to build that. He then went and built it on the platform and then said this isn't integrated into our product, but I know it's gonna take less than 10 months 'cause it works here. how do we actually get a reasonable, time estimate? and it made that guy delighted because previously he has zero recourse to ever. say [00:31:00] anything. I'm sure that the engineering team might've been unhappy with us, but, hopefully they'll forgive us if we make them a nice API and they can use it, directly. maybe you are able to actually reduce the time from 10 months to much less. Right? Yeah. Yeah. so yeah. So that's the trade off. let's talk about accuracy. 'cause this is a big thing. multi-agent systems, they have compounding errors, right? Exponential. Mm-hmm. 5% per step is 40%. error rate for 10 steps. How do we solve that problem? Is your platform reliable? Yeah. so this is why I like, there's people that have used Manus before and generally, yeah. The transition from Manus to us is realizing, had the reliability of code. because our platform isn't just a pure multi-agent system that is going to q and A to q and a, and to find you an answer. we are writing code that gets you an answer. It means that code is gonna execute the same time every time. So if you're happy with it the first time, you're gonna be happy with it again. yes, code, I mean, everything is, there can be errors everywhere, not just if we [00:32:00] build it, but if your data team builds it or if an external organization builds it for you. it's tough to say that just sometimes data pipelines are not as accurate as you want them to be, but it will always be true. that being said, it is something that we put a lot of work into if we put a lot of work into functional tests to test every single query, making sure we get accurate results back, against hundreds and hundreds of queries every single night. and really it is a pride point to us on how accurate we've been so far and how we push that to be better. and then actually on the business side, it becomes, a very big thing for us because. Text to sql, for instance, is now sufficiently easy to do that. It has basically become a commoditized thing. doing large scale data pipelines is a next step that we need to make sure doesn't become commoditized. and the way that we do that is by fighting on accuracy. if our pipelines are 2% more accurate than our competitors, it makes any bank that doesn't use us, use our competitors instead negligent. we need to make it worth spending [00:33:00] five times more by being more accurate than anyone else that they can buy from. so I really like competing on accuracy as a business prop because it means that we can have, outsized returns and justify a higher price. but it is, it's hard. It is definitely hard to make things incredibly accurate. We have put a lot of work into it and we will continue investing in it. but yeah, no. Pipeline is perfect. I'm sure it's just a matter of who can I blame? My dataset? Yeah, exactly. For you guys. what we generally say these days is we do not guarantee a, for some pipelines, we do not guarantee a hundred percent accuracy. We guarantee that we'll follow your plan a hundred percent of the time. a customer that gave us roughly a million rows of company data and they said, there are duplicates here. Can you deduplicate? And we're like, yes, we can do that. But there's complete ambiguities in that process. We are going to make our best judgment calls if you don't give us a description of how you want us to do it. But if I have two companies on the same block with the same name that are different companies, right? have different [00:34:00] legal names, should they be merged? Should they not be merged? So accuracy is an easy thing to chase, but a lack of specificity makes accuracy impossible. Yeah. Yeah. How do you deal with this? there are two problems that you mentioned. One is Data ambiguity problem, right? most companies don't have a data dictionary properly structured or even have one. The second one is, you mentioned,you can guarantee 100% carry out of a plan. Mm-hmm. So just by that is a level of accuracy to measure. How do you do? Yeah. that's the benefit. it's being backed by code. We are like, as soon as the thing is running in its final stage, I have made an ETL pipeline. This thing is a highly optimized polars graph. It is a polars is like a similar thing to Apache Spark. So we've basically made a giant Apache Spark pipeline, which is going to run the same way every time because it's deterministic code. So it's not. It's because of the way we designed the system that happens, rather than saying we're training [00:35:00] agents to be super accurate on that. Ah, okay. So it's not a model making the decision. It's not So you're Yeah. At that point, so you're separating the two, the code gen is deterministic, carry out the plan, and then the design part is actually the interpretation part, which involves the om that,that always will have a data ambiguity problem, right? yes. It just depending on the question, the query. So for that, for larger enterprises, what we do is we have a metadata layer. There's something called data hub, which we integrate with, which is a metadata on top of, data sets. So every single column has a description around what it does, it has information about its governance. So is this GDPR compliant? Is this like cz PA, the California, compliant? Is it PII? how do we want to classify it? So if you're a large org over multiple countries, it makes a big difference. And then our agents are able to automatically detect changes there and update. So if a data vendor that I'm buying from has changed their data dictionary, we notice that and attempt to update the annotations, also send notifications to all of the people that are [00:36:00] involved upstream of that 'cause we're able to track the data lineage through that. and so we do our best to use agents to automatically update the semantic layer on top of a large data set. that being said, we also notify all the people involved. So if there is something that is incorrect, they have the ability to step in and say, oh no address one, two, and three mean different things because of this reason. so like there, there is two different levels of we have to be able to, try our best to automatically fill it in 'cause people are lazy, but we have to allow them to get some sort of recourse because AI is not perfect. Yeah. does this have anything to do with context engineering or are you managing the context because yeah. Yeah. the, when I have 80 tables with thousands of columns, I need to decide which ones are going into my data frame. Like how am I communicating this to the agent? so we do a lot of context engineering, a lot of orchestration around, automatically trying to determine which columns are going to be useful to this agent and answering this query. the one thing I realized that when we're building [00:37:00] production, AI agents, when we are letting the agent, the LMS make decisions, it's not very reliable. Yeah. understanding is okay, but yeah. I wanna ask you if you're using powerful LMS or VMs, it's really expensive, right? does your pricing work? how much? Yeah. Yeah. Um, I mean, generally we try to adapt for the use case. So for some things, for code generation, we use like cloud four at this time. I'm sure that'll change. The models get better. generally it is, we are well over margin on the pricing. but that's just because of the way that we charge per seats. So like the, when we do large scrape jobs, for instance, web scraping jobs or document processing jobs, those are passed on at the same cost that we're being charged in a large scale deal to get to the customer. so we make no money off of that and you're not gonna find a better deal elsewhere because we're negotiating as a business to get the best rates possible for you on that. and then all of our margin just comes from per seat pricing. [00:38:00] So we pass our costs on directly and then we just want to expand as much as possible to getting more people to use us. and I orchestrated that way 'cause I think it really aligns price or incentives. it means that you're not thinking that you are getting, shortcut or, for, for having, using LLM calls. But we're able to be incentivized to try to make you have a good experience so that you want a coworker to have a good experience. So they want their coworker to have a good experience. 'cause that's where all of our revenue is coming from. Um, there are data tools everywhere. You are also in a very competitive space. What do you think is the hardest part about standing out? I would say the hardest part about standing out is that, workflow toolings look the same a lot of the time. So there is not a single customer that uses us for their use case that should use NAN And there's not a single customer that uses NANN that, most of 'em shouldn't be using us. because use NAN you're saying that I shouldn't use you? they're just, they're different. They're different. Like you don't do [00:39:00] large scale data engineering and processing or document processing and like web scraping. I'm not gonna connect to my snowflake and pull in thousands of rows or hundreds of thousands, millions of rows of data and then, tag them all in at eight n and but I'm not gonna do, if you get an email, you should send me a Slack and stratify, which is very much like an na done workflows if this, then that stuff. the problem is a lot of just workflow builders look very similar to each other. And so workflow builders are like the nodes with the edges connecting everything. They all look the same. so that's why I asked a question. It looks like you look, you do look like you're at Workflow Builder. I know it. It's very, so I think that, when a tool is capable of doing so much,It becomes more important and also much harder to say, this is a use case we're not going to do. and so differentiating from conventional workflow builders and, throwing use cases out that you theoretically could do but are not gonna prioritize right now. I'd say those are the two biggest things on how to differentiate for us. Are you [00:40:00] integrated with NAN? we're code generation, so I've never seen anyone use NAN with us. if you took an N-A-N-A-P-I key and you gave it to stratify, it would know how to use it. so here's one. In case I can imagine I can use you guys to pull the data, 'cause you guys can be connected to superb base And then can take it over from there. and then they can do other stuff downstream. Yeah. That's a poss I think that would be a pretty fun use case to, for instance,every time I get an email from, a Portco or somebody, in, in the VC use case, somebody applying for funding, automatically sending it to us. And then so N End connects to a database, which we pull from to get information about that Port Co online and then send it in a follow up email back in that thread. So you get like information, you get their pitch, and then you also get all the publicly information about them as a follow up email. That'd be a fun. Yeah. Yeah. So it's possible. So you could serve as a data layer, and then there's workflow layer. So That way you're [00:41:00] not a workflow tool, right? do you have to, do you feel, you have to explain why you're different to your customers? I think that we have good practice at explaining it, and so we don't, I like the best way to explain it is to not run into it. So I try to not run into it. I do this by, I don't tend to show the workflow builder as a first step. What I'll show is, the slack layer of I'll show the at startify in a Slack channel, get me this information and having it find this bit of information for us. 'cause that is, people are used to adding an actual person in the Slack channel. and instead we're able to do it, we do it instantaneously,Or, very quickly. So I think that's a better way to, to differentiate, Yeah, so I, I think that, I can also bring that up and show that if you want as well, but I think it's much more You want me do it? Yeah, why not? I'll do a, I'll do a quick one. Screen how Share window. Yeah. So there's our Slack test channel. what I can just do here is like a, let's see, can you grab every company that [00:42:00] has signed up? Oops. Spelling is difficult. in the last. 24 hours from our DB, figure out if we've talked to them via the meeting notes in HubSpot and, if not, enrich their information online and respond in thread. oh, I love it. I really love it. This is a great CRM tool. Exactly. And we immediately get the response here. If I click on here, then it's going to start grabbing that information. but I think that this sort of just makes it like you don't get distracted by it, that it's a workflow tool then, because if I lead with that value prop, you don't see, like you don't see the workflow tool, you don't get distracted. You really just see the value of holy mackerel, how long would it have taken me to do this if I needed to do it manually? Yeah, that it's a lot easier that way. Yeah,I can think of how many tools I have to string up together to, to get enrich data and [00:43:00] get everything ready and then to do outreach, yeah, actually I can bring it up too. I just realized I wanted to double check and make sure that it was all, all working well, but this is, yeah, so this is it now. I went and it's writing a bunch of code to automatically try to interact with all of our databases, figuring out how to get that information and then, went and looked at the HubSpot docs in order to figure this out. once it's able to do all of that, it's now writing code. Once it's done writing code, it's gonna hop over into the other view. but yeah, this is the query that we had. if I have any other questions, it's going to respond in line Slack and I'm gonna be able to follow up there. So you don't have to type here, you can just interact within Slack, right? Yeah, exactly. Well, do people ask you the question, like, how are you different from a text to SQL company? yeah. it's, we tend to get this from people that are, that have know what text to SQL is, which a lot of our customers don't, but generally it means we're able to query across so many different sources. So is all of your information in a database, is it all in the [00:44:00] same database? some companies that's, yes. If that's not the case, then Texas SQL isn't gonna work for you. yeah. but we're able to query across multiple data sources, multiple APIs. We're able to query across documents, web, like wherever your data lives, we will track it down and we will get it for you. so it's very different than just, write a SQL query for me on this single database and get me back a table. Yeah, that makes sense. your vision. Mm-hmm. Oh, our vision for the company long term. I want everyone to feel like they have the power of the Citadel data team behind them. like everyone from, small mom and pop stores that just have a single HubSpot to, people like some of the larger banks, the individual PMs. it's just a better thing for the world if we're able to make decisions based off of data rather than based off of guesswork and hopes. And so I would like people to be able to make more informed decisions and I would like to play whatever part of that we can. Yeah. maybe the November [00:45:00] voting time, the ballot time can be a good one everybody can use. Exactly. Yeah. How far do you think we are away from this vision? Like with the current state of ai? Yeah. Do you think so? Be improved? I think that a lot of people are more scared of it than they should be. as in. There are people that it could help, but the idea of interacting with AI or the idea of interacting with data is too scary for them to even start, even though they're only using it through text, they're using it through, a way that shouldn't be as, as intimidating. some people are just, they still think that they're less powerful than they are. they think that they've predefined their limits around how they can interact with data. And we have basically brought in their horizon. We have a tool in the toolkit that has allowed them to do so much more, and it's about them embracing that they can do so much more. And that's like the biggest mental switch for us. The biggest thing that is preventing more people from becoming stratified users, is just their self-belief that they can do more than what they have been trained to do [00:46:00] in the past. sounds like it's just a matter of we go through this adoption curve, so once we pass early adopters It's just like a course that we all have to go through. Exactly. Early adopters are the most eager, and then everyone else, sees those early adopters and eventually converts. and right now you think it's still early, right? Yeah. Oh, I'd say it's very early in, in people. There's so many people that I think we could be useful to that are just too scared of seeing a data set. and as soon as they realize that the data sets aren't that scary, because historically they've been boxed out. Anytime a PM or an operations person tried to ask for data, they have to go talk to the data team. And the data team has a bajillion things to do and is stressed and they're getting a bit shoved off. And so they've just been historically conditioned to be shoved away from the data. exactly. And so it's also overcoming that for them. Yeah. it's like the PMs cannot touch the engineer part of things. They cannot, mess with the code. Now they can. Yeah. Thank you Alex. Really [00:47:00] nice chatting today. Yeah. Thank you so much for your time and I feel like I learned a lot about your tool and your design philosophy, and thank you for sharing all the trends and how you convince your customers and your demos. Yeah, yeah, yeah. I appreciate your time. Thank you.