Cursor Automations Clearly Explained (worth learning?)

Key Takeaways

So, Cursor just dropped something called cursor automations and they claim that this is to build always on agents. And if you go on X, you might see that people are saying that Cursor has built their own open claw. And so, I wanted to make a quick video about all of this because in this space right now, you see a new tool drop or you see a new big announcement and you almost get the sense of panic that you need to go learn that right now. There's so many different tools. There's so many different ways to do things and if you don't know all of them, you feel like you're behind. But in reality, a lot of these tools are doing the same thing. And what's way more important is understanding fundamentals like planning and framing, prompt design, tools in memory, orchestrating, evaluations, QAs, deployment, and safety and guardrails. Because once you understand these concepts really, really well, you can pretty much take those and apply them to different tools and you'll realize that they're very, very similar in the way that they work. And that's why I've really tried to stay consistent on tools and not jumping around because I think the more you jump tools, the more confused you actually end up getting. Okay, so what is cursor automations? It is a new system for trigger-based cloudr run coding agents that can launch automatically on events instead of you manually prompting them. So essentially you can spin up these agents in cursors cloud that will spin up a sandbox and it will just pretty much be way more proactive which is why people are saying it's like openclaw. These triggers could be schedules but they can also be GitHub events. They could be Slack messages. They could be linear issues. They could also be custom web hooks. So when it's triggered, it will basically spin up a sandbox cloud environment for that cursor agent and it will load your repo. It'll look at different tools and it can run the agent workflow. So for example, here's one that looks through my GitHub repo for a news automation. And when it goes off, it basically does code review and security review. And what's really cool about this is I didn't have to do anything besides set up a trigger and then give it a prompt. And then when it's done, as you can see, it can send me a notification and I could also trigger them in Slack. Now, what I think is really important to understand about this is that it is built for a very specific purpose. At least that's my take on it. On their announcement video right here, their very own framing was cursor can now continuously monitor and improve your codebase. Automations run based on triggers and instructions that you define. So, this isn't supposed to be some sort of OpenClaw 2.0 personal workflow assistant operating system. This is just to help your code. If you kind of look at the evolution of AI coding, 2023, AI could help suggest code. 2024 AI could help you write it. 2025 AI could actually write it and ship it on its own. And 2026, maybe we're looking at the system where AI is able to maintain everything and constantly improve improve improve. And it seems like the primary intended use cases are ongoing code review on every push, security and compliance checks on changes, incident response flows off pager duty, scheduled maintenance and reporting, that kind of stuff. Turn your engineering org into a factory of always on agents that own review monitoring and maintenance. What I was interested in and why I wanted to test it out is because if you've built in cloud code, you know that when you build an automation in there, you basically have to trigger it or if you want to host it somewhere so it's proactive or more automated, you have to put that somewhere like trigger.dev. There's some other ways that you could Frankenstein your own solution, but that's just like the theory, right? But in in this cursor automations thing, you literally just click on new automation. You add the trigger. It can be, you know, cron, it can be off GitHub events, it can be on Slack events, linear, paged duty, web hooks, and then you choose what repo it wants to work inside of because these are going to be cloud-based sandboxes that are spun up to work in these directories. And then you just give it a prompt. You can see you can also use different models here. So, codecs, GBT 5.4, which is new, 4.6, Opus, or Sonnet. You have memories that you can add. And then you can also connect different MCP servers and different tools. Once you have one that's active and it's running, you can view the run history. And also, if you want to see while it's actually running, so let me just trigger a test here. While it's running, you can see that and you can actually pretty much watch it run the same way that you watch a cloud code agent run. You can see what it's thinking and you can see what it's doing. So, in this example, it set up its environment. It started thinking and now it's doing different commands. It's going to read through everything and then it's going to actually make some changes for me. And of course, you can figure what you actually want it to be able to do, whether that's just to report or actually make changes. So in this example I have a different branch that it just created which was autoc code review March 6th. All right. So how does this thing differ from openclaw? Well first we have scope and environment. So cursor automations live in a cursor managed cloud sandbox which obviously as you saw are tied to your specific dev tooling and your github repos. It can have access to the outside world and that's all done via mcp tools and anything that you explicitly hook up. Now, with OpenClaw, that's primarily running on your own machine or server. And it has system level access, files, apps, browser, shell, messaging apps, things like that. And this was literally positioned and designed to be a personal assistant across pretty much your entire digital life. And the proactive behavior is interesting because OpenClaw and cursor automations are not agents that are literally just on 24/7 looking at everything, thinking about everything. OpenClaw feels proactive because it has heartbeats and it has crons. So scheduled turns where the agent wakes up, looks at everything it needs to, and then decides what to do next or basically just goes back to sleep until the next heartbeat or cron. And cursor automations are also event driven, triggers in the cloud, it spins up the agents in the sandbox on demand for each job. So open claw is kind of more of like an OS work assistant and cursor automations is your cloudside engineering crew that helps you with your repos and your codebase. Now, how does this differ from cloud code? Well, cursor automations, you have one unified product where you define triggers and you attach agent workflows. Everything runs on cloud with a single, you know, automations UI. All right, so back in here, you can see that that earlier run that I was testing just finished up. But I could also go to my other automations here, and you can see this dashboard. Or I could just do an agent. So right here is more of like a ondemand agent use case. And remember, for each of these agents, when you click in, you have way more of like a cleaner UI where you can see things visually. You can hit run history and you can look at all of these different actual runs. But with cloud code, you're more so just looking at the actual thinking thread and the commands and all your folders over here. And then if you deploy those automations in something like trigger.dev, you would have to go over there to see that dashboard of like what they're actually doing and if they're failing or succeeding. If you want to see a video I did about cloud code and trigger.dev, check it out right up here. So the cloud ecosystem does have similar components, but it's kind of spread. Like for example, co-work has scheduled tasks and those are things that you actually in that interface can schedule except for with co-work the desktop app has to be open. So if your computer's off, those won't run. Then you've obviously got cloud code in the browser or the terminal. But you can do some things with like GitHub actions or slack bots and you can create these event driven kind of clawed workflows. And then you've got things like hooks or the agent SDK, but that requires you to build a lot more of the actual infrastructure and you have to manage a lot more of those settings and you know secrets. So that's why this thing is getting attention because the always on factor, the cloud factor, the ability for things to just be so easy to turn on in a few minutes and they're good to go, which is also another big value prop of something like Nitn because as soon as you're done building your automation, you just turn it on with a little flick of a button. Cloud Co-work, you can schedule these tasks, but you have to have it open. And cloud code, you typically are taking those scripts that you built there and then you're hosting them somewhere else. Now, here's the thing about cursor. The actual like cursor app is kind of just like a forked VS code. So it's basically an IDE and you can use the cloud code extension inside of cursor and I would still use cloud code in order to build these automations because I think that it has the edge on coding and agentic reasoning. But then cursor automations wins because it's easier to just set it and forget it when you need event-driven agents after that. And I know I already briefly covered this, but the myth of thinking that agents are always on like a human. It's really not that way. They basically just have these loops where they wake up, but they can view what they just did and they can view memory decisions, things like that. And the fact that these are being spun up in sandboxes, which means the agent is super powerful inside of this isolated environment. It has specific amount of tools, specific memory and a specific repo that it's working in. But if it's just like completely autonomous across an OS, like maybe something more like OpenClaw, which is why people were literally buying Mac minis just to put their OpenClaw agent on there so that it couldn't hurt anything like real. And another big reason I wanted to make this video is because it's exciting to see where the space is headed. Kind of like this image I had earlier with the evolution of coding with AI year after year. We're moving from kind of just asking a model for help and then doing it ourselves. And now we're getting to the space where it's able to just do it, but also potentially maintain it and optimize it by itself over time and likely do so better than we could. And really just remember to be thinking about what are the skills that I'm learning that will transfer nicely into other tools rather than obsessing over jumping from tool to tool to tool. So the way that I see something like cursor automations and cloud code working together a bit better is something like using cloud code as the builder and then using cursor automations as the caretaker. So cloud code locally designs everything, builds it, tests it, and then once you ship that to GitHub, then cursor can pick it up on top of that and have these autonomous workflows where every day, every week on, you know, a new change, whatever it is, it's doing a security audit, it's reviewing that or doing other things that you needed to do. They could also wake up on certain errors or certain events like that and then take a look and see what's wrong. Now, this also could be done without cursor automations. You could build your own automations to do that. You could use maybe something like GitHub actions. There are other ways, but I'm just trying to think about with this new news, maybe how you could work it into your own workflow. But that's going to do it for today. So, if you enjoyed the video, please give it a like. It helps me out a ton. And I appreciate you guys making it to the end. I'll see you on the next one. Thanks everyone.