I Tested 3 Ways to Deploy Claude Agents (Here's When to Use Each)

If you've been using Cloud for a while, you've probably built a lot of skills and a lot of agents. So today, I'm going to talk about three different simple ways to actually deploy those agents so that they run while you sleep. So I don't want to waste any time. Let's just get straight into today's video. Okay, so before we get into the different methods, let me just paint you a picture here. There's kind of two different things that we're going to be looking at because the different ways that you deploy your agents have different pros and cons. So here's kind of like the slider we're looking at. The first thing is where does it actually run? Does this run on your machine and is it dependent on your machine staying on or is it running somewhere on the cloud whether that's like Anthropics cloud or your own sort of cloud environment modal trigger VPS whatever it may be and then on the vertical here we basically have how deterministic is this thing is this the full agentic autonomous agent loop or is this more of a script that just runs basically the same way every time and there's not like that autonomous decision-making magic agent. So, as I'm breaking down these different methods, I will explain based on this method, where does it sit on the scale? Because the truth is, there's not one best way to deploy an automation. It depends on the type of automation. So, here is kind of a quick breakdown that we're going to be coming back to throughout the video. So, don't feel like you need to absorb all of this right now, but for each of these methods, we're going to be looking at where it actually runs. We're going to be looking at the WAT framework that I've talked about. So, workflow, agent, tools, and what's actually getting deployed and what's not. We'll be looking at if your computer needs to be on and if your session needs to be on. So, I will break all of this down. It's going to be super super simple. Okay, so method number one is just setting up a loop, which I think is a super cool way to just like very quickly deploy an automation. Basically, the idea is you ask Claude Code to run a loop and do X, Y, and Z in the loop. So, basically, it'll fire off every 10 minutes or so. It'll run the skill, it'll run the automation, execute what it needs to, and then it will stop. And then in 10 more minutes, it will just fire up again, and it will loop through that process until you either tell it to stop or it's hit its limit. So, how does this actually work under the hood? Cloud code has three different tools for this sort of thing, which is called cron create, cron list, and cron delete. And if you've ever heard me or other people in the AI space say cron, that just basically means a scheduled task. A cron is like what time it fires off at. So, saying that you're going to set up a cron is basically like I'm just going to set up a scheduled automation. And theuler is actually internal to the cloud code process. And what's really cool is that all of these crons that you might set up or these loops are session scoped. So if you're working in five different sessions, you know, five different terminals or five different tabs in your desktop app, then each one of those individual sessions can have their own loops and they don't interfere with each other, unless they're all like writing to the same file or something, which in that case they would, but they're session scoped. So you can run these in the cloud desktop app or in the terminal, which is pretty cool. The terminal does give you a few extra things for some reason which I will explain. But for now, let me just show you how easy this is because you don't actually have to remember syntax of like how you do like a sloop and how you, you know, explain how this works. You can see you can obviously do the sloop and then tell it to do something every 10 minutes or so. Or you can just use natural language. So I can say, hey, can you just go ahead and set up a loop for every 10 minutes to remind me to take out the trash. So I shoot that off. And now you can see it's going to use a specific tool and a specific skill in order to set up that loop. And right now I'm showing the desktop app. Like I said, I will bounce over to the terminal in just a sec. You can see that it just ran a skill called /loop. And now it's using its tool search. And it's going to have to use the tool that we talked about which was called croncreate. As you can see right there and this is basically just like cron syntax. And you don't have to understand how to read it because it will explain it to you in natural language. Now, what's kind of cool about this and interesting is that when you create a cron and you say every 10 minutes, that doesn't mean the first one's going to be 10 minutes from now. Right here, you can see at the bottom, it actually tells you in the desktop app how many seconds are left until your next cron. And you can see that it says every 10 minutes, next in 1 minute, ends in 3 days. So, when you set up a loop, you're basically going to be limited to how long they run, which is 3 days in the desktop app. And it does this because it doesn't want to have everyone running acron every 10 minutes on, you know, like 1050, 11, 11:10, 11:20 because then, you know, their API would get throttled. So, it kind of does like this random jitter thing, which I'll talk about in just a sec. So, anyways, that's how easy it is to use on the desktop app. And then if you wanted to stop it, you could just come in here and say kill that loop and it will go ahead and use the cron delete and kill it. Or you could obviously just like open up this tab and just like close the session. Now, what's interesting is in the desktop app, if you were running a loop every five minutes or so and you clear your chat, it will kill that cron. But what's cool is that in the terminal, it doesn't actually do that. So, here's an example that I just worked on to show you guys. I said, "Set up a loop every minute to remind me to take out the trash." It creates this cron job, right? And then it fires it. And then what I did is a slashcle. And then after I cleared the session, I said, "Do you have any crons in this session?" And it used its cron list tool to take a look. and it said yes, I still have the once a minute remind me to take out the trash. So that's cool. You can basically in the terminal clear sessions if your context is starting to fill up and your crons are still alive as long as you don't actually terminate that session. And then the next thing is that I wanted to set up a loop every 5 minutes that will run the /clear command because if you have a loop running every 10 minutes and it's processing skills and looking at data, then your context window is going to slowly fill up and you're going to hit context rot. So, it would be nice to set up another cron. And in this case, I said every five minutes, but it's going to run the slashclear command. And it's interesting because claude code actually doesn't think that's going to work, but it does. I basically tried it. I set one up where I inject just the word /cle, and it actually treated it like a clear command. Right here was the actual cron firing off. And then after it cleared it, once again, I said, "What crons do you have?" And it found both of them still alive. So that is why whenever I'm really going to use loops, I'm using it in the terminal because you get functionality like this, which you don't get in the desktop app for some reason. And another interesting thing is that these crons or these loops are supposed to actually run for 7 days. And right now in the desktop app, you could see that it said three. Now maybe if I relaunched and I updated that would update and now we would see that these live for seven days. But typically when you're using the terminal, you just get more functionality. And then real quick, that jitter thing that I was talking about to avoid every session hitting the API at the same exact moment, the recurring tasks fire up to 30 minutes after the scheduled time. So if you want something to run like at 9:17 and 9:27 exactly, it might not do it because of this whole jitter thing, but it would still set up an interval to run like every 10 minutes. So one example that I was using this for is when I first started doing the Nate's AI agent responding to comments on my YouTube videos. I would just upload a video and then I would go into cloud code and say, "Hey, set up a loop for every 10 minutes to read the comments on my new upload and respond to them using the transcript and, you know, point them in the right directions." And so that was me just setting up a loop. I could even say, "Set up a loop to do that for every 10 minutes and then automatically kill the loop after 24 hours and it would do that." Okay, anyways, real quick, pros and cons. The first pro is that this is zero setup. You literally just say set up a loop and it runs. You get the full agentic loop because all this is doing is working inside of your session. So all your skills, all your files, anything that you do normally when you're doing your knowledge work in cloud code, you get access to. You can even do a loop that runs skills explicitly. You can make it shut itself down after certain amount of iterations. And you can run the slash commands directly like you guys just saw me do with the /clear loop. Now some cons. The session has to stay open obviously. So if you close out of that terminal session, the loop dies. Your machine has to stay on. So if your computer turns off, the loop also turns off. You've got a 7-day expiry and then the whole fixed interval thing that we talked about and then of course the different nuance there with desktop app versus terminal. So that was loop. This is basically what we're seeing. Your machine is where it lives. You get the workflow, you get the agent, and you get the tools. And one quick thing to clear up is with this WAT framework. People have been asking me like, okay, well, where do skills live in there? Well, skills are basically the W and the T because sometimes you have a skill that's just a W, right? Sometimes your skill is just here's how I write a LinkedIn post. And that's just a workflow. But sometimes you have a skill where it's like, okay, here's how I write a LinkedIn post and generate the infographics. And in that generate infographics section of the workflow or the skill, you're probably pointing to this image generator and this API, and you're combining those together, the tools with the workflow is a skill. Anyways, you're getting all three of those elements, WAT. Your computer has to say on and your session has to say open as well. Real quick, guys, I know we're about to cover a ton of information in this one. So, I have broke all of this down into a very simple resource guide, which you can access for completely free. The link for that is down in the description. All you have to do is join my free school community. And once you get in there, click on classroom and go to all YouTube resources and you'll be able to find everything in there. So, if you want to grab that resource guide, completely free, head over there. But anyways, let's get back to the video. Thanks, guys. All right, so now let's move on to this next one, which is desktop scheduled tasks and cloud routines. And the reason I put them together in one bucket is because if you open up your cloud desktop app and you go to routines, you can see right here that you can create different routines. And in here, you can either have local or remote. So they work very, very similarly, but there's one main difference. And that is what I'm going to talk about real quick. And it's honestly pretty obvious. Like right here, scheduled tasks run on your machine. So if you close out of the desktop app, they won't run. And the cloud routines will run no matter what because they're actually running inside of Anthropics infrastructure on Anthropics Cloud, which is why if you're doing the cloud routines, you're limited to how many runs you can do per day. So right here, I'm on a max plan and I get 15 runs a day for remote scheduled tasks. And if you're on the pro, you only get five. And I think if you're on team or enterprise, you get 25. Otherwise, it'll just cost you extra usage. But what's really cool about these is it's very similar to that loop because you're basically just getting to inject a prompt into the conversation of a regular cloud code terminal. So it's nothing too crazy. So for example, if I look at that school wins engagement one, which I currently have paused because I switched this over to a Hermes agent, you can see that I have these instructions, right? I basically say, "Hey, run the wins engagement skill. This means you do XYZ in this order. Here are all my instructions." And so when this actually runs, if I go down to like an example that ran, you can see May 6th, what it does is it just injects that entire prompt into a cloud code session and then it just executes it. Right? This project has my API keys. It has my context. It has everything that it needs and it can even search through other things. So you get the full agentic loop right here. You get cloud code on a timer. Now the cloud routines are basically the exact same way, right? Let me just click on this remote one, which is a paused one at the moment. you put in a specific prompt and that just gets injected right into the session. Same exact way. The only difference is that because these run on Anthropics cloud, you are basically getting like a clone of a repo in the cloud. And so you have to set environment variables a little bit differently. So I'm not going to do a full breakdown right now, but I did a full breakdown video which I will tag right up here. If you're interested in checking that out, click up there. Okay, so pros and cons here. The pro, this is built into cloud code on the desktop app. So there's no extra infrastructure or configuration. You obviously get your full cloud code session capabilities with skills, um, shell, mcps, sub aents, reasoning, all that. The cloud variant is awesome because you can literally set up those cloud routines and your machine can be off and your terminal can be closed, whatever it is, that will always run no matter what. Something else that's really cool about the local ones. So remember, if you guys saw, I had all of these local ones running, too. If I accidentally turned off my computer for like five days and then I turned it back on, when I open up the desktop app, Cloud Code would look through all of the local tasks that hadn't fired while it was turned off and it would play catchup, which is pretty cool. But definitely keep that in mind because if you don't want it to play catchup, you're going to want to make sure that you like pause those. Otherwise, it will play catch-up. And what else is cool on the remote ones is that you can have those be called by an API. So, it's basically a web hook that you could have other automations call on. So besides those just being timebased, they can also be event driven because you can also set them up to be called by like a GitHub action. So here is me creating a new cloud routine. You can see I can choose schedule GitHub event or API. So that's pretty neat. Of course though it's tough because you only have 15 per day unless you want to use extra usage. Anyways, cons. The cloud routines you have a 1 hour minimum interval. So you couldn't run like one every 20 minutes. If you wanted to do something like that, you would probably just want to do a / loop. The cap can be pretty tight, five a day with pro, but you know, you can always upgrade. Of course, if you're doing the desktop ones, the local ones, you have to keep everything on. And the other thing to think about is whenever you're injecting prompts into your cloud code sessions. And the idea is that you don't have to give any input, you really want to play with the prompts and you really want to watch it for a while to make sure that it can just autonomously go do whatever because careless prompt scoping can cause unwanted actions, which is just the nature of an autonomous automation. Okay, so that was these two right here. These two scheduled tasks we have obviously this one is on your machine. This one is in Anthropics cloud. They all have the WA and the T which is great. And then the scheduled tasks needs your desktop app open and your machine open. You don't need the session open because it starts a new session. And then the cloud routines you don't need anything on or any sessions open. So it's truly a 247 type of system. Okay. So moving on to method three we have deploying to something like modal or trigger.dev which is kind of it's not your own cloud. It's either modal or trigger.devscloud, but it's not enthropic. It's something that you are kind of configuring on your own, but it's not very difficult. The idea here is that you basically write a script. So, Python if you're using modal or TypeScript if you're using trigger.dev. You deploy that script to modal or trigger and you can have them run on a schedule or even like a web hook fire. So it can be like an an API at endpoint essentially and then it executes that Python script or type script script and then it gives you the output and you get a dashboard in modal or trigger to see how many times they've run and you can see you know errors and how long it took and stuff like that. So what's the difference between modal and trigger.dev well modal is Python serverless. You write a Python function and you just push it over to modal and then it runs in the cloud on a cron. So this very much feels more like a script on a timer. Trigger.dev dev uses TypeScript and it feels a little bit more agentic because sometimes your things get broken down into like two different um like scripts that would call on the other one. So typically I have preferred to use trigger.dev but at the end of the day if you have a very deterministic process they're both going to achieve you the same result and I don't really know how to write code in Python or TypeScript. Obviously my cloud code does it for me. But if you do understand Python way better than TypeScript then you probably would want to go with modal. Cloud code works with both of these two options very very well. It understands how to push scripts to the dev and move them to the prod. It understands that you need to put your environment variables over on modal or trigger.dev so that your automation can actually access things. I'm not going to do a full breakdown right now, but I have done multiple videos with modal on this channel. I will tag one of those right up here. And then I will also tag a video that I did with trigger.dev that I made on this channel which breaks it down a little bit more. I will tag that one right up here. Anyways, the oneline analogy modal is a chron job in the cloud. Trigger.dev dev is a durable workflow engine that happens to also support cron. But once again, both of these could be uh an API endpoint. You could turn that into a web hookup call. Okay, so that was modal trigger.dev. You can see here that's going to run on your cloud or technically like modal's cloud. And for the WAT framework, you're basically just deploying your skill. You're basically just deploying the workflow and the tools. You don't get that autonomous agent loop. And what else that means is all of the AI processing that you're going to be doing there will be an API call. Whether that's the cloud API or whether that's to open router, it will be not your cloud code subscription, which means it might be more expensive, right? Because you're running an AI processing that's token based, paper token. But the other cool thing about this is that a lot of these automations that you're going to deploy because they're going to be primarily pretty deterministic, might not even use AI at all. And that's where I would opt for one of these is if the process doesn't need AI and I can just chuck that script up somewhere to run on a cadence because it doesn't need your computer on and it doesn't need any sort of session to be open. Now, what you guys notice down here is I do show you an option with modal and trigger.dev that gives you the a part of the WAT framework and that is using the agent SDK. So, what is the cloud agent SDK? So, this is not really an official method that I'm diving into right now. It's just kind of like a little bonus thing to think about. But the agent SDK, it almost gives you like an endpoint for cloud code because essentially cloud code is kind of just like a user interface built on top of Claude's agent SDK. It has the tools, it has the query ability, it has more of that agent feel compared to if you just hit, you know, a raw cloud API endpoint where you're just kind of talking to the model and you get an answer back. But the agent SDK is like cloud code where it has like that harness and it can call tools and things like that. So yeah, the cloud API gives you just the brain that talks back while the agent SDK gives you cloud code essentially the brain plus the hands. So it can do all of these, you know, bash, file edits, web search, that whole loop and it's already wired up so that you can actually do the work instead of just give you some sort of like text based output. So here's kind of what it would look like. You would send off a query. You would shoot off an API call to this agent SDK. The agent would read that. It would decide on what tools it would reason. It would run the tools. It would get the results and it would keep iterating and then it would give you some sort of output. And so that's essentially what cloud code is, right? It's just wrapped up nice. Like I said, now the one thing that used to confuse me a lot about how the agent SDK worked and how cloud code worked was when you're in a cloud code session. So for example, if I just pull up this one, we can see how much has been used of my limit. And I could do something like a slashclear and I could do a slashcompact and I could do things like that. And I know that if I'm having a long ongoing conversation and I keep scrolling up, Claude will actually read that and help use that as context for my next decision. And the thing about the agent SDK is by default, every message that you send off is going to be stateless, meaning it wakes up, no memory, nothing. So basically the fix there is when you make your request to the agent SDK, if you're sending over the session ID, that's how you have an ongoing session. The agent SDK will also autocompact and things like that, but I don't think it does a SLC clear. If you want to do a slash clear, you would basically just start a new session. But anyways, it can do all these tools of course and it can utilize sub aents, MCPS, hooks, skills, slashcomands, cloud.mmd, memory, compaction, all that kind of stuff. And obviously, this is an official SDK from Enthropic. But the one thing that of course is bad about this is that you cannot use your cloud subscription if you're using the agent SDK. It requires a cloud API key. So, it's going to be much more expensive than you just using Cloud Code in your app or VS Code, your terminal, whatever it is, wherever you use Cloud Code. I'm so glad that I waited a few days to post this video because then on May 13th, they just announced that your monthly credit can actually go towards something like the Cloud Agent SDK, but it's not exactly like super straightforward. It's not the same weekly usage that you get. It's like a different dedicated budget. So, I'm not going to dive into that too much right now. I just wanted to let you guys know. Um, Theo made a really good breakdown where he kind of dives into like the scale and the different nuances. So, I will link that in the description if you guys want to check that out after this if you're interested in like understanding what this really means. But, just want to let you guys know. So, let's get back to the video. But the idea of pushing some sort of automation to modal or trigger.dev is still the same except for you just get the agent now, which obviously lets those automations be a little bit more nondeterministic, a little bit more agentic. not even a little bit more, a lot more agentic. Okay, so there are two more things that I wanted to very very briefly touch on. I'm not going to dive into them in this video, but I did want to call them out. So the first thing is managed agents, which is a fairly new service that Anthropic has spun up, which lets you do managed agents completely on Anthropic Cloud. Now, the reason I'm not going to dive into them in this video is because I played around with it and I honestly don't love it. Like I'm just going to keep working in my own infrastructure, the way that I have my routines, the way that I have my endpoints, things like that. I think a big value of the managed agents is for people who've probably never opened up cloud code before and they're looking to start building some agents. It just feels a little bit more like wrapped up nicely, but there's some functionality in there that I don't get. So, if you already are using cloud code and you understand it really well, then I would just say stick with cloud code. But if you guys do want me to play around with them more and give you a video, just let me know in the comments. Obviously, I'm here to experiment and figure out what works for what use case. And the other thing that I wanted to touch on was hooks, which honestly I haven't talked about too much on this channel, but it's a really really important and really cool feature of Cloud Code. So hooks are basically like eventdriven little automations and they're much more deterministic. So you write something to Cloud Code, right? The agent does something whether that's a um a GP or a glob or an edit to a file and after a specific event happens, you can set up a hook to fire. So then that hook script runs every time a certain action happens and that is very very powerful if you kind of layer a bunch of hooks together. So a real quick example is every time cloud code sends you a message that is something that can fire a hook and you can have that hook fire a noise notification so that if you're working you can hear when cloud code has sent you a message. The other things of course could be like a pre-tool use, it could be a postto use, it could be a session start or a session end. So there's a lot of power. I think if you're already just starting to like have some light bulb moments of, oh wow, every time the session ends, I want it to do this or every single time it uses like one of these tools, I would like it to do this for me. That's where you start to sort of loop them together. So it's a very very powerful feature. If you guys want to see like a full kind of masterclass breakdown of hooks and different use cases and how they work, let me know and I would love to bring you guys a video about that as well. But anyways, that is going to do it for today and I know we covered a ton of information in this one. So I threw all of this into a resource guide that you can access for completely free. The link for that is down in the description. You just have to join my free school community. This is what it will look like once you join. And then once you're in there, you're going to go to classroom and then you'll just click on all YouTube resources. Everything that I've ever shared for free is in there. But if you guys enjoyed the video or you learned something new, please give it a like. It helps me out a ton. And as always, I appreciate you guys making it to the end of the video and I will see you all in the next one. Thanks everyone.