Cursor Automations
Cursor Automations run always-on AI agents that proactively monitor, maintain, and improve your codebase.
Terms in this video
Transcript
Awesome. Well, thanks everyone for joining. Today we'll be talking about cursor automations, which is a way to build always-on agents that you can um build into your productive workflows. And today you're joined by me, um John and Joseph. I'm on the growth team, where I work to make sure that every company with software engineers hears about us and uses us. Um John is one of the engineers that actually built automations, and first ever automation
was a actually bug bot that he worked on as well. Um and Joseph is on our field engineering team, so working on giving demos to help share cursor best practices. Um so with that, I will hand it off to Joseph to share a bit more and run a demo. Sounds good. So, um today we're here for automations, and here's kind of one-sentence summary of what I like to talk about automations. It's essentially a cloud agent that runs automatically on a schedule or in response to an event.
So, that's kind of like the textbook definition, as you you can understand. Um of course, um we all learn better by watching someone do something. So, I think I'm going to start sharing my screen and show you guys what I'm trying to build. Are people able to see my screen here? Good. All right. So, I'm going to open up the chat at the same time, too. Uh at any time when people have any questions, go ahead and drop down um in the chat. We'll answer them at the last 10 minutes
of the uh presentation. So, as you guys can see here, this is my screen um in cursor. On the left-hand side, I have all my agent um conversations I can have. On the right-hand side, I have a localhost that's spun up. So, this is my personal repository. Uh it's it's for lookbooks. Uh as you guys know, I'm based in San Francisco, me and Emily. Um people in San Francisco they dress very well. So, I want to also dress well, too. So, this is kind of like a personal inspo of a lookbooks of oh, what can I
dress well of? And as every other engineer, what I do is I track progress in how I can make this lookbook better. So, what I do by that is I have a Jira board. Um you can see a standard Jira board that has to-do, in progress, in review, and done. So, I finished some of the tasks already, and I have some to-dos that's on the side. You can see some of the ones are low-hanging fruit.
You can see this one is like add dark mode to toggle top bar. Um it's quite easy, so in the traditional sense, if I don't have automations, what I would do is I probably copy this Jira or connect it with MCP. In this case, it's faster to just copy it, so I switch back to cursor, and I just uh paste it in, and in agent mode, I say, "Go ahead and implement this for my landing page." And I'll just shoot that in, and uh agent would go ahead and do some um some coding right away. It would go
through my localhost, it would go through the code base, and be able to to add a dark mode and light mode toggle on the top bar, um like probably right here. So, uh let's give it the agent some time to finish, um and then we can talk more um afterwards.
So, we can see that okay, the agent went ahead and one-shotted um it added a button right here. So, if I were to test it out here, indeed, it goes back uh light mode, dark mode. It looks pretty good, right? Um so, if it looks good and I feel like I'm confident enough, I can go ahead and create a PR and set it onto GitHub and then have people to review it and then send it off, right? So, wow, that was actually very tedious for me. What did I just do? Uh let's review.
First, I go to my Jira board. Uh I actually forgot, you see, I already forgot to move this into in progress. You got to move it into in progress. You got to copy like the content of what you want to work on on the issues, paste it into agent, wait for the agent to come back, manually test it, open up PR, have someone review it, and then push it in. Like I I I think I just did like seven steps or something. That's That's crazy, you know? I I don't like that. And it's
such an easy concept, right? It's just adding dark mode and light mode. So, what's one way that we can make this better? We can use automations. Um over here, you can see that we have in progress human. We have another one that's called in progress cursor. Let's go ahead and drag drag and drop this to-do into cursor. Uh what is going to happen here, right? If I go ahead and go to cursor.com/automations, uh reorganize my tab over here. I'm a little neat freak. Um and then you can see this automation called lookbook
lookbook fruit. It stands for a low-hanging fruit. Let me open this up. Go to run history. You'll be able to see immediately there's actually an automation that's running right away. Let's go ahead and open this up and see what's going on here. It's spinning up a cloud agent that's doing the exact same task I just showcased locally, but in cloud in a separate VM.
Um it would automatically spin up a VM within the cursor's environment, go through the um the the Jira ticket to see what's going on, what is a complex task. In this case, it's just a low-hanging fruit. It would do some implementation and come back with us with two things. One is a PR for a diff file for us to review. The other one are artifacts, which are screenshots as well as uh as well as screen recording. Unfortunately here, it's going to take
about 10 minutes for it to complete, so we won't be able to see it. However, I did come in prepared and be able to showcase you guys. I actually did this earlier today. And this is what it came back to me, right? Um you can see that the agent on the right-hand side, it gave us a diff file of everything. Um like, "Okay, you can manually review here." It's quite tedious. Or, the agent actually automatically sends us screenshots and screen recordings. So, this is the dark mode screenshot that it created for me.
Um in this case, I chose composer two for it. Um and it has a screen recording, too. Let me put this on 2x speed here. It goes to the localhost that it spun up, plays around with the toggle button, indeed showed me that, "Hey, it's dark mode and light mode." So, that way, uh if it looks good to me, hey, I can just mark it as ready. Um let me go ahead and do that.
And with that, it would open up PR um for me to review and be ready to to to merge it into main line. So, that streamlined the entire process here. Um to look a little deeper underneath the hood to see, "Hey, what does automations look like?" Let's actually go back to our automations tab here. Uh instead of run history, let's look at the setting. Underneath the hood, automation really is just three things. One is a trigger. Two is an instruction. And the third one
is tools, which are actions that you connect it with. So, in the trigger, in this demo that we did, it triggers via a webhook via Jira's board. So, whenever I moved from uh a ticket into the AI uh um in progress cursor, then it triggers an automation. What does it do, right? It has some instructions. It goes ahead and say, "Hey, go extract the content of the Jira ticket. Uh these are all the steps that I would have done manually, but I put it into an
instruction in the cloud, so then every time when I put some tickets into that Jira column, it goes ahead and triggers it." And the third fold that you want in the automation is the tools that you you you give the agent uh to use. So, some of the good things I did was, "Once you're done, you always have to Slack me, too, because uh asynchronous workflows sometimes they work 8 minutes, sometimes they work 13 minutes. I don't really know, but I want to get
notification by it, so send me a Slack message once you're done." And I can confirm I got the Slack message. Um and then um you open up a pull request, that's also an action that you want to do, and I connect it with Atlassian, which is uh the company that owns Jira. Um so, then it can do some um additional actions that's on top of it. And in this case, uh you'll be able to choose different models. Um in uh for this demo, I chose 5.3 extra high fast. You guys can go ahead and choose composer two. Uh composer two
is one of the latest models that's dropped by cursor. Um it's extremely efficient. It's the intelligence model of near frontier uh lab, but it's a tenth of the cost. So, highly recommend everyone to go try it out. So, that's one strong feature that you guys can do with automations. And what showcases automation even more is its asynchronous workflow and parallelizable task. So, what does that mean? Let's go back to the Let's go back to our Jira board here. You can see that I have I have seven to-dos, right? A bunch of
them. Some of them are bug fixes, some of them are low-hanging fruits. I know that these low-hanging fruits could be one-shotted by the agent. What do I do? I just simply drag it into cursor and say, "Hey, let's let's drag all of them, right? Let's Let's see what happens."
Drag four of them into it, right? Let's Let's go back to our cursor automation. Look at run history. And you'll be able to see that another four of them went ahead and spun up and went ahead and start start pushing out some code and doing some implementations. And once they're done, as I said earlier, you'll be able to see the diff file as well as artifacts like screen recordings as well as screenshots. And once you're ready, just push a PR and you'll be able to see all the PRs that that it had opened earlier.
Um all these PRs, LB1, LB2, LB3. These are the keys that it defined. And if you're ready, just merge all of them then. Um so that's one of the power of automations. And internally, we realized that this is we reach quite we work with multiple enterprise companies and lots of them have been creating a lot of very useful automations and I want to showcase one specific automation for everyone to set up with me today that's on the call. So let's go ahead and do that. Um what you can do is you can go to cursor.com
/ um h agents. Um on the left-hand side, it has automations. Let's go ahead and click that. Or in the shortcut, you can type cursor.com / automations. Um and from here, you'll be able to do two ways of creating automation. One is you can speak to it in natural language form to say, "Hey, um help me create a daily digest of my repository." And you can send that off and then it would give you a scaffolding of how like a template of what what you would like
to set up for your automations. Um or you can click on new button over here. This was This would take you to a new automation tab in order for you to set things up. This is a demo that I showcased earlier. Or one thing that I like to use a lot is these templates that cursor team provides. There's lots of very nice and juicy resources over here. You have find vulnerabilities, assign PR reviewers is one of my favorites because a lot of times when I push out PR, I'm
like, "Who should Who should review this, right?" And this automation would help you do that. Find the correct person to do to so. Um and one thing I know John's favorite is CI failure. And also, I believe there's one for PagerDuty as well. So a little background of myself, I came from Amazon. I wake up at 3:00 4:00 a.m. every day.
And with page page PagerDuty, you'll be able to set it and configured so that when you get page, the the automation workflow is able to do some investigation for you overhead. Or if you classified the severity to be, "Hey, it's a low severity." You can actually go ahead and implement a fix right away.
So when you roll out of bed and then you open up your laptop, it already has a has a fix for you. That's like a dream come true for all the on-call people out there. So that's something that's very fun. Let's actually go ahead and do a walk-along. And let's let's let's do this automation setup together.
So internally, I had our data science team to pull what is the most sticky automation feature that's the most useful and most beneficial. We actually only we we reached 89% retention in the last month for this automation. It's summarize changes daily. Everyone who's on the call, go to cursor.com / automations.
Click and then right here in this UI, go to summarize changes daily. You'll be able to see that, "Hey, this posts a daily slack slack digest of summarizing notable repository and changes that happened in the previous day." That's super helpful because our engineers are cracked. They dev every single day, every single night, every waking moment.
And it's very hard to keep track. And this automation helps a lot. So every day at 10:00 10:00 10:00 at 10:00 a.m. PST, it goes ahead and create a daily engineering digest. It already has a pre-written prompt for me and it uses a tool of send Slack channel. Let's go ahead and hit start building here.
And with this, you'll be able to select which repository that you want. In this case, I'm just going to choose a random one. I'm just going to choose my lookbook one. I named it Joe. And you choose a a branch that you want to use. In this case, I'm going to choose main. Um that's the trigger part of the automation. And in the instruction, I think the instruction is already pretty good. It's it's a template that we we wrote in the cursor team. If you want to tailor it to your own repository, um say if a
certain branch is more likely to have more documentation and certain agent.md file or .cursor file, you should go ahead and put that into the instruction for the agent to look more deeply into it. Um and you can choose a choose a model that you want to use. I think I'm going to use composer two over here. Um the tool is uh um is default to Slack channels that we added for you already.
You can choose a channel that you want or you can DM it to yourself. I think I'm going to do that. Um so then it's it's it's giving it to my own. It would arrive to my own DM. And from there, you'll be able to just hit create. And just like that, your summarized changes daily I'll probably change this to summarized changes daily to Joe repo. And just like that, you'll be able you have your automation set up. And every day at 10:00 a.m., it would give me some
notable insights of how the repository changes. So that's that's something to showcase here. Um and I think I I reached to the end of my demo. Maybe we can move on now. Awesome. John, we have a few questions for you given you've built this right though and people are probably super curious.
Um I guess to start, maybe how did we think about automations as a feature and why did we decide to build it out? Yeah. So it's kind of an organic thing where we think about what we would want to do work better and faster and this just kind of was a natural evolution of cloud agents. So we already have been using cloud agents for a really long time. I think about 30 or 40% of the PRs that we merge as an engineering team comes straight from Slack where someone will
post a bug and we'll just say, "@cursor fix it." It'll come in. It'll have a video of the fix. We'll review the PR and click merge. And then we thought, "Okay, why do we even need to say @cursor fix it? Why can't we just anytime anyone post a bug in our bug channel, why can't we just automatically have an agent kick off and then just have a fix there ready for you to go?" And so that's kind of the thinking that sparked it. And once we started building it, we started seeing all of these
different use cases that people started building. For example, we have one automation that will trigger is PR is opened. And what it will do is it will look at the PR and it'll determine if it's low risk, then it'll approve it. Or if it's high risk, it'll assign reviewers to it. And it'll find the right reviewers using Git blame. This is saving us like a lot of time on PR review. It's it's helping us with like not having to deal with code owners and things like that. Um we have other automations that just,
you know, PagerDuty triage. Whenever someone gets paged for an incident and they're waking up at 3:00 a.m. all delirious opening up their laptop, instead of having to figure out what's going on and navigate DataDog, the agent has already done that. And you just wake up and there's like a root cause for you and a PR ready to merge. So it's kind of all these magical use cases that we just started seeing form and we thought, "All right, we really need this." Also, I'm seeing a ton of questions
coming in. Would it make sense for me to just kind of rapid-fire answer those? Um I think we have three questions prepared and then let's rapid-fire those afterwards. So as long as you send them, we'll try to get send them in Q&A, we'll get to them. I guess what's the most creative use case you've seen of folks using automations?
Oh, wow, that's a really good question. Um Oh, I kind of wish you sent me these in advance to prepare. I'm on the spot. The most creative use case that I have seen Um I would say >> the most genuine response from you, so that's that's good. Yeah, yeah. I would say the most creative use case is Nathan's supervisors. So we have somebody here who's a manager and started setting up a supervisor for to monitor CI, a supervisor to monitor like daily changes to the repo, supervisor to manage like who's reviewing PRs. So he
has all these different supervisors and they all post to their own channels on Slack like CI supervisor, PR supervisor, whatever. So he made an automation called supervisor of supervisors that looks at all of the supervisor channels and summarizes them into a channel called supervisor of supervisors.
Um, I would say that's the most creative use case. Nice. Um, and I guess what are some future developments or improvements that you're most excited about? Yeah, totally. So, um, it it it's working really beautifully for us and we're really excited about it, but some things that we're really excited to add are more first-party triggers. Um, some people have been asking in the chat here about Microsoft Teams and Jira. Uh, yes, those are coming. Um, but in the meantime, you can always use the webhook trigger and set
up like a workflow in those tools to send us a webhook and and it should work just fine. We are also excited about uh, opening up more capabilities like uh, Joseph demoed the artifacts like the videos and and the images. Right now, there is sometimes it works with automation, sometimes it doesn't, so we're working on like solidifying all of that.
Um, we are also going to be implementing um, more uh, more tools like the ability to add labels to your PRs and things like that. Um, oh, and then uh, yeah, someone else asked about this. We uh, would like the idea to have more of like a meta agent kind of thing. Uh, I can't give any ETA on this, but being able to set up kind of more uh, combining deterministic workflows with LLM workflows and maybe being able to delegate tasks to different kinds of
sub-agents. Uh, something like that is very exciting to us as well. That's awesome. Um, and then I think Joseph said 10 minutes for cloud agents to finish. Have How I guess do we think about shipping rate given that maybe cloud agents take a bit longer than the local agents? Um, why not just spam a bunch of them locally on your computer rather than having automations run?
Yeah, so uh, first of all, we're working on improving the startup time of cloud agents. Um, before the cloud agent launched, the big thing was like reliability and now that we've really nailed that, our next big focus is latency. But because these are automations, because they're automatic, you don't need to be watching them, you don't need to be manually triggering them, they just kind of run in the background and tell you when they're done, we think that the the
latency isn't too bad. Um, but yeah, that being said, we do want to speed it up. Mhm. >> [clears throat] >> Also, when you were asking about uh, future plans, there's two really big things that I forgot. Um, multi-repo. Yes, a lot of people here are asking about that. Multi-repo is currently not supported by cloud agents at all and so therefore not supported by automations, but we're working on that. Um, alongside multi-repo, we're going to have the
ability to do multi-PR, so a single cloud agent will be able to open multiple PRs instead of being tied one-to-one. And someone asked about this, why do you need to set a repo for an automation if it's not doing anything with your code? For example, it's just reading Slack or something like that. And the answer is just because that's currently a limitation of cloud agents, but we are also working on removing that limitation. Um, but yeah, if your automation doesn't do anything with the
repo, just pick a random repo. It'll it'll work just fine. Awesome. And then can do can you do a trigger for GitHub issues? Uh, GitHub issues. Um, there's no first-party trigger for that, but if you set up a webhook trigger, then you can just I don't know if GitHub has a built-in workflow or that'll fire a webhook or you can like build something on top, but you can always use a webhook trigger for any custom triggers like that. Mhm. And then how do we handle the bottleneck
of code reviews? I think we've done a bunch of very interesting stuff internally to ship fast without being bottlenecked, so would love to hear about that. >> Yeah, well, so the first bottleneck came out about a year ago when we were all writing a lot more agent-generated code and suddenly the number of PRs increases. And so that's when we built BugBot to serve us this like code review agent that never sleeps that can do all of the code review for us. And we kind of fully rely on BugBot as
our code review process. And then we've introduced this new layer with automations that's not BugBot, but it it's like this new thing where we have kind of different people making different automations for different things. So, our security team has like four different automations, some of them review PRs for like specific security vulnerabilities and message them, various things like that. We also have that automation I talked about earlier where if it determines a PR is very low risk, it just approves it right away.
And if it determines it's high risk, it will use Git blame to find the right reviewers and then assign them to the PR. So, just kind of all of these things together can reduce our uh, our lag time. Mhm. And do all automations require Slack as the notification? Um, and do we have any plans for new ones coming soon? Saw a lot of people ask about email. No, yeah, uh, they don't require Slack.
Um, Slack is just a very common workflow, so you can have an automation that's triggered by Slack or an automation that messages you on Slack when it's done or a combination of both. Um, we really just want to let the agent run free, so you can really just prompt it to do whatever you want. The only limitation is the tools that it has available. And so we have those first-party tools for like Slack messaging, but you can also just use MCP. Like you can connect Slack MCP, uh, in which case the agent will act as you
instead of cursor agents. Or you can connect whatever MCP you want to send emails or you can write your own MCP. And MCP is really just a server that has functions that the agent can use. So, if you want to write yourself a function that like sends you an email, you can create a little MCP, you can add it and you can just give that to your to your automations.
Mhm. And are we ever thinking about doing automations locally? Yes, I believe there is work involved in that. Um, I believe we have a very exciting launch coming today or or soon. I don't know, don't quote me on that. Uh, but it will be a new uh, big update to uh, cursor and we're planning to implement local automations to to some extent there. The thing is, local automations are very limited. Like you have to have the editor open, your machine has to be running. Um, it's
harder to do things like GitHub triggers. You're kind of limited to maybe only cron triggers and maybe some other things like that. So, we see local automations as like useful, but significantly less powerful than cloud automations. Mhm. And any advice for tailoring automations with large mono repos? Um, kind of specifying different service paths, different submodules and so forth.
I would say it's no different from anything else. Um, if you find it not working well, just tweak your prompt. Like prompting always requires some rounds of iteration. For every automation we have, we've always, you know, we start it with this, we see it's doing this weird thing, we edit the prompt so it doesn't do that weird thing. You just kind of got to iterate, but I would say that's it. And with that in mind, do you typically build or test out local agents until you realize it's a repetitive workflow and
then build an automation? How was the process? Kind of, yeah. Sometimes uh, so I recently had an interesting thing happening where ever since we've launched the automations, every day I've been posting an update in our Slack channel for like automations usage, how many people are using it, how many runs are happening every day, what's the current revenue of it, things like that. Uh, and I've been doing that for like a few weeks and then someone was like, John, why don't you just make an
automation for this? And I was like, oh my god, I can't believe I didn't think about that. So, yeah, now we just have an automation, it runs every day, it uses the Hex MCP to query all of our data and it just posts it in Slack. Uh, so sometimes I have a blind spot and I like don't realize it, but there's so many things that we just do every day that can just easily be automated.
And how are cursor automations different from Open Claw? Tricky question. Uh, that is a good question. Um, I am not the best person to answer this mostly because I don't know much about Open Claw. Like I've seen a lot of the conversation around it. My understanding is it runs on a on your machine, so you need to be having you need to like have a computer open.
And I don't know all of the capabilities it has. I can only speak to the capabilities of cursor automations. And so we have all of these different cool things with with cloud where we create artifacts for you that show you all of your videos, where our agent has all of these tools to navigate your repo, where we have all these optimizations to improve startup time, although that's still a work in progress and maybe Open Claw is faster cuz it's running on a
machine for you, but basically like the cloud opens up all of these different possibilities. It lets you access your agents kind of anywhere in the cursor ecosystem. It gives you access to all of cursor's tools, our harness, which is the best harness available for coding with agents, just kind of all of these superpowers that we just have bundled up for you.
Mhm. I can chime in on that question as well. Um, I guess I get that I get that question all the call all the time during customer calls. Um, Open Claw is kind of like here are all the components, here are some RAM, here are some CPU, go ahead and build your own PC.
And whereas automations is more like uh, Cursor gives you like a MacBook that's everything's already inbuilt. Uh, everything's more secure, so then uh, you can go ahead and run this product right away and configure it in however uh, however way you want. And in an enterprise price setting is very important because um, you won't have as much of a security risk.
Mhm. And then in the on-call case where the agent proposes a fix, puts up a PR, how do you like prevent it from being incorrect and making the situation worse? Um, how do we think about human validation there? Yeah, so we we don't let any agents from automations merge directly to your repo. It's always a PR that a human will review, hopefully. I mean, that's up to you at that point. Like once a PR is put up, it's kind of out of our hands. If if you merge something that causes a big
bug, that's on you. Um, we give you all of these different tools. Like the agent will propose a fix and the agent is very smart and the agent will test things for you and then you can have BugBot to test even further, you can have your own automations to validate things even further, but ultimately the person clicking merge is you and you are responsible for whatever you merge into your code base. Yeah, and we internally have an automation that rates the severity of the um, change the PR. So,
if it's low, medium, high, the high ones require human PR review. The low one, if I'm just changing the title, um, you can kind of merge, so I know that's something we also do internally. Yeah. Um, I guess if you're think talking to a net new team thinking about adopting automations, what would you tell them? Maybe what are the first use cases to start? Um, and how would you recommend them to get started? Yeah. Yeah, mean, not only does it save everyone time. Like I'm saving at least 30 minutes a day, maybe an hour
a day from automations. So, just from that I mean, it I don't know how to describe this. Like the automation costs like a tiny, tiny, tiny, tiny, tiny fraction of what it costs to hire an engineer, but it can make them 10 to 20% more effective. So, I would say like that's a clear win there. But not only on time savings, it also uh improves things. So, for example, the PagerDuty uh example, by the time I've opened my laptop and even started to navigate what the sev is, the description is already there, and
there's a PR ready to go. So, this like saves on incident response time by like 30 minutes. So, if you have an outage, and your company is losing millions of dollars of revenue, uh every minute matters, automations can just speed that up and save that. We also have an automation that fixes CI for us, for example. We have a first-party trigger, whenever CI is broken, automation fixes that. Boom, all your developers are unblocked right away. So, I would say it's like it's huge because it saves your
developers time. It's also huge because it protects your code base, it saves you incidents faster, it just kind of keeps you in a clean state. When AI was first kind of taking off for coding, everyone imagined this future where we're managing agents, and agents are just kind of actively uh passively watching and making sure everything is is safe and good to go. That's really what automations is enabling. This is really that next step forward into that
future. Mhm. Didn't want to touch on like privacy mode. So, cloud agents respect the same privacy mode as your user account. So, if it's enabled, none of the code will be used for training. It doesn't work with legacy privacy mode, so we do need to be able to store your code base um in the cloud for the duration of the agent run, so I did want to call that out uh since I saw a few questions on it.
Yeah, we're very careful about respecting privacy mode. The reason it doesn't work for legacy privacy mode is not because we don't want to support that, it's because legacy privacy mode says we will not store any code, and the cloud agents need to store code uh for the VM's life cycle, so um if you're still on that privacy mode, which I think is very, very old, you'll need to switch off.
And does the automation look at screenshots, zip files, Jira comments, or only what's in the description? And like probably extrapolating that question to Slack threads as well. Yeah, so that's a really good question. Um right now, uh Joseph, I think you did a webhook for the Jira one, is that right? Yeah, that's right. I did a webhook one. So, we're going to add first-party Jira support, and uh which will enable, you know, some more functionality. Right now with the webhook, you can include whatever you
want in the webhook payload. So, I'm sure that when Joseph set this up, he probably included the title, the description, you know, the the spaces in, all these things. Regarding the screenshots, I think if you set up the Atlassian MCP, it can probably access the screenshots there.
Basically, automations are fully extensible. You can either use the the the first-party triggers and the first-party tools we give you, or you can use a webhook trigger and any MCP you want. And and you can just do literally anything. So, like if you want it to be able to access uh images from Jira, use the Atlassian MCP, I'm sure it can access images from Jira. One thing we do is we have an automation um anytime anyone posts a bug in a bug report channel, an automation will use the Linear MCP to see if that bug has
already been posted, and then if not, it'll create a Linear ticket. So, you're just really leveraging MCP to just let agents do anything. For the PR approver one, we have it use the Notion MCP to write into this Notion table every uh PR it does and like the action it takes, so that we can like human review it later.
Like anything you want to do, all these questions about like can automations do this, can automations do that, the answer is always yes. There's literally nothing they can't do. The only thing might be you might need to find the right MCP, maybe an MCP doesn't support it, so you need to build something.
There might be some like missing puzzle pieces here and there, but it can do literally anything. Well, I think folks are getting excited now. There's lots of questions about security. Um I guess I Joseph, this one I'll give it to you, but I guess what's the best way to build architectural guardrails into the process? Um maybe one, what have we done in place already built in in terms of security? And then two, what can other enterprise users build on top of it to protect their code base?
Is this one for me? Or is it for John? You can start, and then John can follow up. Yeah, I think um in in this case with automations, it's it's quite well for enterprise settings. Uh reason why is because um we have a zero data retention policy for all the LM models that we pass into. Um and also within um our own VM, we also pass through a lot of uh SOC 2 um um compliances. Um if you go to um compliances. Um if you go to trust.cursor.com, you can find more about it. I can post uh post all the resources there. Um and
lots of lots of um big companies, they are have already enabled cloud agents as well as automations within Cursor because they trust uh we've been through uh lots of compliances uh review as well as security team reviews who go back and forth. Sometimes it's over months of review to make sure that we're um uh within compliance with the enterprise company. Um yes.
Yeah. Yeah, basically uh cloud agents, I would say, you know, very secure, of course. Uh we we do a lot of work to make sure that, you know, your your code is very secure, never leaves the US, like whatever, all of these things. I don't work on security. I just know that they worked really hard on this. Um for automations, I would say the security story doesn't change very much. The only kind of new attack vector with automations is that you can set up an
automation that then other people trigger, but you as the person setting that up are like responsible for that. So, you know, if you set up an automation that's triggered by anyone in a Slack channel, and you have people in your Slack channel who shouldn't be able to access your code, you know, you you should think through those cases uh to make sure that you are like being responsible. Um but, you know, generally if you're working at a company, your Slack is for that company, those things kind of map one to one,
just kind of use your best judgment there. Mhm. And building on that, like we have hooks that are enabled where you can actually have it run before any agent changes um and enforces so you're not like sending private keys and so forth. Um when we're setting up system integrations, we have some that are read-only, for example, and so if you're querying the database, we have a read-only SQL um Databricks connection, so that way it can fetch data, but you won't actually drop
production tables. Um so, changes like that you can also build in. Um and then if you haven't heard, but we also have support skills, rules, commands. Um all of that is also supported in cloud agents. And so, you can kind of codify a lot of your code base best practices. Um so, maybe you have an always-on rule that provides high-level architecture guidelines. Um we have stuff that says don't add AI slob comments that I always have. Um we have security rules that are
applied um and so forth. And so, you can kind of customize based on your standards. And you can also use these rules. I know we had questions about multi-repo. If you all um we internally have it like, "Hey, when the agent is triggered, if you're making kind of changes to the marketing site, call this repo. If you're making changes to our deployment pipeline, call this repo." Um and that kind of also streamlines the process.
And then I think one for you, John. How do you see automations evolving over the next 3, 6, 12 months? I know we don't think about Cursor in more than a couple days in the future, but what would you predict? Yeah, I mean, this landscape is changing so much. Uh over the next 12 months, I have no idea. Over the next 3 months, we hope to support more integrations, make things easier, make things faster, make things, you know, fully smooth and reliable. Over the next 6 months, I could see us building some
kind of more meta agent flows, you know, more complicated workflow capabilities for more advanced power users. Um we also our automations have a memory tool where the agent can write to a file system that future runs of that same automation will have. And it's very useful if you prompt it to use it however you want. For example, you know, if you make a code change that was very difficult to find, write something in the memory tool, or you can use it as a
locking mechanism. So, when CI is broken, if 20 agents kick off, you can basically prompt it to like write a memory file when you're working on this CI problem, and then if the memory file already exists, abort early. Um but right now, you kind of have to prompt it to use it however you want. I could see us trying to find ways to make memory more useful out of the box. Um that's something agents kind of struggle with right now, but I'm I'm excited about.
And then what I guess code base tools are do we integrate with? I know we have GitHub support, but folks are curious. Do we Can you share all the integrations and all the ones coming soon? Yeah, um there's GitHub, there's also GitLab. Um there is Slack triggers. Um So, okay, the GitHub GitHub GitHub and GitLab triggers are basically like anytime a PR is opened, the PR is pushed to, a PR is commented on, uh etc. Um I think there's also just a Git one
where anytime your remote repo has a push, which should work for any, I think, providers, but I I'm not too I'm not too confident on that. Uh we also have Slack. Uh the Slack triggers are new message in channel and channel created. And you can filter all of these, by the way, with like allow lists. So, for example, you could have it only run on PRs from certain people, or you could have it only triggered on Slack messages in certain channels with
certain keywords or certain regex matches. We give you some like customizability there. We also have Linear triggers. Linear is a task management tool like Jira. Jira will be coming soon. Uh but we have Linear triggers, so so like on issue created, on issue updated, etc. And we have PagerDuty, which is like, I think most companies use PagerDuty to like get paged of incidents. Um that's the one that just automatically kicks off to like resolve our incidents. And then we have webhook triggers. And this is any
webhook. You can set this up however you want. Like Slack has workflows that will send a webhook. You could write your own script, your own server that sends a webhook with whatever logic you want. You could just send a webhook to our endpoint with whatever payload you want, and the automation will run. So, that's what we currently have. So, what's coming soon is Jira, Microsoft Teams, and maybe Sentry.
And then I'm seeing a lot of people like ask about best practices for reviewing code by these um automations. I think one meta-level question is like, do we review AI-generated code the same way we treat human generated code? Should there be any differences in how they're treated?
And over Yeah, I think that's passed off to Yeah, I mean you're going to get different answers based on who you ask for this and I would say you should really feel this out within your organization. Like I think different orgs will have different flows here. Personally, I think human code and AI code both need to be reviewed. AI code tends to be more verbose. It tends to be more technically correct, but everything comes down to your prompting. Like the model will listen to what you tell it to
do and it'll probably do it really well, but it might miss some things and it might be a little too literal. It might not have your exact kind of schema in mind. So I mean for review, I would always say you need BugBot. BugBot catches things that no human would ever catch from my experience and it works as like this perfect safety layer. I would also say you should be reviewing your own code with your own prompts for specific things. So whenever I'm working
on a new feature, I always, you know, say, "Is this code regressing anything outside the feature flag?" And I'll kick that off with Opus or GPT-4 or Composer 2. Or I'll say, "You know, make sure this isn't regressing like this specific feature." For specific questions like that, LLMs will always answer like pretty accurately.
I know we have a minute left. I did want to quickly share my screen and show you one of my favorite features, which is our docs are searchable. And so if you kind of go on the right hand side, you can actually ask any questions about our docs, about BugBot, you can ask about automations. Um so if you have further questions after the session that we didn't get to, highly recommend checking out the docs for that. Well, with that you so much. Yeah.
Awesome and we'll send out the recording afterwards. Have a good one all. Bye-bye.