Building the Intelligence Layer for Wall Street (Rogo CEO)

All right, thanks for having me tonight. I'm Gabe. I'm the CEO and co-founder of Rogo. We're building AI agents for financial services, for investment bankers, for investors, for folks that invest in public equities, private equities, all sorts of stuff. I was an investment banker at Lazard. I did M&A coverage for healthcare companies. Before that, I studied computer science and machine learning at Princeton. And really our goal is to make the generative AI platform for finance, the intelligence layer for finance. We want to transform how that work gets done. Our goal is to make our users smarter. And obviously, you know, you have to define smart in the context of the job to be done. And for our users, that means better decisions faster. And we also want to save them time because there's a huge amount of work that, you know, is kind of the accidental complexity of finance, of normalizing data, pulling numbers, research, putting logos on a PowerPoint page, doing Excel modeling. That's not that exciting for Excel. We're used by tens of thousands of bankers across some of the world's largest banks, some of the world's largest investment firms, asset managers, family offices, and so on. And really, the impetus for Rogo was when I was at Lazard, it became apparent to me and also bizarre that the world's largest, most important business transactions, M&A between $100 billion companies, was bottlenecked and rate limited by 22-year-olds and 50-year-old tools at 3:00 AM. And I was the bottleneck for a $50 billion transaction. And the fact that, you know, you can go on to Robinhood and buy a bunch of stock and Citadel can market make and, you know, do hundreds of millions of transactions instantaneously. But if you're Bob Iger and you want to sell Disney, you're going to be rate limited by a kid who just started at Goldman Sachs, and then you're going to have to pay $20 million for it was bizarre to me. And so why do people use Rogo? Obviously, there are a lot of generative AI tools out there. And I, you know, To Mitch's point around, you know, why do you make a tool just for a specific vertical rather than for everyone? Well, there's a lot you have to do to make it work well, right? The building in a generalizable way obviates all the small details, the long, the context management, the integrations that are specific to your vertical. And for us, we're purpose-built for finance. And that means, you know, the prompts are purpose-built, the context management is purpose-built, the UI/UX, the features, the integrations, the data, Everything is specific to financial workflows. The second reason we're able to work with large banks is deep client partnership. You know, these are not simple workflows. These are not simple institutions. They require a very white glove approach. You know, I didn't name our team a deployed intelligence team, but, you know, there's a very similar thing where we have to go into a bank like a Wells Fargo or a Lazard or whoever our client is and teach them how to use the product, scope the use cases to what they're doing, connect their data. Sometimes there is custom code, sometimes it's custom prompts. There's all sorts of work to be done. The final reason finance needs a specific type of platform is because there are very high bars to entry around security compliance and regulatory issues, whether it's flagging for MNPI and data upload or just being able to deploy in a way that a bulge bracket bank is comfortable with. What happens when finance becomes AI native? And this is not accounting. This is— it's hard to figure out what to call investment banking and investing. Sometimes I just say high finance. But for me, the reason it's an exciting domain to work on is when I think about what AI is going to do, it's going to raise what we're able to collectively do and think together. If you want to work on a problem set in AI where there's an unbounded price people are willing to pay to be smarter, that's in the financial services domain. And if you can be the intelligence layer that makes the capital allocation just a little bit more efficient, get capital to the right businesses, the right people, the right teams, if you can democratize access to these services such that emerging markets companies, you know, companies in Middle America that can't pay to work with Goldman Sachs or JPMorgan to sell themselves or raise capital can, well, then you can create a vastly healthier, better global economy. And so that's what we're working on, and that's why we think it's important. But the way to think about Rogo is it's an AI agent that connects to all the same tools, data, output formats that a banker does. For this demo, it's only publicly available data. You know, I'm not showing any private data. But there's a lot that it can do. A very basic example that I like is building a comps table for FactSet versus peers. These are my public comps. And so I often run questions like this, which are questions that a VC might run, a growth equity investor might run, a banker might run if I'm asking someone to help me raise money. And what Rogo does is it's a tool, it's a reasoning model like a GPT-5 or an O3, where it's able to reason on the fly, assemble, go out, retrieve a bunch of data, and pull in context. Sometimes these queries take a while. And so this one was actually fairly quick. But you can see we're pulling in data. We're pulling it in, in this case, from CapIQ and other sources, not FactSet, but I can configure that. And just doing a very basic question that a ChatGPT would maybe not be capable of because it doesn't have the long tail of integrations with a FactSet, a CapIQ, a Bloomberg, and so on. And then a lot of what we work on is the product interface around making sure the answers are, you know, not just as accurate as possible, but to Mitch's point, auditable, usable. You know, we expect we're not going to be fully accurate the same way an investment bank expects their analyst is not going to be fully accurate. That's why there's an associate and a VP and a director and an exec director and an MD who all, you know, tear apart that work before it goes to a client. And for us, making these systems usable means making them auditable. And so for a kind of basic question like this, which is just go through Google's transcripts, try and find any KPIs around traction, we're able to bring you to an underlying source for every single one of these. And so if we're saying we're helping billions of people, I'll make it very easy for you to go in and see exactly where Sundar said that. Or if we're pulling from— I guess these are all transcripts because I said transcripts. But if it was internal data, if it was a PDF, if it was an Excel model, All of the same things still hold. Instead of running a bunch more of these, I'm just going to pull up a few. Another fun one, since these are folks who are interested in the VC ecosystem, just pulling PitchBook data, being able to query over Crunchbase, PitchBook, and so on, being able to estimate how much a VC might own in another company. In this case, I was curious how much Thrive owned of Cursor, and so I asked Rogo to build up an estimated cap table. The reason we're able to do this and other systems are not is because we can go in, we can identify the companies, we can then pull in their fundraising data that's proprietary, and then actually start to build out an Excel model that might contain some of this data too. What else do I have in here? Comparing hyperscaler revenue growth and so on. We also produce PowerPoints. We also have some other features where we, you know, analyze data in tables. We have the ability to schedule some of these agents. And then there's much more robust workflows, what we call through pro and deep research. I've been showing fast just because it's no fun to demo a 10-minute-long report. But the sort of caliber of output is only increasing. And so I thought it would also be fun to talk a little bit about how we think about building agents. And for me, I mean, I pretty much agreed with everything Mitch said except for the fact that, you know, GPT-5 was only maybe smarter than Mitch. I think it's probably smarter than all of us here. combined, it just doesn't have the right tools. It literally cannot go out in the world and do anything. For me, when I think about building Rogo, I just need to give it the same tools that a human analyst has. AI agents for finance only need a few types of tools. GPT-5 made this very nice graphic for me. But any given workflow in finance, I think there's basically only 3 things that could be missing for an agent to be able to do it. Either it doesn't have the right tool, Excel, PowerPoint, screening, an ability to update a CRM, the ability to update a VDR. 2, it doesn't have the right data. It doesn't pay for a FactSet license. It doesn't pay for a PitchBook license. It doesn't have access to transcripts or private market data or private credit data. Or 3, it actually doesn't have the know-how. The reasoning isn't there. The kind of brain of the model or the brain of the human isn't comparable. If you've never scrubbed comps before for an MD who's very granular about the EBITDA adjustments for TMT companies, how are you going to know how to do it? Maybe that's in domain for the model providers. Maybe it's out of domain. It's sort of up to you to solve those reasoning challenges. And so what are some learnings from building this tool? And I'll caveat all of this with, we got started about 3 years ago, and we've had to rebuild everything every 6 months, maybe more often than that. I would say these are kind of 3 of the most important takeaways from building the tool. The first is the debate between model training and great engineering. And in my mind, There's 3 types of AI app layer companies today. There's those that treat RL and model training like a big hammer and every problem's a nail. OpenAI, Anthropic, the large labs where they just believe they can build up enough data, create the environments, and solve the problem. Then there's the kind of Manus and Genspark of the world. And if you guys haven't heard of Manus or Genspark, they're these pretty amazing consumer agents that I think are best in class from a product perspective, But if you go and read Manus's blog, which is fantastic, they'll talk about the fact that they believe they should never ever have to train a model. Instead, it's all just great engineering. To Mitch's point, great context window management, great ability to do KV caching so that it's low latency, great ability to get the agent the tools it needs as well as the actual memory. Then the third is companies that mostly rely on great engineering and through that are able to obtain data that's differentiated so that they can do some of their own model training. I think we'll see more and more of that, of the scaling app layer players. But for that, I think of a company like Cursor that is mostly just product engineering, adding memory, putting into your IDE, mostly app engineering. But through that app engineering, they've collected a boatload of data, mainly in the form of diffs. Do people accept an edit or do they reject an edit from their tab model? They're able to take that differentiated data and train a model that really surpasses the frontier. For example, they released their new tab model, which basically just means it's autocomplete for code, last week, and it's far superior to what the labs have been able to do. And the takeaway here is just you really need to know why you're doing what you're doing. And if you're trying to train a model, you should have a very good idea of why you're training a model and not just relying on great engineering, unless you're OpenAI. The second thing is that expertise is invaluable, and not just in, you know, being a PM, but in engineering the whole system, thinking about the systems that take place and need to happen for you to actually get the context the agent needs. And so the feedback loop in creating these products should be much shorter than the typical interview a customer, see what they like, go back and put it into the system. If you can't look at an output yourself and kind of tell, is that 90th percentile, is that 50th, is that 99th, it's going to be very hard for you to actually build the product for your end user. And not only is it going to be hard for you to build it, it's going to be hard for you to be a forward-deployed, engineer or ambassador for the product and explain it to your customer and get them on board and show them the use cases. And I think the value of expertise is just going through the roof. We're seeing that with companies like Merkur, whose whole businesses are predicated on finding expertise for folks, but also in these app layer companies that tend to be started by folks with some experience in that domain as well. The final thing is, is don't get bitter-lessoned. And this is trite and cliché, but I think it's so important. And for those that don't know, bitter lesson just means it's a, you know, I'm gonna butcher the concept 'cause I'm not a true, you know, not a true engineer. I studied it. But if you try and solve a very niche small problem, you're probably gonna get blown out the water by someone who trains a model to solve a much bigger problem. Example, you know, 5 years ago, folks at Bloomberg spent a lot of time training NLP models to classify sentiment in articles. So you could say, hey, this was a positive article for Apple, this was a negative one. GPT-3 did a much better job than any of their models did, and it does a heck of a lot more too. When you're designing a full system, you really have to pick your spots and decide, when am I going to invest in something specific to make up for the gap in the intelligence of model right now? And when am I going to let the rising tide of quality lift me up with it? And one of the things I would— and Mitch, sorry, I keep referencing your talk, but it was great. One of the things I would pitch Mitch on is memory and this idea that the models aren't going to solve the continual learning problem. I think there's one thesis out there, which is memory is a tool. You can just write down notes or write down and record stuff to a file system and then retrieve it later. Models aren't quite as good at doing that yet, but that might get solved. And so when I think about how we design our system, we actually always let the agent start from scratch, right? A year ago, we had to explain, hey, this is how you calculate EBITDA. Hey, this is how a PowerPoint slide gets formatted. Hey, bankers tend not to use the Oxford comma. All of that work was wasted. The base models know that now. And we had all of these small systems, small models, small components that was a complexity tax on our system, and we had to maintain, and we've constantly had to peel it out and throw it out. That said, there's all sorts of places where if you don't get to high quality today, you're not useful. And so you do have to create specially engineered systems to solve those. We're 60 people. We're based here in New York. We're hiring a ton across all sorts of things, but specifically engineering on Infrastructure, Platform Data Eng, and Product Eng. It's a lot of fun. It's a great team. And if you're interested, please either email me or go to that careers page. Thank you. Thank you.