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-assing like it's not really a high quality product on the output

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

If our pipelines are 2% more accurate than our competitors it makes any bank that doesn't use us use our competitors instead negligent. I'm going to say something that you might disagree with. 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 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 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 TwoSetAI and today I'm sitting down with Alex Reichenbach. 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 Matician in South Bay, building robots and teaching them how to see the world. Most recently, I'm one of the founders of Structify. 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 them. So, you're able to chat with your data.

How old is Structify?

It's about two years old.

You guys raised around earlier this year, right?

Yeah. From Bain Capital and 8VC. It was just over a $4 million round.

Congratulations on the recent raise.

Thank you.

Yeah. Tell me 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. Generally, 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 transferable skill. I did it yeah computer vision work at the early days of Matician and then directly in the early days of Structify 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 LLaVA and like the Phi models out of Microsoft and fine-tuning those for enterprise client use cases so that was like the early days of Structify before we got a nice more platformized setup

Yeah did you run into any personal data problems or in you know space that's why

Yeah one of our earliest customers was a family friend who run a pretty like a small bank and they realized that they were basically unable to keep track of all of the deal flow through their pipelines because their data engineering was terrible and so they called me up and they said Alex I can't afford a real engineer would you help me out 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 when I went to 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 of the first things that we built for them was automatically tracking portfolio companies in which you go scan millions and millions of websites for all of these investment firms and it took me probably a month and a half to build the version of that and most recently I 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 very nice catharsis moment seeing it all come together

Was it in 2023

That sounds about right yeah originally

Right so that's when the hype just started right so you're one of the early adopters and trying to integrate AI workflow into something This problem still exists because I was just talking with another company and then they asked me a way to scrape portfolio companies like new startup. 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 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 want to 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 the data. Telling tell me more.

Yeah. We're generation platform. So it's going to go every time you give it a task it just needs to find a strategy to do it.

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 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 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, then 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 agentic and somewhat unreliable, if you get it to work once, then just stick it on a refresh loop and you're going to 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 want to clarify one thing when you're announcing you frame as data sets on demand which I introduce you. Can you explain what does that mean?

Yeah. 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 going to have hundreds of Snowflake tables. You're going to have some BigQuery 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 is 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 revops at some company could just go into their Slack say at Structify 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 will always have the data that you need at the time that you need it. There's sort of a 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 know also noticed that people have very nuanced requests sometimes and one dashboard have a thousand derivatives and that's how it just go 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. We are at one data scientist match 6 PM. It just doesn't work. It's just not fair.

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 like I was talking to a customer that 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 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 can do. And so for them it was utterly miserable and they ended up turning to us. It was just fully drop in replacement of stop asking your data team just come to us.

Yeah. Sadly I feel like I feel bad for the data scientist.

Yeah. I mean it's true a lot of dueling unfortunately.

Right. Tell me more about this. I'm curious because you know this year it's very hard to find jobs like for, I have interns, 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. And you are the Yeah, you'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 FDEs 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 any response that's sufficiently complicated goes to one of our FDEs. 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?

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 our AI 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. So, I think it's probably the fun part. It's just the strategizing.

I agree. I agree. I don't think we should frame it as like data scientists, you're out of job. It's just your roles are redefined. You're going to be more of the deeper thinking which is really good and which 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 because 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've been in data for so many years. I'm like, h yeah, someone got solved. So, what is the core problem you think you're solving?

Yeah, we're Structify. We're the AI data team. 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 want actually we actually need a help. We build a text to SQL engine in 2023 when the LLMs just came out and we're thinking using text to SQL can partially solve the problem. But there's more to it, right?

Yeah. Text to SQL. I feel bad for especially all of the NLP work, the natural language work that was done pre-2020. So much of it is just been replaced by LLMs of I if people are using n-grams for text prediction these days, it's not very good. Like at all the people that were doing like very heuristic based document prediction or document extraction. It's not as good as a visual language model.

I don't know if you remember the days of spaCy and NLTK.

Yeah, exactly. 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 tooling the tooling switch over time. We just continually get better at it.

Yeah, the data pipeline is really long. We have the ETL data engineer, we have annotation, we have analytics, modeling, ML, data ops, now ops, AI ops, whatever. So, it's a whole big pipeline. Where do you think Structify is fitting into this pipeline?

Yeah, my favorite place that we fit 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. Sell to the six PMs because they hate us, right? Because we have this queue of tickets and then Yeah. We working on stuff overnight. Yeah. Those people are actually the end user. So the PMs

I know 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 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. The head of data. Two sides either they are 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 at a 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 sense. So if they have buy into the org and the org's how well it's doing, then they'll like us a lot more.

Yeah. As the head of data, I need something that accelerates a team. However, the team can be very resistant of a new tool that potentially replaces. So there is a learning curve. Dbt, think of dbt query. You have to write your own queries, right? Even for text to SQL products, you have to prepare your data really nicely. You have to do the metadata to make it work, right? It's garbage in garbage out. So, it doesn't work. And then this data scientist 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 learn this new thing. Second, it does not work. It 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 Structify in the Slack and ask a 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 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 as sometimes happens I can ask which one you're interested in or I can just take my best guess.

And so I think that there is a funny thing around LLMs that it has actually lowered the effort 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 drop down list and stuff. I know what this is called. We can coin a new word like vibe data engineering.

Vibe data. 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 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 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 feels like that experience when you're using us 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 but hopefully with a higher degree of accuracy.

I recently talked with an 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 coding

Yeah it lets you move a lot faster until you reach yourself into a little bit of tech debt. I think that is something that I like about data engineering though as compared to general vibe coding because vibe coding in general. It is such a large surface area. You can work across an entire codebase and it's very hard to keep that all in context. Like part of the 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.

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 well at is Excel. Beyond that, no, we're good. So like put it in a 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 as well. PDFs as well. Yeah.

And you're using VLMs to extract the tables in the PDF. Okay.

Yep.

I used to like work with Wells Fargo and they're dealing with a lot of the compliance filings. Those documents like 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 regexing to wash the data but you know how it

One of the similarly there's an M&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 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'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 to the 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. They pull data from a 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 and this process so manual that I just hear my friend complaining about it. This is very error-prone. Can you guys

That seems like a future Structify customer right there. Where it needs to be. I mean what I see there is 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 aggregate of 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. 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 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. Because I got it from Cheryl. Okay, how did this whole thing happen with us? Like it starts with oh, there's a database pull. 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 untracked, 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 analyst just ask these questions directly or do the verification automatically 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. It pains me when I see teams still doing it manually.

So let's say if a customer like that and reach out to you and tell you that with this pain, can you help me? What happens next and how long does it turn around? The first pain point people tell me is I don't have time to learn something new. Even this is a pain. I'm just going to suffer through it every quarter, every month.

Yep. 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 2 compliant. We're going through our HIPAA now. So that's hopefully going to allow us to deal with more PII medical information as well because there's some medical sector interest. Beyond that, they talk with one of our strategists.

So one of our deployment strategists, these are the re-employed 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. 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 want to onboard entirely themselves, then my guess is you should show them how to 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 with you, right, to show you what the process look like.

I'm going to say something that you might disagree with. So I think it's easier to teach a in this modern day given tools like Structify, 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 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 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 without your team. My impression I don't know this if this is your observation. My observation I feel product managers does 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 always 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 of the thing that they have in their head is worse than what they think that they had. 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 don't know. 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 an 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 I'm out here in a pirate hat. I'm wearing as many hats as I can.

Okay, good. Now, you're the you're the pirate of my so the 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 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. I it's a weird it's a weird thing. So yeah the result of that is what you're exactly saying that just people end up wearing so many different hats.

Yeah. Yeah. Because if I want to build something I want to go faster. I'm just gonna go ahead and do it and then even hand it over to the sales team and then can you sell this for me and then they were sell it right and then I can come back to the engineer team now you have to build it you don't have excuse because they sold it

Yeah there was a very funny customer story that I got which somebody pitched the engineering team on something engineering team said it's going to 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 going to take less than 10 months cuz 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 anything. I'm sure that the engineering team might have been not happy 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?

Yep. Yep.

So, yeah. So, that's the trade-off. Let's talk about accuracy because this is a big thing. Multi-agent systems, they have compounding errors, right? Exponential 5% per step is 40% error rate for 10 steps. How do we solve that problem? Is your platform reliable?

So this is why I like there's people that have used Manus before and generally the transition from Manus to us is realizing have the reliability of code because our platform isn't just a pure multi-agent system that is going to queue an agent to Q&A and an agent to find you an answer. We are writing code that gets you an answer. It means that code is going to execute the same time every time. So if you're happy with it the first time, you're going to be happy with it again. Yes, code I mean everything is there can be errors everywhere. Not just if we 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. 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 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 data.

Exactly.

Or you guys.

Yeah. What we generally say these days is we do not guarantee for some pipelines, we do not guarantee 100% accuracy. We guarantee that we'll follow your plan 100% 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? 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, that have different 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 a 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. So just by that is the level of accuracy to measure how

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, 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 agents to be super accurate on that.

Ah okay. So it's not a model making the decision. It's not so 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 LLM that always will have a data ambiguity problem. It just depending on the function the query.

So for that for larger enterprises what we do is we have a metadata layer. There's something called DataHub which we integrate with which is a metadata on top of data sets. So every single column has description around what it does. It has information about its governance. So, is this GDPR compliant? Is this like CCPA to 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 involved upstream of that because 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 is two different levels of we have to be able to try our best to automatically fill it in because 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? Are you managing the context? Because 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.

This one thing I realized that when we're building production AI agents when we are letting the agent the LLMs to make decisions it's not very reliable. Yeah, understanding is okay. But yeah, I want to ask you if you're using powerful LLMs or VLMs, it's really expensive, right? Does your pricing work? How much?

Yeah. I mean generally we try to adapt for the use case. So for some things for code generation we use like Claude 4 at this time. I'm sure that'll change as models get better. Generally it is we are well over margin on the pricing but that's just because 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 the to the customer. So we make no money off of that and you're not going to 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. 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 because I think it really aligns price or incentives.

It means that you're not thinking that you're getting shortcut or 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 co-worker to have a good experience. So they want their co-worker to have a good experience because that's where all of our revenue is coming from.

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 n8n and there's not a single customer that uses n8n that most of them shouldn't be using us

Because you were saying that I shouldn't use you.

They're just they're different. They're different. Like you don't do large scale data engineering and processing or document processing and like web scraping. I'm not going to 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 n8n. I'm not going to do if you get an email you should send me a Slack in Structify which is very much like an n8n workflows if this then that stuff. The problem is a lot of just workflow builders look very similar to each other. So workflow builders are like the nodes with the edges connecting everything. They all look the same.

That's why I as a question. It looks like you look you do look like you're a workflow builder.

I know 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 just not going to prioritize right now. I'd say those are the two biggest things on how to differentiate for us.

Are you integrated with n8n?

We're code generation. So I've never seen anyone use n8n with us. If you took an n8n API key and you gave it to Structify, it would know how to use it.

So here's one use case I can imagine. I can use you guys to pull the data because you guys can be connected to Supabase and then can take it over from there and then they can do other stuff downstream.

Yeah, that's a positive. 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 the VC use case somebody applying for funding automatically sending it to us and then sorry n8n connects to a database which we pull from to get information about that portco 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 public information about them as a follow-up email. Might be a fun

Yeah. Yeah. So it's possible. So you could be serve as a data layer and then there's workflow layer. So that way the 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 Structify and a Slack channel. Get me this information and having it find this bit of information for us because that is people are used to adding an actual person in the Slack channel and instead we're able to do it and we do it instantaneously very quickly. So I think that's a better way to differentiate. Yeah. So I think that I could also bring that up and show that if you want as well, but I think it's much more Can I do it?

Yeah, why not?

I'll do a I'll do a quick one.

Screen auto share window.

Yeah. Yeah, those are Slack test channels. What I can just do here is like a can you grab every company that 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.

I love I really love 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 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. Yeah. I can think of how many tools I have to string up together to get enriched data and get everything ready and then to do outreach.

Sure. I can bring it up. I just realized I wanted to double check 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 going to hop over into the other view. But yeah, this is the query that we had. And if I have any other questions, it's going to respond in line Slack and I'm going to 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, 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 same database? Some companies that's yes. If that's not the case, then text SQL isn't going to 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

Oh, our vision for the company long term, right? 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. 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 voting time, the ballot time can be a good one. Everybody can do this.

Exactly.

How far do you think we are away from this vision like with the current state of AI? Do you think 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 intimidating. Some people are just they still think that they are less powerful than they are. They think that they've predefined their limits around how they can interact with data and we have basically broadened 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 Structify users is just their self-belief that they can do more than what they have been trained to do 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 too early, right?

Yeah. Oh, it's it's very early 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.

Overcoming that for them.

It's like the PMs cannot touch the engineer part of things. They cannot when they mess with the code now they can. Yeah, thank you Alex. Really 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.

I appreciate your time. Thank you.