Lessons From The Trenches: Building Rube - Jayesh Sharma

So our next speaker J Sharma for his talk lessons from the trenches building group mic over to him. Thank you so much. Um thank you all for showing up u I'm really excited about this talk here. Um but before I begin I just want to get a hang of uh how the cloud is like and I'll just ask you a few questions to understand you a bit better. Um how many of you have used MCP servers in the past or are familiar with MCP? Wow, a whole bunch of you. This is in like what kind of servers do you use? Like what clients do you use the most? Like what's the most favorite client that you must have used? >> Cloud. >> Cloud code. What else? >> Aama. Okay, cool. Nice. I was expecting cursor, but like surprising that people don't use cursor as a client. That's nice. Um Okay, cool. So I think u what I'll do through this talk is I'll walk you through why we built something called RP. It's more like a universal MCP server. I think it's that's easier to understand. And I'll walk you through my perspective of why we thought something like RP should exist in this world. And then once I've established that, I'll walk you through what are the lessons we learned while building this because we like also ran into a bunch of issues around context, windows, uh various of the problems as well. So we'll walk you through it. I'm Jesus. I'm most active on Twitter. Um and I work as an AI engine in here and multiple things at Compose. We do um bunch of things. So I I'll start uh with the challenges with the current MCB servers. So I think uh personally like how many of you have used MCB servers in the past like how many of you actively use MCP servers like you you so okay look at the stark contrast like I when I ask about MCP almost everybody knows about it but the amount of people who use this like a couple or maybe like four people here. What's the MCP that you use? >> Superbase. >> Superbase. Okay. >> Makes sense. >> Yeah. Yeah, I think like now like why do you think is there is a discrepancy between the number of people who know about uh MCP service and the people who actually use it daily like do you do you know what the reason is like anybody without looking at the slides of course >> they don't work in >> they don't work okay that's that's the separate problem altogether but I think like for me personally the problem that I faced was I need to like when I want to use a specific app I need to install the server for that app let's say I want to use der or let's say github whatever I need to go find that server install it and then authorize whatever give it to my API key and then it becomes active and let's say if I in the course of time I want to use like five more MCP servers then I install those servers as well and then you can't really have multiple MCP servers in the same client. So let's say if you have like seven active 10 active servers and it like really bloats the whole context up so that for me personally that was the reason I didn't use MCPS at all. I thought like why go through the whole hassle of going to like configure each and every server. So like chances with the random C service is that like I need like manless version of all servers there too many servers uh bloat the client and let's say if you have many tools in your uh context window also bloats the context window size so like you can't really have too many uh tool execions happening the same thing and authorization is painful of course so let's say some MCB servers just use API keys very simple put the API key works like environment variables but some other MCB servers require oorthth authorization so you need to like go allow give scopes and all that and you need to manage the tokens yourself also sometimes So authentication is also very painful. So for these reasons I feel like this is why discrepancy exists. People don't use MCB servers and that was one of the reasons why I thought we should do something about it. Um so what we need is this I want like some solution where I can just get a very simplified solution where I just have one MCP server idly which can figure out what tool select and when when to do it right that is what I want smart selection of tools. I also want like large context management because I've seen that as I said like we discussed right now that once you have a bunch of tools the context window explodes and like you can't really have a lot of conversation. I think people using cloud code I think we just talked about a lot of people use cloud code here as MCB client you must have seen that cloud codes like after a few conversation it says okay it complains about the context when you use a lot of MCP servers there. So that's a huge problem as well right. So I want something which can handle large context. I want something which can select the right MCB servers at the right time without me having to manually go install them. I want fast execution because I feel that okay like there it must be smart enough to know when to execute what tool how to paralyze stuff and all these things. So this is just my wish list here. So it's not really something super important. I think the first two points are very important because I want that to happen. Everything else is just like a added bonus. So what if it has caching in memory also let's say I I do something I execute a tool somehow it finds some ID from somewhere and then it stores it. It knows what my ID is and whatever and then the future executions it just figures out by itself. Right? So I want these kind of things. I want handling of complex queries. I can just give it whatever I want and it should be able to handle that. So all of this is why we've started to build something called RP. I'll get to Rub in the towards the end. But what I'll do right now is I'll ask if you have any questions so far about what we are discussing what we're trying to build and then we'll move on to the lessons that I learned from whatever we did here. Any questions so far? People clear on the server client why there is a need for something like this. All good. Perfect. So now I I'll move on to the lessons. So lessons from building these features. Uh I think uh one of the things we talked about was the large context window. So the way we solved it, I'll just quickly give you some tips. If you need more information, come to our booth. We'll like have a detailed technical discussion after that. But what we did was like uh when we for example we have this Gmail. Gmail is our top used app in Composio. So Composio provides manage toolkits for AI agents. We give you like tools which we write ourselves and manage execution for. Uh and what happens is like Gmail is one of the top used apps and there's a fetch emails action. By action I just mean a function where you can like fetch all of your emails and usually the responses are very huge like you get like a thousand like 100 responses 100 number of emails. So now what happens in that way is that your context will get bloated with all this huge context. So what we do instead in root is that we write it to some machine somewhere like a protected sandbox. they write to a temporary sandbox all of your tool response which are very huge and then the LM can perform actions like grab jQ whatever on that data to analyze data. So instead of putting the whole data into the context of the LM, you write it to a file somewhere. You tell the LM, okay, this file exists in this machine. You can use these commands to interact with the file and then the LM can decide smartly how to interact with the data, what data to extract. So that way you get over the limitation of large context sizes. Right? So that is one of the problems we solved. I think we have also a bunch of optimizations here which I'll talk about later on at the booth. But overall, this is how we solve the large context problem. Uh the second thing we talked about was like how to make it fast, right? Let's say if you have a bunch of things to do for example if I have a very complex query I'll show you some queries I'll ask for some queries from the crowd right now in a while but let's say my queries like look at all of my linear issues and then create GitHub uh issues on top of that and then add comments whatever like if I give a longass task then it would need to plan and execute things and it will take a lot of time if it does everything sequentially right so it needs to be smart enough to figure out okay instead of just executing one by one okay I'll call tool this I'll call tool that it's how traditional MCPS work what we do is instead we have a tool which is called multi-execute internally And what it does it figures out okay what tools can be called in parallel. So I can say okay I if I need to list linear ids for a given user I can do that in parallel with list Gmail for example like whatever commands it figures out that can be done independently and parallely are done parallely and then execution have a sequent so that way it's way faster than executing every tool one by one. So you get this out of the box. So whatever tools we support like root supports all mc I'll come to that in a while but we make sure that the tool execution that can happen in parallel happen in parallel. That's the idea. So that's what makes it a bit faster. Any questions so far? Yeah, go on. >> Yeah, like it it knows it knows dependencies of different tools. So composio is built on composure platform. So compos platform has all the tools that it needs and we have dependency graphs internally. We know what tool depends on what are the tool. So that way we figure out like that's why like I think it's built on it's a it's a customer of composer platform in a way RP. Uh but we'll come to that in a while as well. Cool. Uh I think the other thing that I was talking about is memory. I said like memory also adds a lot of value. It also enhances the experience. For example, like if if I if I talk about uh let's say we'll come back to the linear issues thing. Let's say if I ask about my linear issues, it'll first look at my linear ID and then list my issues based on that ID. The second time I ask you is to remember what my ID is and not have to like search again for my ID the whole process. Right? That is the idea. So memory helps and I think what we do is we store we figure out what the important memory is. So I told you there's a multi-execute tool, right? This tool is like which executes multiple actions together. LM decides what memory to store. We have memory layer which stores in the vector DB. And then ultimately when you search for tools and I'll show you how it works in a demo. So it become clear very well like how group does all of these things. But on a very high level group has these two tools which is like a search tool and a multi-execute tool. The search tool will tell you what tools to go for a given use case. So when I ask group to do something which I'll show you in a while, the group will figure out okay for this given use case I need to call these these tools and along with those responses also get the memory back. Okay, for these tools you have this memory already enabled from the past interactions. So that's how the memory works. So we have a very simple memory layer at subtraction. We'll continue to work on that. I think in the future we'll add more stuff but I think this is what it is right now. Um and the other thing is handling complex user queries, right? So we I want it to be more than just a bunch of tool calls. Let's say if I call if I want some action to be done, usually it involves more than just like a API call. It revolves around some manual processing to be done. For example, if you look at the example here, I said count the number of meetings I took this week and compare it to the last week. Figure out how many were with Jes for example, right? This is the query I asked. So this can't be just done by simple Gmail API calls or calendar API calls. I need to call something then I need to process something like I need to get the results back. It will some processing will happen. It'll count the number of meetings and we'll see okay what is attendee so what is the participants uh list of a given meeting and then is j there or not. So there are multiple things that need to happen in a bunch of things and what root does is it combines the API calls with code execution. So remember I talked about the sandbox earlier like where we store all the files which are huge. We also use that sandbox for executing code as well in a remote environment. So what happens is root can figure out what code to write based on the API calls. It then executes those code and then what happens is after that it'll figure out and give it a response back. So that's how it works. So that's how we handle very complex queries as well. Uh that's the whole idea around it. Um, so, okay, I just realized I also don't really have uh a thank you slide, unfortunately. So, what I'll do is I'll quickly show you how I'll add that with Rube. So, let me go back one second. Uh, so I'll come to what is Rub and why uh Rub why we built RUP. But before that, I'll quickly show you a demo because I think it'll make things a bit clearer on how Rube works. So, let me zoom in. Is this visible all good? Okay. One second. Oh, sorry. That didn't work. But I think uh if it's visible, I'll just go ahead. I don't want to take up some time here. Uh let's see. Cursor dark light. Yeah, perfect. All right. So now I'll go back here. So like I have uh an MCP server called Rubert. I I to call it Rubert, Roberto, whatever because cursor has caching. So I need to change the names every once in a while. So for me it's Roberto right now that I'm going to demo you. So I'll I'll ask it something like okay um uh I want to add a thank you slide to my presentation called uh lessons from the trenches building group. Uh do that for me. It's like I added this lesson in the trenches building. Okay, I have to this to rub and I'll press enter. Right. So now what'll happen is like this is all the prompt I gave like there's only one MCP server here and it'll now figure out like what tool to call based on this given query. Right? So so okay one second let me check. Yeah it cursor now figures out it needs to create a directory for me. I'll just do this. So like sometimes it doesn't really pick up like it has to use MC it just do something else but it's fine. So what happens is now root calls root search tools. Now this is a function which figures out what uh specific action to call for a given uh prompt. So you can see that it already has uh it has Google sites available. So if I show you the output of this tool, it will say what functions to call. So the input is okay I need to add a slide some known fields and then the result is what functions to call. So all of these functions are actions on compos platform. So compose gives you access to 600 plus apps. So like Google, Gmail in all the asset that you use usually and it has built tools for all of these apps for you automatically. So all root does is it tells okay what compos your actions to execute here and then it'll execute those actions going forward. So it found the tool yes and then it found manage connection. It says okay I don't have Google drive authorized because I need to find the presentation from Google Drive. So it just gives you a link very well and it waits for the connection to be active. So all I do is I click this authorize Google Drive. I open this here. This will open my account. I'll just choose this to allow composer to access my Google drive and that's only done once. So once I authorize Google drive root will remember my Google drive going forward and it won't ask me to do that anymore. So authentication successful I can go back to my thing it becomes active now. It already says Google is now connected. So that's how simple it is. So I don't have to go around like work with API keys find access tokens and that I just like click a link and now it already found my presentation. It says I found my presentation. So it called probably called uh something. It did something. I don't even have to worry about any of that. So it just find says it called the Google Drive find file function and it said name contains this thing. That's all it did and it found my presentation. It's already added a thank you slide to the end. So I think we'll keep it for later when we go back to my slides you'll find a thank you which Rub made right. So that's how simple it is. Like I didn't really care about it. It already had my slides connection. So I didn't have to authorize slides before that but I didn't have Google drive. So it did Google Drive connection by itself. So that's how simple it is. Right? Um and that's how it works. So this was very simple. We didn't really use any um code workbench because it's not a very complex query. But I would encourage you to come up with a query, come to our booth, give us the toughest queries you can think of and we'll see if can solve that for you. Right? I think it'll be a very fun challenge to do and if time I'll also do it here later on. But we'll go back to the slides for a while. We'll just complete whatever we have there. Uh take a few questions and then uh I think we can come back and play around with Rubbit. It's my favorite pastime to do that. Like I just try giving it some challenges. It can also do browser control. It can do Spotify a lot of a lot of other things like in a way not right now but yeah cool. Okay. Yeah. So uh roof is new server the only app server you need. So this is a QR code. You can scan this to take you straight to roofs. The installation is very simple. You just click a button. It installs in your cursor. Cloud code for the cloud code folks here and everything else as well. So just rub.app is what it's called. Um and yeah why like because it handles authentication as you saw already. It knows how to talk to what tool, call what tool when. I only have to install one MCB server. That's it. Plain and simple. Uh, and yeah, there's no management on your part as well. So, that's it. I think that's for the demo. Like, uh, how much time do I have? Okay. So, I have like five more minutes. Okay, cool. Perfect. So, now I think what we can do is we play around with group a bit more. So, that's nice. Uh, so yeah. Any any questions so far though? Any questions so far on like whatever I showed you? Yeah. Go on. >> Yes. >> Yeah. We talk to compliance. So like whatever data you have like we encrypt everything on our back end. So like even this is built on compos your platform. So like RP is just a consumer of composure platform and we already have a lot of enterprise clients on the platform itself and whatever we handle on the platform is completely secure. So we don't release to any of your data. Nothing is visible to anybody even internally in the company as well. So you encrypt everything in there as well. So I think Rub just uses that platform. So it doesn't really build data by itself. It just uses composio. It tells okay I need to execute this composio action executes on the compos platform and then get the result back. That's why like we're pretty secure in that fashion. And we'll also add more stuff going to rub. I think it's been only like recently launched and we're working on making it more secure for enterprises going forward. But right now as a consumer app for people to try out play and see if it works well. That's the idea. >> Rub extend. Oh yeah, of course. Yeah, that's the that's the thing which is coming pretty soon. So I think ne at by the end of next week, we'll have an MCP registry where the idea is that any MCP server on the web, let's say if there's a GitHub repo or if a docker exists, you can just add this to the registry yourself and R will be able to access it. So like we can integrate any number of repos like whatever repo you want uh with root. So there'll be a feature coming soon. Anything else? We have one. >> How do you third party with for like my customers, right? So here you clicked the link. Yes. >> And that created a token for Google Drive that's stored in somewhere your >> I presume. Yes. >> How do I do that for my customers? >> Yeah. Like I think we have uh this thing I'll show you. So on the platform side so right now what what happens is RP is a customer of the platform and what you will do in your case is you'll become a customer as well. So what you'll do is you okay I'll maybe I'll show you the dashboard. I think it'll be much clearer there that way. So if I go to the composerio platform or not here I'll go here maybe. Yeah I'll show you. So ultimately the the short answer is that you will create an o config. You'll create a config for a given app. Let's say if you want to authorize uh Gmail for your customers. What you will do is you'll come into the composio platform. You'll create an o config for Gmail which will have let's say your uh client client secret because you have a developer app for example let's say you add your developer app to uh compose and then what users can do users can connect your accounts for that developer app. So I'll show you the flow in a very short while. Um but the idea is that rub itself uh like it can't really directly support that multi-level of uh authorization but rub itself is also a product as I said uh so you can deploy it internally in your own uh organization. So I think we're working on that right now working with a few customers to deploy rub internally to their platform and I think if you need more details you'll come to the booth like we'll discuss in more technical details how it works. Uh but like for now I'll just quickly show you like this is the composer platform and what you have is a bunch of toolkits. So you can go to all toolkits. So the name is platform.composer composerdev that's what we usually is uh and you can come here you can say okay these are all the toolkits you have access to a whole bunch of them and like you can have o config so let's say if I want to have gmail if I want to expose gmail to my customers I can just create a add to a project and create an o config and I can choose what scopes to add here so like maybe I won't allow my customers to write to Gmail only read from Gmail for example I can create the oconfig and then I can like connect accounts based on that so is created now I can connect an account here and this will open the whole flow I need to like this is where you can add your user ID for example any number of users Every user will get its own user ID. So J whatever n number of your own user ids for example and then you connect and you can use this from the SDK. So we expose all these functions with the SDK as well. So you can integrate this with your own uh solutions and then this is what user will see ultimately that you want to you can also white label it. You can also add your own name here instead of compos whatever. So that's how the flow works and this group just uses internally in the back end. >> But yeah anything else? Yeah. uh the toolkits which you have here uh are integrating with various applications right so did were the toolkits made as a part of rub or are you getting them from the applications you're integrating with >> oh yeah like I think the toolkits are a part of composers platform already so rub was built after this so the reason we could build rub was because we already had a whole catalog of 600 plus apps that we could build on top of so internally we have like a now an automated pipeline I think we'll that'll be a point of some other talk someday but we have like a internal pipeline where if you just give an app name to integrate with we have a bunch of agents which actually go to the website sign up for that app create credentials and then create the whole app test it and then create a PR out of it so we generate all these apps ourselves like the integration is code that we write for it like say for Gmail we have our own Gmail app internally which is the integration so you have 600 plus integrations we built already and there are customers who use the platform intern already like not just root group is a consumer product which we built just right now because we felt the need of having MC server like that but the tools already existed before that so if you want to use the tools You can also do it through the platform through the SDK, TS SDK, Python SDK. Uh and Rub is just built on top of that. >> Uh so if if I want uh say I have an application which I want someone to use uh Rub with with via the compos your platform, >> I would need to expose a set of actions that you can do on my platform. So is there a standard for that or is that just manually done? >> Oh, you you want to select what actions can a person execute, right? Yeah, you can do that for Can you choose what scope I said you can choose scopes like when I was creating the o config say I can choose what scopes are allowed and based on the scopes you can choose what actions allowed as well what tools to include in the server owner for example so you can choose like okay for a given MC server I only have right tools I only have like a bunch of two tools or maybe only the list tools I can only add those things so you can very very well manually verify sorry configure what tools or what scopes go into your uh end product >> and say something new say a new feature comes in Gmail say there's a new scope or a new set of features >> uh what's like the lead time between that being released in Gmail itself versus it being available on compos. >> Yeah, >> pretty fast. I think depends on how many users ask us based on the priority that's a good question altogether. >> Got it. Thanks. >> But yeah, anything else? We'll just go for >> Yes. >> Yeah. >> 100%. And following to that question is is there any control for RPA in that that you know I want some of the let's say users have the right access to >> yes I think uh to answer your first question yes this definitely possible we do that with all of our corporate clients also we choose their IDP whatever they have using right now uh but for the second question I think we don't really have uh composer level arbback right now maybe like it might be in the works I'm not super sure on that front like I'm not really working on the platform I think struen will be on the booth we should go talk to Sujan he'll tell you exactly how it works. uh but like uh there is possibility like there's arbback at some level because on the app itself you can configure what scopes are allowed but if you're talking about the whole platform level arbback I'm not super sure like what the status is right now but I think like you can control okay for what app what users can use what actions that's something you can definitely do and the IDP stuff is also possible we do that with a lot of customers already I think yeah perfect >> yeah another question >> yeah go >> so so we are handling a lot of credit card >> yes >> composers socks compant. >> Yeah, we sock to compliant. >> Socks complant. Can like can we handle the PCI data also apart from P? >> I'm I'm not sure if Socks compliant like I'm not super clear on that to be honest. I think we'll have a chat at the booth later on. But we do have a lot of corporate clients which are very strict on the data requirements and we work with them already. So I'm pretty sure that's also there but I'm not completely sure. I can't give you a wrong answer. So I think we will talk about the compliances like when you come to the booth I think we'll be happy to do it. Um yeah, go on. >> How do you compare this with MCP gateway? >> With an MCP gateway, I think it's it's in in essence is similar like MCP does the same thing, but I think this is more efficient. This is way faster and it can do things across a bunch of different apps without having to because it's not really MCB servers. Essentially, it's just calling composers tools in the back end as you seen and we also have additional things like context management and memory other stuff as well built on top of it. This is a much better user experience than having like a gateway or something else. But I think like we'll keep the questions going but I think I'll just ask for a use case from a user if you already have some time. So give me give me a use case which you want to execute like what do you usually do? >> One last question on the fier side. Can you show me that thank you slide which you added in the >> Oh yeah actually yeah let's just go to the thank you so I completely forgot about that man. Let's go. Yeah. So let's see. Oh wow. Nothing here. Oh yeah there is a thank you site but it's it did it in like freaking black. But yeah, that's something I have to worry about. Like that's that's my LLM, not the server, unfortunately. Thank you. Yeah, exactly. It's been a great journey. Thank you for being part of it. I mean, yeah, like it works, but like you have to tell it what to write. Exactly. Like it it did its best, man. Like come on. It also had like something here. I'm not sure what it was. Oh, thank you. Perfect. It built it in a way you have to like scratch it like a scratch card to figure out what's going on. But yeah, I think like we'll keep the questions rolling until we have time. But like right now, let's go back to this. Let's play around with it. Like anybody has any anything to give me like whatever across any app like linear, GitHub, whatever. Let's just think of a use case. Let's see what root does. Okay. >> Yeah. Go on. >> I have a GitHub. >> Okay. Go on. >> Say that. >> Okay. >> Explain what the problem is. Okay, I think we can do that. Let's try it out. So, what I'll do is uh let me say uh Okay, cool. I have a GitHub PR called uh com Oh, sorry. Yeah, my bad. My bad. I have a GitHub repository called Composio and just find the latest PR on it and comment what the problem is which the PR is trying to solve. So I want like a detailed analysis of whatever the PR does and add it as a comment to that PR. >> Can you do a specific >> Can you do a specific line? Yeah, I can like a specific comment >> a line on the >> Well, let's try that. Actually, I never never said and make this comment on a specific line in any file of your choosing. I just want to see if you can do that. Cool. I mean like now this will this will Okay, connection failed. You know what I mean? Okay, let's try. So I think like everything is built on top of the tools that we have. So we have like around 800 tools for GitHub. So I'm pretty sure like it'll it'll do some granular stuff there as well. But I think the the the shine like the real value of comes in when you have like cross app execution stuff. So I think I was giving a last talk at hacker rank earlier and there's one of the users told me that okay I want to look at my linear team find all the people there create GitHub issues based on their names and some other repo and then some create a repos. like basically cross application stuff with large context. For example, if you come to the booth, we'll show you demos around let's say look at all of my emails like all of the emails I have in my Gmail and label them based on reasonable categories. So then it reads 10,000 emails. It goes through 10,000 emails and then labels them on the right category and all of that. It's pretty quick as well. It's not doesn't take like forever to do that. So it can handle large context cross application stuff. So I would encourage you to do it like if you do something cool tag composi on Twitter with whatever use case is make a video on top of it I'll be happy to share a happy like feature give you some extra swag if it's really cool because I want to push the boundaries of what roof can do and we are also constantly improving it so that's why we added memory where other things as well because you want to push it to become like a very nice user experience which is why I want people to try it out like make it fail like the more you make it fail the happier I'll be so that's why I'm trying this use case out as well like let's see how it does so let's see how it goes so it finds search tools See I found GitHub whatever it's creating a plan. So for harder task it creates a plan first. Okay I need to do this then that then this and that. So it stays on course and then it's already found the latest pull request in the composer repository I think. Yeah what whatever. So I think it got now at this point it's calling get a pull request. So I think it's get the pull request and now it's analyzing the PR and completing a comprehensive review comment. So it's got to point already. So so it already got the files changed in the PR because it needs to understand what's going on. So it fetched the files in the PR which had diffs and it read those files already. It knows how it's going on. It's analyzing it. It's analyzing the PR to get a comprehensive review and it's already done that like based on analysis this is about updating documentation to produce a new connect link feature for authentication. So we just add this new feature. I think I made the release like an hour back at the booth. So it already found that PR it knows what the PR is about because it read the files and now it'll now create an analysis based on it. I'm not sure what's doing it right now. Maybe the internet is a bit weak right now. I'm not super sure. Yeah, but it's doing it. Hold on. Maybe I'll try again. Yeah, there it go. So now it's calling the remote workbench as I said because it's a more complex query. It needs to perform a bunch of actions. So that's why it'll call the remote workbench. It writes his own code. So this is the code it wants to execute, analyze the PR to understand what problem is solving. And then there's a whole bunch of code, right? It wrote this code by itself to figure out what's going on. and it'll run this code in the remote workbench to figure out something. So perfect. It already did that. So whenever you have a very complex usequery, it calls the APIs, it goes to the codebench, it writes his own code, figures things out and gives you this all that. So it already found it. Insane. Let's go. Let's see. Uh so okay, I need to ask for confirmation before posting the comment as this will be public and visible on the PR. Let me show you what I've done. PR analysis summary. This is the problem which PR solves. So you can see the whole thing. That's actually pretty accurate like this is what I did the last thing. solution was this key changes were this what is the new method what is the dual approach so imagine you can just integate with with your PR so you never have to write PR descriptions anymore you just ask group okay find my latest PR which I wrote like last day and add a PR description to it and it'll do that for sure so that's how powerful it is across any number of apps and whatever you want to do man so key changes development proposed line comment is this this is whatever so yeah yeah XY Z XY Z go on let's go yeah cool so yeah like I'm happy man come Come on, give me more. But yeah, let's see. But yeah, I think I already have Yeah, over time already. So, I think let's just let's just see what it does. And I think we if you want some more fun, let's head over to the booth or like install Rub yourself. Give it a shot. And I would love to see some videos on Twitter for sure. Go on. >> Yeah, I think right now it will show you like it's only 9.8% which is pretty low compared to the stuff it has done already. So, I think it's already done that. Let's quickly see this before we uh Okay, add to line 81. I just Oh, okay. I thought they cut mine out. Yeah. So, there you go. That's what you wanted exactly, right? Like go to some line command. Excellent authentication. That's how it goes. Like, exactly. Insane. Cool. That's that's my time. Uh composio, come out to the booth. Let's try some fun things out. Um happy to help. Thank you so much, guys, for coming.