Invest with AI
00:24:48 · Thomas Li
[00:24:48] S0: Yeah, so the moat ironically itself is high quality, right? Because being able to collect data and being able to collect data at like a 99.9% accuracy are wholly different problems. I'm going to use the car factory example. So when you build a car, and Toyota is famous for like six sigma, right? When they build a car, the car has the same quality as every other car down to, you know, six decimal points of nine. That is really, really hard to do. And even if someone else has access to all the engineers to build the factory, like you cannot replicate the quality of the Toyota factory. Now why is that? It's because it's never about just a tool. Giving someone a really good hammer doesn't make him a good carpenter. It's everything else. It's how do you set up your process? How do you set up your controls? How do you set up internal SLAs? Down to how is your company culture? How do you incentivize and reward people? How do you hire? Right? Every single thing that we care about has an angle towards accuracy. Within ZALUPA, we even talk about what are the personality traits that lend to higher quality output versus what are the personality traits that lend to faster output, and are they the same personality traits? So we care about like microscopic little decision making. We care about how we get incentives aligned at the fifteen minute mark of earnings, the thirty minute mark, the forty five, the one hour mark. And how do you think those incentives translate into actual human outcomes, and the engineers outcomes? So you can't just go into just like how you can't go into cloud and collect all the data for me. It's about how you set up your entire factory with like very clear goals in mind. And for us, we have three things we care about. We care about completeness, we care about accuracy, and we care about speed. Right? That's like, frankly, the only three things we care about. And you can't just go to Claude and say, and maybe you could in five years, who knows, right? But you can't go to Claude and say, I want perfect data extracted from every document in a database in real time, go.
00:26:59 · Khe Hy
[00:26:59] S2: And if you look at those three parameters, assuming you're hitting them, you're delivering at the quality that you want, and you fast forward, is the company's strategy to expand into more data sets or to move more into the application layer? Or is there like, what's the where do you go from here?
00:27:19 · Thomas Li
[00:27:19] S0: Yeah, so we always think of a company as made up of two pieces, the workflow piece and the content piece. So they have the central goal is to solve problems for our customers, right? So if there is a problem that requires more data, then we will collect more data. If there's a problem that requires us to get better aligned with workflows, we will do that. But high level, content the job is to acquire datasets that can get us deeper and deeper into our coverage. Right, so we cover 6,000 companies today, constantly expand our coverage, that's just a motion that we have. But it's also about can we get deeper, right? So let's use like commodity companies as an example. Commodity companies disclose a lot of data just standalone. But they actually have regulators that are not security regulators. So think about like the environmental agencies around the world, and for particular commodities that might even be their own like regulatory agencies, and there are filings, right? A lot of these mines would tell you the reserve number, where their mines are landscaping with all these regulatory agencies. These are all information that can help you make better and more informed decisions, and the content is really hard to assemble. Right? Some of these guys you literally need to call the regulator for them to like FedEx you the documents, some of these guys need to develop a relationship. And so the content team's job is to make sure that we get deeper and deeper. The workflow team, the way we think about it is we call our work basically the thirteen week problem work, where every quarter has thirteen weeks. And if I looked at week four of every quarter, they have a tendency to look the same. If I look at week one, they all have a tendency to look the same. So the question is like, what is the most painful week? And of the most painful week, what is the most painful problem? And is that problem a problem we can tackle with a workflow solution? So for example, our first product is updating, right? We basically said the most painful week in the hedge fund analyst quarter is the earnings week, and the most painful minute of earnings week is literally the minute when earnings drops because you have to update your model. So what is the ideal workflow solution here is to create a button where if I hit the button, I update my model.
00:29:37 · Thomas Li, Khe Hy
So a workflow team's job is okay, identify this unique problem, and what is the ideal workflow outcome, which is to hit this button, right? So given that we have now developed that, what is the next set of problems, And what is the ideal workflow outcome for that? And usually our framework is the best workflow is always an invisible one. So we don't want to build into like some big UI that you have to like tinker with, and there's like knobs to turn, right? We want to build an invisible experience or an experience where you basically hit a button and it works. But the magic comes in identification of the problem, and creating a system that is so good that it feels invisible. [00:30:18] S2: And on that identification problem, are you using a forward deployed model or are your product managers that's being done kind of in house?
00:30:18 · Khe Hy, Thomas Li, Brett Caughran
[00:30:18] S2: And on that identification problem, are you using a forward deployed model or are your product managers that's being done kind of in house? [00:30:31] S0: Yeah, so we don't do forward deploy. And maybe we will in the future, but right now, the way we like to think about it is you need to be so integrated into your customer that you shouldn't have to have a forward deploy engineer, right, we should be able to just sit down, get a coffee with any of our customers at any time and just like really, really dig. If you have the philosophy and the culture of a business that is so deeply ingrained with the problems of your customers, you shouldn't need a proxy to tell you what the problems are. Right, you should almost be at one with how your customers operate. Right, so if I went to my team today and I asked them, hey, it's earning season, like what's going on? I should be getting a response, but like, Hey, this is what's happening, you know, this is the peak, here's what we expect at 4PM, here's what we missed, like, those are the high level things that we should be able to experience internally, because we need to live like our customers too. [00:31:29] S1: Thomas, how are you seeing funds integrate other sources of data, their internal data or their alternative data with the loop? And how has that changed as more top funds have gone down the agent path?
00:31:46 · Thomas Li
[00:31:46] S0: So they don't integrate into Dilupa. What we see a lot of is they basically start to create this orchestration layer internally within the fund. Folks have taken different approaches, some are building knowledge graphs to solve that problem. So everything feeds into the knowledge graph, and the knowledge graph feeds into the large language model layer where the agents sit. Some folks are basically not using that, there are other ways you can solve it, can connect a bunch of MCPs, you can create skills to help you orchestrate the MCPs. So some folks are doing that. The key benefit of doing it without the knowledge graph is access control. Because if let's say team A does not have access to a certain asset and team B does, then you can't really go to create two different knowledge graphs, you can't create a knowledge graph for every single person based on their licenses. So it's hard to do that when you are really, really scaled out, you're trying to build infrastructure for everyone. But you can say, okay, instead of building a knowledge graph, captures context, can I use a bunch of orchestration skills to do that, and then connect all the MCPs? I think the most forward thinking buy side firms, they also tend to be larger, will work with vendors and walk them through where the MCPs are good and not good, and where they need to work on. I think it's easy for a vendor to look at their MCP and say, here's the customer's problem, but your end user's problem and the enterprise's problem might be wholly different problems. Right, so like making sure that you can solve both problems in your MCP also really matter.