# ⚡️Composio: 10,000+ tools that evolve for Agents — Karan Vaidya and Soham Ganatra Latent Space · 2025-08-04 Composio co-founders Karan Vaidya and Soham Ganatra join Swyx and Alessio to discuss their platform for self-evolving agent skills, now with 25,000+ actions and 100,000+ developers. They explain how MCP's client-side limitations led them to build a learning infrastructure that analyzes agent usage patterns to improve tool reliability over time. The team uses agents to build and maintain 95% of their 500+ integrations, adding 35 per week, with plans for 5,000 by year-end. They reveal that more than 20-25 actions confuse LLMs, so they offer a natural-language execution tool and dynamic tool exposure via MCP. Key challenges include enterprise APIs with poor documentation and the need for dev environments. Composio's internal agent benchmarks and A/B testing infrastructure optimize tool schemas for LLM calling. ## Questions this episode answers ### How does Composio use AI to build and maintain its own integrations? Soham Ganatra states that 95% of Composio's integrations are built and maintained by agents, generating over 3 million lines of code. The remaining 5% require manual intervention due to poor documentation or lack of dev environments for enterprise tools like Workday. [7:40](https://addtry.com/56acad54-5780-4b9a-a697-2c4d2876bbdf?t=460000) ### How many tools and integrations does Composio have, and how fast is it growing? Composio has over 500 applications and 15,000+ actions. Soham Ganatra says they were adding 20 per week, now 35, and plan to reach 100 per week, targeting 5,000 apps by year-end. Over 100,000 developers use the platform. [9:05](https://addtry.com/56acad54-5780-4b9a-a697-2c4d2876bbdf?t=545000) ### What limitations of the MCP protocol does Composio highlight for agent tool development? Soham Ganatra notes that MCP tools with long outputs can overflow context and lack post-processing. Tool descriptions are server-controlled, making client-side customization painful. Karan Vaidya adds that MCP is optimized for server creation, not client developer experience. [4:15](https://addtry.com/56acad54-5780-4b9a-a697-2c4d2876bbdf?t=255000) ## Key moments - **[0:00] Intro** - [0:36] "We are kind of self-evolving skills now, for agents," says Karan Vaidya, introducing Composio's evolving agent skills. - **[1:23] MCP Arrival** - [1:23] Q: How did Composio react to the MCP spec? A: Karan says MCP is great for universal clients but difficult for builders customizing on top, so Composio optimizes the client side. - [2:44] Karan says a learning infrastructure is needed beyond MCP so edge cases discovered by one agent benefit all agents. - [4:00] Swyx notes MCP limitations: large responses overflow context and developers cannot easily modify tool descriptions. - **[5:33] Evals** - [5:38] Composio uses an internal agent to test and evaluate its tools, asking the agent what can be improved, says Karan. - [6:07] Composio collects human feedback through MCP clients like Cursor to build internal evals, explains Swyx. - **[7:31] Auto Maintenance** - [7:40] 95% of Composio's integrations are built and maintained by agents, totaling over 3 million lines of code, says Soham. - [8:04] Q: What 5% of integrations can't be autonomously maintained? A: Enterprise apps with bad docs and no dev sandbox, like Workday — Soham Ganatra. - **[8:59] Growth Metrics** - [9:25] Composio has 500+ app integrations, adds 35/week, targets 5,000 by year-end, and has 100k+ developers, says Swyx. - **[10:15] Tool Limits** - [10:46] More than 20-25 tool actions confuses LLMs, says Karan; Composio flattens schemas and plans a single natural-language execution tool. - [11:51] Composio's search tool allows agents to find and execute from over 15,000 actions based on natural language queries. - **[12:10] Benchmarks** - [12:43] Soham explains Composio creates a benchmark for tool ease-of-use by LLMs and A/B tests tool designs to optimize reliability. - [14:49] Composio leverages MCP's dynamic tool exposure to A/B test different tool designs and optimize based on real agent usage, says Soham. - **[15:04] MCP Dynamics** - [16:09] Karan says Composio's 'Agent API' handles end-to-end task execution internally, like scheduling meetings from natural language. - **[17:13] Hidden Gems** - [17:27] Composio's underrated features include triggers that spawn agents on events and Code Act for agents generating code to use tools, says Karan. - [18:16] "You can use Composio inside of Composio" — Swyx highlights the meta tool aiming to be the single tool for all agent actions. - **[19:28] Porsche Hiring** - [19:41] Karan confirms Composio's Porsche referral bonus for hires, citing the difficulty of recruiting top engineers in SF. - **[20:19] Coding Tools** - [20:31] Karan's hot take: Groq CLI was better than Claude Code due to agentic capabilities, but he's back to Cursor. - **[21:09] Open Roles** - [21:17] Composio is hiring research engineers for RL, product engineers, DevRel, and growth roles. ## Speakers - **Swyx** (host) - **Alessio** (guest) - **Karan Vaidya** (guest) - **Soham Ganatra** (guest) ## Topics Agent Platforms ## Mentioned ChatGPT (product), Claude (product), Claude Code (product), Composio (product), Cursor (product), Gmail (product), Gorilla (product), Groq (product), MCP (product), Notion (product), Rippling (product), Salesforce (product), Workday (product) ## Transcript ### Intro **Alessio** [0:03] Hey, everyone. Welcome back to Lit In Space Lightning Pod. This is Alessio, partner and CTO at Decibel, and I'm joined by Swyx, founder of Small AI. **Soham Ganatra** [0:10] Hello, hello, and today we are so happy to invite Karan Vaidya from Composio, who just announced their Series A. Welcome. **Karan Vaidya** [0:17] Yep. Thanks for having me, uh, Alessio and Swyx. **Soham Ganatra** [0:19] Yeah. Uh, Karan, you, uh, I, I think we met a few months ago. I think honestly, you were sort of evaluating a move to, to SF and Composio, I think at the time was, uh, sort of like the, the bundle of tools for agents and sort of building that agent's platform. How do you, how do you introduce Composio today? **Karan Vaidya** [0:36] Uh, yeah, we are kind of self-evolving skills now, s- uh, for agents. So people building or using agents want to, like, basically make agents interact with their apps. They can use Composio. We manage all the authentication and user account related stuff for them so that they don't have to take care of all that and provide agent friendly skills, which can be anything from like a direct API call to a somewhat more complex, like directly agent giving natural language tasks to an app. And the idea is that kind of like the skills evolve over time. So we analyze the patterns of how the agents are using these skills and kind of like, like the specific usage patterns of a particular agent and improve these skills over time so that the agentic reliability is on a higher side over time. ### MCP Arrival **Alessio** [1:23] And you started this company before the MCP spec came out. It's been about two years. Maybe talk people through how that felt, you know. Were you excited when that came out, and did you have to throw out a lot of stuff and kind of move on to the, the new paradigm, or were you just happy that there was now a standard? **Karan Vaidya** [1:40] So yeah, I think, uh, firstly, MCP is really amazing and, uh, but it has its own quirks of how, like, it is good for some over like, like universal clients, uh, and not that great for like people building on top of. So like MCP is great, for example, if you want to connect your ChatGPT, Claude, Cursor, sort of a universal client with different apps. It provides a ton of, uh, like servers that people have already built. So like you can connect with all the tail end of applications. But even in the AI engineering conference, I was kind of like, uh, looking at the MCP stream and, uh, the MCP creator mentioned that they are optimizing the protocol so that like the ease of server creation is on the higher side and not so much for the client. So th- what that means is like kind of people building on top of MCP can't customize a lot of things and like it's kind of like the DX of creating on top of MCP is somewhat difficult while we are optimizing Composio for the like server side of, like the client side of things, so that like people building has-- have a very easy experience of connecting with tools. In addition, I think MCP is one of the protocols. There might be a lot more protocols that might come over time, but there needs to be an overarching learning infrastructure that need to be, uh, that needs to be developed, be it MCP or function calling, so that when one of the agent discovers an edge case, let's say, while connecting to Salesforce, like other agents also benefit from that. So that's what Composio is. We are over, like we connect via, uh, we will connect, uh, to Composio tools via MCP, via function calling, via Code Act, multiple formats, and like all of them have the same learning infrastructure. **Alessio** [3:17] When you say there might be more protocols, do you have ideas on how to make it better or requests for MCP improvements or what should people build if they wanna get a new protocol going? **Karan Vaidya** [3:26] So I think MCP, as I mentioned, is great for like the server side of things, but they can do a lot of improvements on the client to make it easier to connect to different servers. In addition, we have now seen a lot of like vibe code, coded platforms. So like Code Act is becoming somewhat more real. We have seen like recently a surge in how people use Composio tools via like directly code generation. So I think that still is somewhat new. So like there might be some changes that needs to, mm, that need to be done to improve on that. **Soham Ganatra** [3:58] Yeah. So by the way, I can, I can take last couple of, uh, like maybe just to add some more context on last couple of questions. Uh, the first answer, like how MCP could be better. So, so some of the limitations that we have been observing in production is like, um, MCP, uh, let's just say you have a tool that has really long context, a really long set of response. Currently, if you use MCP for those kind of tools, it ends up sort of messing up, right? Because let's say I'm trying to fetch like 100 emails on Gmail and my sort of context overflow occurs, and I'm not able to sort of post-process the output that is coming out from MCP. I'm not able to sort of play around with it before it reaches my set of LLM and, and a lot of like potential failure scenarios like that exist. Some of the other things that we have observed is like, hey, maybe I want to sort of change the tool descriptions, but like in MCP, the tool descriptions are controlled by the server itself. And so essentially for me as a developer who's sort of using an MCP to build on top, like messing around with tool descriptions or messing around with tool schemas becomes a very, let's just say, painful experience, uh, to actually do that. So a lot of like this client side thinking, just like how do you optimize the whole thing so that for a developer who's sort of building on top is kind of missing today. And truthfully, like when you talked about like new product, like so many thoughts emerged in my brain, but the, but the, the way I would put it is I think we are like really sort of in the emergent phase. Few different lines of thinking I could get into on like how new prot-protocols could look like, but I don't really have a concrete answer to like where, where it should be. Right. Uh, yeah. Yeah, I, I think this is, uh, evolving skills over time. Um, any ways to eval this stuff? ### Evals **Karan Vaidya** [5:38] So we have an agent essentially which builds a lot of these skills and kind of like does a lot of like testing as well as eval. So it's like you can say like agent as an eval where our internal agent uses these tools and kind of like we figure out where it is messing up and improve over time, even asking agent what we can do better, et cetera. So that like that's one. Then obviously we have like how the agent is using it, where it's getting stuck, that data to improve over time. Does that answer your question? You're looking for something specific? **Soham Ganatra** [6:07] Uh, th-no, I, I can add maybe a couple of more things and maybe that helps, right? So I think like MCP, by the way, uh, so one of the really cool things that it ended up doing was it ended up sort of, uh, creating a very simple way to sort of integrate with universal flags. So for Composio tools to be used in Cursor today, it's super easy. Uh, anyone can go start using it. And that creates a very sort of interesting way for us to actually create eval then. Because then I can allow anyone who's using Composio tools via Cursor to essentially give me feedback right inside the Cursor chat window saying, "Hey, were we able to sort of execute on what you wanted to execute on?" Uh, and, and so we are, we are getting a lot of like human feedback through this, and we are able to sort of u- somehow accumulate some part of that feedback into like a internal sort of eval. Uh, so again, tool calling has a lot of different evals. You have seen the function tool calling evals, you have multifunction tool, like, like multi, multi-turn, uh, tool calling evals. But like none of them are actual like production call it. Like, like none of them are actually something that we are able to rely on truthfully, because like they don't really represent the situations that occur, like the orchestration issues that occur, uh, in a complicated sort of scenarios, uh, that, that you often see in production. And so this like getting the feedback through MCP clients and essentially using that in some way is something that we are actually finding it way better for at least our internal set of benchmarks. **Alessio** [7:31] Are you guys doing any autonomous maintenance of these integrations? So you get this data, what happens next? Like, do you guys manually kind of review it and decide where to work on it? ### Auto Maintenance **Soham Ganatra** [7:40] So ninety-five percent of all our integrations are completely built using agents, maintained using agents. Uh, we-- I think at this point we have a repository with more than three million lines of code completely built using agents. Uh, all, all the integrations out there that you could think of. **Karan Vaidya** [7:55] And even the maintenance, uh, of sorts, like if kind of like something goes wrong, we figure it directly via our kind of like observability platform and like the agent gets self-corrected. **Alessio** [8:04] So what's the five percent that you're not maintaining? **Soham Ganatra** [8:07] Uh, the, the enterprise tools that have really shitty documentation and, uh, you, you basically just wish that if they had taken like maybe ten percent more time documenting the edge cases, uh, I would have solved it. Uh, and like more than that, the problem is that they-- you, you need a dev environment to sort of run these agents on. Like, a lot of these enterprise tools don't really have that dev environment. Like a very simple example would be, okay, I want to sort of integrate with Rippling, but like my dev instance of Rippling has no HR data, and so what am I going to do? And so like you do your best case analysis of like what the API is like looking like and how to go about it, and, and then you try that. And like real sort of applications that I'm talking about are like Workday and like, like they, they, they're really terrible, right, in terms of the documentation they, uh, sort of put out, right? So yeah, tho-those kind of applications. **Alessio** [8:59] Can you maybe give people some numbers about how many integrations you have, how many dev-developers you have, maybe the growth rate of integrations? Like how many do you add? Is there like a big backlog that people are requesting? ### Growth Metrics **Alessio** [9:11] I think there's a lot of people launching MCP servers. Like you said, it's not very easy to use them, so I feel like sometimes it's like a marketing launch to do it, but then there's not a lot of usage. Like also, what are you seeing the most popular ones? Just give us some numbers. **Soham Ganatra** [9:25] Sure. So we have at this point, more than five hundred different applications on top of Composio. We are adding close to, at this point, like, like we, we were adding like close to twenty a week, like a month back. Now that, uh, like a lot of sort of improvements have been done on the agent side, we added like, last month has been like basically thirty-five a week. Uh, we're planning to sort of ramp that up to like close to a hundred a week in next month. Planning to reach like a target of like five thousand applications by end of the sort of year, uh, which would like put us in the similar lines of like all the sort of-- like which would essentially encompass all the major applications you could think of. Um, in terms of developers, we have like more than a hundred thousand developers who have been, uh, been building on top of us, um, and like trying our product out. **Karan Vaidya** [10:10] Yeah. Uh, uh, yeah, what, what were the, the numbers you kind of asked, uh, to ask? ### Tool Limits **Alessio** [10:15] Oh, that's kind of like the Composio product platform. I think there's maybe the other ninety percent of once you have the infrastructure, how do you kind of make it successful in your product? There's a lot of talk about how many tools an LLM can support, whether or not, you know, you should give different tools, whether or not you should put all the tools in one MCP, which you guys also offer with the Composio MCP. Can you maybe give people kind of state-of-the-art today, where do things go wrong, uh, and maybe the slope of improvement of the models? **Karan Vaidya** [10:46] Sure. So I think, uh, like we have seen over like a lot of practice that like more than like twenty, twenty-five, uh, actions, like just confuses the server. Like it's not able to kind of like figure out which tool to use. And same goes with like if the schema of the tools are really complex, that also confuses the agent. So we try to keep our kind of like schemas simple. Like some of the things are like flattening the schemas, et cetera. In addition, I think, uh, like basically I think it's like agents, like because they are LLMs inherently, so they like to think in natural language. So some of the thing that we are planning on that front is like a single natural language execution of a tool so that like the agent does-- just gives like, like agent is just given a single tool and it can call any of the other kind of skills that we have like inside Composio with just natural language. So like create a Notion doc and send a meeting invite just in natural language and we'll do that in the back end. **Alessio** [11:38] And when you do that, do you have-- does the Composio MCP have a search tool that the agent can use to search what tools to have? Or like do you put-- like you know when you have an MCP, it kind of exposes what tools are there. Is there just like a big list or do you use search for that? **Karan Vaidya** [11:51] We do have a Composio search tool which kind of essentially does exactly what you said, like searches across all the... Like we have around like fifteen thousand plus actions that we support across Composio tools, so it can search all across depending on the natural language use case that you provide and kind of like then execute that specific action. **Alessio** [12:10] What, what do you guys use for benchmarking? So there's kind of evals, which is like internally what works. I know for a while there was the Gorilla, kinda like a benchmark function calling thing. Is there anything new that you kinda keep track of, or is it maybe something you should do? ### Benchmarks **Karan Vaidya** [12:26] Yeah. Soham, do you want to? **Soham Ganatra** [12:28] Sure, yeah. So, so essentially, so there are, there are like few, right? Like Gorilla was one, but then like a bunch of others emerged, right? And they were all sort of more on the base of like, is an LLM sort of good with tool calling, right? We are trying to create a different kind of benchmark, which is like, how good is this tool for LLM to be sort of like calling it, like in the correct fashion, right? And this is more like in the lines of DSPy, if, if you look at like how they're... like, like they sort of engineer the prompt and stuff. We are trying to engineer the sort of tool in a way that like it becomes easier for LLM to sort of call it. Like internally, we have essentially... The, the way I would go about it is like you can break it down in two terms. Like we have figured out the right heuristics that we have seen essentially work better for LLMs, and then we have also sort of given like a A/B testing kind of infrastructure for LLMs to go ahead and like test out with. So there are like two kind of optimizations we do, right? One is like, is the tool to the API transformation right? Which is like, is this Salesforce tool getting transformed into the right request payload so that it is hitting the right endpoint in Salesforce, right? And that is like the major source of error today because a lot of documentations are not great, a lot of like edge cases are not mentioned, and you kind of keep seeing that issue. And then the second feedback that we kind of optimize for, which is like, is the Salesforce tool really sort of simplified so that an LLM can call it nicely? And that optimization essentially, uh, is built on a bunch of sort of internal like benchmarks that we have, which is like, which are around, here's like a query that we saw, here's a query that LLM couldn't really transform into the right set of Salesforce call. That is the reason Salesforce API co-endpoint resulted into failure. How do we sort of like make sure that we are able to get those kind of queries working nicely, right? And like we keep seeing the meta patterns emerge here, and then we do A/B testing here, which is like if we would've built the tool in this way, and like all of this is through agents, of course, we can't do it manually for all the tools, but we start doing A/B testing that way. So like if we had sort of built the tool in this way, maybe this query would've been easier resolved, right? And the, the reason sort of MCP helps here is because if you know MCP allows you to do dynamic tool sort of like, uh, exposure, which means essentially like based on the query, I can decide what tools to expose and how to go about it. And so we can do that. So we, we can essentially decide that for the same Salesforce, uh, for the same query, we can expose two different kinds of Salesforce tools to the MCP client and just see like what tool is being better sort of used here. So, so that's the infrastructure we've been building. ### MCP Dynamics **Karan Vaidya** [15:04] I, uh, I was aware of, uh, tools discovery in MCP, but I didn't know that it was that dynamic. Um, can you say more about that kind of behavior? **Soham Ganatra** [15:12] So, so essentially, what you can do is like you can decide what tools to expose, right? So since the Salesforce server is with us, like the MCP server, we can decide like in 20% cases we want to expose these tools, and in the other 80% cases we want to expose these tools. And then we can expose like different tools for different people. Uh, and so we can know like what tools are essentially getting better results. And then the dynamic tools, there, there's also one more layer of dynamicity that is coming, which is like in MCP you can actually change tools, and you can notify the client that you have changed tools while MCP is, uh... Like, like I, I can share that with, with you, but like we have, we have been building around this also. The idea here is that eventually we want to sort of create a layer where like we can like keep like changing tools and like recommending better and better tools. Let me just quickly share this with you, like the, where it's coming essentially. **Karan Vaidya** [16:07] In the MCP spec, I- **Soham Ganatra** [16:09] Yeah, yeah **Karan Vaidya** [16:09] ... I was looking at the sort of the, yeah, the tools page. **Soham Ganatra** [16:12] Yeah. **Karan Vaidya** [16:13] Cool. Well, I, I didn't, I didn't know that, but I, I haven't tried to sort of, uh, extend it to as many tools as you have. **Soham Ganatra** [16:18] Yeah. **Alessio** [16:19] I was gonna say, the other thing at the Engineer World Fair in the MCP track was, uh, sampling, which was pretty new. I don't think many clients supported it. Is that interesting to you guys, like having the MCP server also do some LLM inference before returning to the, to the client and... That, that seems like one way where you can take over more of kinda like the, the value that happens in the, in the value chain. **Karan Vaidya** [16:42] Yeah, I think, uh, as I was mentioning, kind of like one of the tools like or kind of like servers that we support, which we internally name as like Agent API, is essentially that, where kind of like the whole end-to-end, um, use case to tool formation, like, uh, kind of like tool calling formation is done by us. So the client just gives, like for example, that it wants to schedule meeting with like five people, probably just names, and we figure out all their email addresses beneath the, uh, kind of like the server and kind of creates, uh, create the meeting invite with that. **Alessio** [17:13] We're gonna probably zoom out from just the product itself. Anything that people are missing about Composio, like, um, underrated parts of it? Or obviously you're growing so fast, you just moved to SF and opened a, a new office, so everything is super exciting. ### Hidden Gems **Karan Vaidya** [17:27] I mean, like, uh, a lot of features, uh, that we have, like including, like one of the most used features which kind of people discover after they come to Composio is, for example, triggers, where it's not just like the agent can take action, but they can get notified over time. So like, essentially when y- uh, like when you receive an email or when you receive a Slack message or like anything that you can use to spawn an agent, uh, that it can work on top of. The other thing that I'm like really excited about and we are optimizing our tools for is like Code Act, where a lot of like, a lot of tool calling is happening via generated code. So you can use Composio's, uh, actions not directly in like MCP or tool calling, but like expose them as functions which the LLM can use while generating code. So that's very interesting, and we are doing a lot of optimizations on that front. **Alessio** [18:16] Yeah. Awesome. **Karan Vaidya** [18:16] Uh- One, one of the, the things I wanna call out is I was looking at the tools list, and you can use Composio inside of Composio, which is, uh, very meta. I, I wonder if like that's the ultimate end state of everything. **Soham Ganatra** [18:28] Yeah, that is. We, we built it like a year back. Nobody used it for a very long time. Today, it's probably one of the most used tools. The idea here was that we just wanted anyone to just install Composio and inside Composio, and that's pretty much it. You don't need to think about anything else after. **Swyx** [18:45] Yeah, but like this is, this is then like sort of the, the tools discovery layer or like, you know, the one MCP through all the MCPs, depending how you think about it. **Soham Ganatra** [18:53] Yeah, yeah. Like one way to think about it is like, okay, this is basically like me sort of just talking, learning about it. But essentially, why do you need like a layer of tools? Because you want to sort of execute stuff on the client, right? But let's say if a server is smart enough, and like basically if I build something very interesting and I say, "Hey, you don't have to worry about anything, just send me the query and let me do all of the stuff," then like you don't need a layer of tools. Then you just need one tool. Like, "Hey, here's the query. Go do it," right? And like that's the idea, which is like Composio eventually gets to that point where like you just give us the query and we just do it, right? That's it. **Swyx** [19:27] Yeah, fair enough. **Alessio** [19:28] Uh, awesome guys. So you, you're offering people a Porsche if somebody refers somebody to work at your company. If they apply after watching this, do we get the Porsche or what-- how are you doing attribution on, on these things? ### Porsche Hiring **Alessio** [19:41] Has the word- has that gotten you a lot of traffic? I'm curious. **Karan Vaidya** [19:43] It has. It has. I think- **Soham Ganatra** [19:45] Definitely. **Karan Vaidya** [19:46] Yeah, I mean, I mean like obviously like I think it's anyway hard to kind of hire really good engineers in SF. We have like a lot of competition all around. So kind of like that was the idea where we want some of the best engineers to work at Composio. So I mean, yeah, like if somebody like sees this and applies via the Latent Space, uh, happy to kind of like, uh, give you guys a Porsche. **Alessio** [20:10] Please write that, write that in the application notes. "I heard about it from, from Latent Space." **Swyx** [20:15] Yeah, yeah, I, I'm actually in the market for a car, so this would be really nice. ### Coding Tools **Alessio** [20:19] All right, get to work, Sean. Other hot takes, Karan, you had a tweet about Groq CLI being better than Claude Code. So maybe we wanna talk about coding stacks and why do you think that is? **Karan Vaidya** [20:31] Uh, so yeah, I, I mean like when Groq 4 came out, we were, uh, like experimenting with it and, uh, like just developed the CLI because there was none. Like for Claude, you had Claude Code. Uh, you can use probably Codex, uh, with, uh, Groq 4 as well, but, uh, I think the idea was, I think Groq 4 actually has some of the really cool agentic capabilities. So kind of like I think-- I really love Claude, uh, Sonnet for example, because of the same. And Groq 4 had like some of a mix of Opus and Sonnet which I really like, so kind of like wanted to use a CLI to use that on my code base, so kind of just developed it overnight. **Alessio** [21:05] Are you still using it? **Karan Vaidya** [21:06] Not that much. I'm a Cursor fan, so I think move back to Cursor. ### Open Roles **Alessio** [21:09] Oh, awesome. Awesome, guys. This was fun. Are you-- obviously you're hiring. Any engineering roles, any other open recs? **Karan Vaidya** [21:17] Yeah, I mean we are hiring across, uh, like a research engineer to work on some really cool RL stuff that we just kind of like to build skills on top of tools that we just discussed. We are hiring for product engineers. We are hiring for DevRel. I think hopefully somebody listening here, uh, might be interested, uh, to work in one of the coolest AI companies as it, and, uh, growth person, uh, as well. Yeah, any kind of these roles, uh, uh, would love. **Alessio** [21:45] Awesome, guys. Congrats on the Series A. Thanks for coming on and, um, I'm sure we'll see you around in SF. **Karan Vaidya** [21:51] Yep. For sure. Thank you. **Soham Ganatra** [21:53] Thanks a lot for having us. Bye-bye. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.