01:00:28 · Varun Badhwar
[01:00:28] S0: Actually, even more fundamental, which is what's a vulnerability? Like now you're talking about securing an ecosystem of code that is being generated 10 times faster with more security problems, but also the dynamics of the individuals you're working with, is you're going back to their baseline. So at that point, to your, I basically where you're going with your idea is security just needs to be autonomous. Security just needs to be handled for the user, not being something that a user needs to think about and be trained about. And I think that opportunity exists. Think about this. For the last 20 years, for people who are on this podcast that are listening, that are software engineers. Every year in your company you go through an annual security training. They teach you how to write code. But then there are 20,000 of you in the company. Do we realistically believe that 20,000 people will remember and follow all the instructions on how to do things manually? Unlikely. But with agents, you can actually give agents consistent instructions to follow the same parameters if you can infuse that intelligence to them. So like at Endor, our product infuses that intelligence into cloud code, into cursor, into codecs. And just make sure when they are creating these loops of code, the security intelligence is fused in and they're instructed to fix the problems they're introducing right at the source. And I think agents are far more capable to do that consistently than humans can. I think that's the we've been talking a lot about like the risks of AI. But that's the boon of AI. We can now solve these problems that have been unsolved for 20 years, despite more volume, despite reduction in time we have to fix these differently. And that's what I'm most excited about.
01:02:13 · Siddhartha Ahluwalia, Varun Badhwar
[01:02:13] S1: So uh at Endor, when the code is getting reviewed as it's getting written, is it completely autonomous? [01:02:24] S0: It can be. Some of our customers are in the everything is fairly autonomous unless it's a known large disruptive change, you gotta bring a human in the loop. There are others that are still using our context to create gear tickets and not be in the developer workflow. This goes back to my uh example of meet customers where they are and then take them to your promised land and dreamline. If we had designed the product to just be autonomous, what would we do with all the customers that are not ready? And so I think it becomes really important to think about designing your product for the masses. And that's kind of where one of the common fallacies a lot of startups in Silicon Valley have is they'll talk to their friends in Silicon Valley, understand the problem, build a product, and be like, oh, well, nobody else is really thinking of it this way. And so I always tell people when they're ideating, don't be in the bubble. Get out of the bubble and go talk to you know the company that has a 40-year-old code base or has 100,000 employees worldwide that is regulated entirely differently than how Silicon Valley operates. [01:03:52] S1: But but your agents are always watching the AI coding agents, whatever they be. Yes.
01:03:52 · Siddhartha Ahluwalia, Varun Badhwar
[01:03:52] S1: But but your agents are always watching the AI coding agents, whatever they be. Yes. [01:03:59] S0: So our security agents essentially get integrated into the um your favorite IDE, and they are established through workflow and requirements to be a step in the coding process. So when Claude is iterating on your spec and writing the code, Claude's job is not done till it has gone through Endor feedback on that code, seen what problems it introduced, fixed them, re-verified them, and when Endor says good, that's when the plan is complete. [01:04:36] S1: So whose responsibility is that uh the Endor's plan is executed? Is it Claude's responsibility? Is it Endor's responsibility? [01:04:46] S0: Uh it's a it's a shared responsibility. It's the way you um insert the product into the workflow. So with Claude, with Cursor, they're now giving you more and more tools to enforce certain tools to be run or certain actions to be taken. And so using those things, specifically, uh Claude has something called Claude Hooks. You can actually mandate deterministically that Claude has to abide by the instructions of Endor. So that's how it works. We use their configurations to put ourselves in the workflow. [01:05:22] S1: So does Endor today become like a firewall, like omnipresent and um there are components of it that does.
01:05:22 · Siddhartha Ahluwalia, Varun Badhwar
[01:05:22] S1: So does Endor today become like a firewall, like omnipresent and um there are components of it that does. [01:05:32] S0: Actually, it's interesting you bring up the word firewall. With malicious open source, right? I told you this is free for all. You pull this, by the way, it'll surprise you to hear that the agents, a third of the time when they're recommending open source libraries and dependencies, they're making it up. They are not real names, they're not real versions, or they're pulling really outdated stuff. So if you think about the Firewall concept. What Endor will do is any developer or any agent that is pulling an open source package or an open source model or a skill that is malicious, that has malicious instant intent because we're evaluating them, we can block them. We actually call it a package firewall. So in some use cases, yes. But I think firewall also annotates a slightly different meaning to me, which in package firewall case is like a yes-no. It's a guard at the gate. We're not just a guard at the gate that is one use case. It's also we're the fitness trainer, we're teaching that agents how to write more secure code for you. We are your house manager, right? When all of this pile of more new vulnerabilities comes in, we're figuring out what you need to fix, how to fix it, getting that job done for you. So I think it's all of the above, right? We we want to run your house as effectively as you can. So we're a house manager, we're a cleaner, we're a security guard, all of that.
01:07:05 · Siddhartha Ahluwalia
[01:07:05] S1: And uh, you know, one of the things, you know, before we dive into the last part of the podcast, which is Rapid Fire, uh, is you know, for the founders that are listening and their companies are in acquisition discussions, what have been some of your best learnings on the ground on acquisitions, on the process, price, getting multiple LOIs to make sure that, you know, uh in US the uh the LOI drop rate is one by third. Like only one by three, one out of three LOI LOIs get converted into. Yeah.
01:07:39 · Varun Badhwar
[01:07:39] S0: I think we can probably record a whole podcast on this topic. Um in a rapid fire style, no particular order, I'll I'll share a few things. One, you know, you can't when I start with saying as a founder, never a lot of people come to me and say, well, I'm just building this because I want to get acquired in the next year. And I say, like, you're building for the wrong reasons then. Um, your job is to be bought, not to sell. And in order to do that, you have to be in a position of strength. In order to be in a position of strength, you don't think about and build a company to get acquired. You build it to be the best or the second best at worst case in whatever problem you're solving. So I think that's one thing for me. The second thing is these relationships start long before transactions. So, you know, if you know that you would love to, or you think your target, ideal targets are these three companies, you should be finding ways to prove the better together stories years before. A lot of times manifests as potential investment, strategic investment, could be them being a customer of your product, could them being doing co-selling of your product, there being technical integrations and value delivery. So that value and engagement needs to start way before, months to years before a potential acquisition. Because you want to show, like, this is so obvious. Like, why aren't we doing more of this? Um, most acquisitions also fail. Like, I think you talked about the LOI rate. I would say 90% of the acquisitions probably fail post-closing if just like didn't deliver the promise. And as I've kind of inspected that much more closely as to why that happens, I think the fundamental mistake, the obvious mistake every company makes is great, I acquired this company. There's 500 people from this company I acquired. I'm a 5,000-person company, so guess what? The hundred engineers will go into my 2,000-person engineering org. And the 50 sellers will go into my thousand-person sales org. And you know, and you just break the entire culture of the company. And you'll usually put them under a GM of a business that likely has failed to solve this problem internally. Because if they hadn't, you would have not gone out and acquired a company. If you could have done it better, you would have.