3 AI Agents Built an App Overnight While He Slept

0:00This guy right here built three AI agents overnight. This [clears throat] is an amazing open claw use case that you could build today. This guy basically has three AI agents inside of open claw building him apps overnight while he is sleeping. I'm going to put the link to it down below. You could check it out and in this video we're going to be going over how he built them and what these agents actually do so you could build the same type of system. We're going to be talking about this Reddit user who woke up one morning to find that his three agents had built him a complete content platform while he was literally sleeping. 48 files, 3,360 lines of code, working screens, a full database, and an admin panel. All of it

0:46done literally while he slept. The crazy part is the reason it worked was not some fancy new tool or any kind of breakthrough model. It was one of the small architecture changes that most people building with agents are still getting completely wrong. So before I get into the story, let me set the scene because I think a lot of you are going to recognize yourself in this and myself playing some. You set up your open claw agents, you get them running and at some point you notice something weird in your usage logs. Your agents are waking up consistently and every few seconds but not because they have something to do just because they are checking in. This is what they call a heartbeat and some orchestration setups, the kind that inspired by older frameworks, run heartbeats on a tight loop. The agent

1:32pings and then it checks and then it finds nothing to do and it goes back to sleep and you get charged for every single one of those pings. The Reddit user who posted this story called it spending more on paperclip heartbeats than on rent which is a great way to put it. You you know so this person, their username is routine arm 8683, they posted in the open claw subreddit and the thread absolutely just blew up. The post is titled exactly that and I'll just I have the link down below like I said earlier, you should check it out. What they described was the classic trap that most people fall into when they first start building multi-agent setups. They had three agents running. One doing research and one is planning, one is executing tasks, one doing actual technical building, and all three of them were running on the heartbeat loop.

2:17Constant wake-ups, constant idle checks burning API credits around the clock even when there was literally nothing happening. And on top of that, the agents were not really coordinating anything. They were just all spinning up doing their own thing with no real sense of what the others were doing or had already done. That's the classic orchestration coordination failure that we all experience from time to time. Here's the shift that he made. And this is what I want you to pay attention to because it's actually kind of sweet. If first, they killed the global heartbeat loop and replaced it with a per agent cron schedule similar to kind of how I have it set up. So instead of every agent waking up every few seconds to check the work, each agent has its own schedule based on what it actually does. The lead agent runs once a day to plan

3:03the work. The executor runs on a schedule that matches the task flow. The technical builder gets triggered when there is something to build, not before it. And then they stop paying for the idle agent that wakes up entirely. Real quick before we keep going, if you're watching this and you want to actually build with some of these tools, not just watch videos about them, then you're going to want to check out our community down below shipping school. We have a full Claude code course, a full open claw course, and four live bootcamps every single week where we actually help you get set up from scratch. Like actually set this thing up, not just watch a tutorial and figure it out by yourself. And we also provide one-on-one coaching so you could book a call with me, we could share screens, and I can help you get Claude code or open claw

3:49running on your machine. That's it, no fluff. I built this community because watching YouTube's only gets you so far. We launched it just three days ago and we have over 55 members. You need people around you who are actually building, people who hold you accountable, and coaches who can help you when you get stuck. I'll put the link in the description down below. Get in now before the price goes up. The second thing is they set up a Discord server as a shared office for the agents. This is the part that I think is genuinely amazing. The agents use Discord channels as their communication layer. The lead agent posts its plan to a channel. The executor reads it and posts the updates. And then the builder agent picks up the task and then reports back. It is basically a stand-up meeting that runs

4:34itself. No human has to coordinate any of it. The agents literally talk to each other the way basically a small team. The third thing is, and this one is something I talk about inside of our community, is they set up a clear model hierarchy. The lead agent runs on Opus, the most capable and the most expensive model there is because it is doing the hard thinking. The executor runs on Sonnet. The technical builder runs on Codex. You are matching the model to the job, not just throwing the most expensive model at everything. You don't want to do that. Which is I think pretty cool from a cost standpoint but also just makes the system smarter, you know, because each model is being used for what it actually is good at. So they set all this up and then they went to bed. And in the morning, they had a content

5:19platform. 48 files, 3,360 lines of code, screens that just work, a database that is all set up, an admin panel, and all of this was built while he was sleeping. I want to be straight up with you about this and what it actually means. This isn't magic. The agents did this not spontaneously. They didn't just randomly decide to build a content platform. They were basically given a clear goal. They have the tools they needed and most importantly that they had the architecture that allowed them to actually work together instead of stepping on each other's toes and spinning up in idle loops, right? The architecture did the work, not the models. The architecture. This is something that I see over and over again. People get stuck in the thinking the model is the bottleneck. It's not. So they upgrade the model. They throw it at Opus. They throw Opus at everything.

6:04And then they're spending thousands of dollars. And sometimes that helps but most of the time the bottleneck is not the model. It's the setup. It is whether the agents have a way to talk to each other. How does your memory markdown files look? Are you using super memory? Are you on the active memory? Do you use wiki memory? What does that all look like? All these are pieces of the puzzle and to get it to work you need to put the puzzle together. That's where people get wrong. They end up starting on the wrong foot and it's okay. I did too. But that's why the things that we expect to work aren't working. There's more pieces to the puzzle. It's all about the architecture. So it's not whether, you know, they're being woken up at the right times or not and for the right reasons or not, it's whether the right model is doing the right job. Get those three things right and the model does

6:49not matter. The Discord shared office pattern is something I actually think is underrated. Most multi-agent setups either have agents running completely isolated with no awareness of what the others are doing or they have some kind of complicated orchestration layer that you have to build and maintain yourself. No one wants to do that. The Discord approach, just using a tool that already exists that handles message history, that lets you see exactly what your agents are saying to each other in real time, and that does not require you to build any custom infrastructure. You already understand Discord. Your agents can use Discord so just use it. The cron over heartbeat shift is also worth breaking down. The old way, the way that used this person used to do it, was the

7:35heartbeat loop way. It treats your agents like they're always on call. Every few seconds, every few minutes or hours, they're waking up, checking, going back to sleep, and you pay for every wake-up. The new way treats your agents like scheduled employees. They show up when there is work, they do the work, and then they clock out. It's the same exact system that I have for my content machine. For a team of agents running around the clock, that difference can be the difference between a system that costs $10 a day and one that costs 50 cents a day. But it will add up fast. If you're struggling to keep up with content, what I'm about to save you about 40 days worth of work. I [music] built something called content machine. It's 10 AI agents that run on the open claw orchestration and they handle everything. Scripts, thumbnails, X posts, [music] blogs, outreach, clips,

8:22newsletters, all of it. So I went from 1,000 subscribers to 4,000 subscribers on YouTube in 7 days using this exact system. Every single morning I wake up and the content's already done. I spend maybe 15, 20 minutes reviewing and approving them and I move on with my day. It works for any niche, fitness, [music] finance, real estate, marketing, whatever you are building and it is 100% completely customizable to your use case. So you get the mission control dashboard, all of the cron jobs, everything I've built over the last 40 days helping me gain more and more people to subscribe and join the community. So you plug in your own thing and it molds it to you. It learns how you talk and it writes [music] so it doesn't sound like AI slop. $97 one

9:10time, it's not a subscription. I'll put the link down below and you'll thank me later. And look, the reason this story resonated on Reddit is not because it's complicated, it is because it is straight up simple. One person, three agents, one architecture change, a working app by morning. And that is the kind of outcome that makes people want to get into this space, not because of the technical deep dives and not because of the benchmarks, but the actual real world results. Someone went to sleep and woke up with a content platform. That's pretty amazing. Let me talk about the model hierarchy thing for a second because I think this is where a lot of builders lose a ton of money without realizing it. When people first start running agents, they tend to just pick one model and use it for everything. And if they are being careful about quality, they pick the best model. So they're

9:55running Opus on every single task, including the simple stuff, the stuff that does not need Opus at all. That is like hiring a senior engineer to answer your emails. It works, but is not the right tool for the job, and it will cost you way more money in the long run. The hierarchy pattern that Routine Army used in the Reddit thread, Opus for the planning, Sonnet for the execution, Codex for the technical building, and that's a really clean three-tier setup. The lead agent is the thinker. It gets the expensive model because thinking is hard, and it's literally the job. The executor is the doer. It does not need to think that hard. It just needs to be fast and reliable. Sonnet is perfect for that. And the builder is the one actually writing the code, and Codex is built for that. It's the job that's perfect. And you can use your

10:40subscription through Open AI, and it won't cost you barely anything. And you can do this with any model stack. The point is to be intentional about it, not just defaulting to the same model everywhere. You want to build something like this yourself, here is what I would tell you. Start with the architecture before you start with the agents. Figure out how many agents you need and what each one is responsible for. Assign each one a model that matches the complexity of its job, and then set up cron schedules instead of heartbeat loops. Give them a shared channel to communicate. That is what the whole system is. It is not complicated, but it has to be intentional. Routine Army, the poster of the subreddit, posted all about this in Open Claw. The thread has

11:25a full breakdown, and people in the comments are sharing their own variations of the pattern. I will link it down below. Like I said, you need to check it out. This is the kind of thing that gets me excited about where this is all headed, because the tools are getting better, but the people are figuring out the architecture patterns are the ones that are shipping the fastest. And that is what this channel is about, shipping and building in public, not theorizing about shipping, but actually doing it. Not waiting for the perfect conditions. Get your product out there. Who cares if it works or not? Get it out there. And if you want to learn how to build setups like this step-by-step, come join us inside the community. 216 members have joined in the last 27 days. I got the link down below, and we have nine live calls a week. We just added our first local LLM

12:10call, where if you want to learn how to install local models on your local hardware and actually get things running and take control back to your life, well, we have a call for that on So, come join us. That's the whole point. Get started. You'll be able to go from zero to one incredibly fast and be building alongside other people that are doing the same. So, I hope you guys have a blessed rest of the day. Subscribe if you haven't already. Hit the notification bell, and we're going to keep coming at you with more videos, Open Claw use cases, and Open Claw updates. Have a blessed night.