How I Manage 45 AI Agents Across 3 Machines Transcript, AI Summary & Key Points

00:07 Right now I have 45 agents working across three machines. My laptop, a mini PC in my office, and a server in in motion. I call it my agent fleet. In a few hours, that fleet produces what would take me a week or two to write myself. Getting it to do the work is not the hard part anymore. Seeing what it's doing is. Now, we all know how to run an agent and work with it.

00:36 Many of us know how to do the same with a few agents running in parallel. But what happens when there are dozens of them spread across multiple machines? How do we manage a fleet like that? because that's what I am these days, a manager. And a good manager's work comes down to three things. Delegating work, resolving conflicts, and removing obstacles so the team can keep going.

01:01 To do that well, a manager needs a team that can work on its own most of the time. And the way to see what that team is doing when it can't with that team is made of agents. They are already very good at almost everything. And if I did my part, they know how I like to work, what the rules are, and what they should and shouldn't do. That's what agents MD and skills are for.

01:30 I will assume those are in place since that's the whole different topic. Now, what I want to show you is how that team grows from a single agent I have to babysit to teams of agents spread across machines I don't even need to be near. And what happens to the manager along the way? because the agents scale much better, much much better than I do. Now, the beginning is often the best place to start.

01:55 So, let's go back a year or maybe two. A fleet like that doesn't stay the same size for long. One week it's a handful of agents on one box. The next it's a queue of 20 issues with six of them working in parallel. The hardware has to follow and so does the bill. That's where the sponsor of this video comes in. In motion cloud offers a managed private cloud running on infrastructure it owns and operates with a predictable monthly price and a fixed egress allowance.

02:26 The part that fits a fleet that keeps changing shape is flex spend advantage. Instead of paying per line item and finding out at the end of the month what the agents cost, you commit to a fixed monthly spend within it. You rebalance resources as workloads change more VMs for agents this week, fewer next week without rewriting the budget. That gives you room to scale agent environment, CI runners, and test workloads without treating every change like a new pricing decision.

03:02 You can see how resources map to your plan and senior US-based engineers can help when your environments need to change. If you're building agents, running CI, or moving AI workloads beyond a single machine, use the link below, somewhere below to get up to one month free within Motion Cloud. Big thanks to Inot Motion Cloud for sponsoring this video.

03:25 And now, let's go back back to the beginning and a single agent I did not trust just yet. I tell it to fix an issue and before it has even read that issue, it stops and asks whether it's allowed to run GH issue view. That's how it goes with the team member I don't trust yet. I approve this, then the next thing, then the one after that, the work gets done, but all all of my attention goes into babysitting a single agent.

03:59 So the team cannot grow beyond one. there is nobody left to manage the others. Trust changes that. At some point, my skills and the rest of the agents instructions become reliable enough that I noticed I was saying yes to almost everything it asked. And once approving turns into a reflex, it's no longer oversight. It's just me slowing the agents down.

04:21 So, I switch it to auto mode and it stops asking about every command. It creates a work tree, lows the skill that tells it to reproduce a bug before fixing it and carries on without me. That is the moment a manager stops supervising and starts delegating. A few hours later, it's done. The agent opened the pull request and that kicked off everything I would expect around the change made by anyone on a team.

04:50 workflow built and tested on Linux, Mac OS and Windows and run the security checks. Two review bots grab and codo went through the code over four rounds and every time they found something, the agent fixed it and pushed again. By the time it comes back to me, all the required checks are green and no review thread is left open. My job comes down to two things.

05:16 Delegate the work and judge the outcome. If something is off, I tell it what to change. That's the other half of the trust. Good instructions make the agents reliable, and the pipeline catches whatever still slips through. Once the agents can work without me hovering over them, the size of the team is no longer limited by my attention. My job shifts to handing out work, and one agent in one terminal isn't enough for that anymore.

05:50 That's where agent deck comes in. It's an open- source terminal app I built for running and merging my coding agents at once. Whether that's cloud code, C codeex, open code or others. In it, I start a dispatcher, an agent whose only job only job is to take work and delegate it to other agents. The simplest version is one issue per agent. I ask the dispatcher to pick two issues.

06:14 It spins up an agent for each of them, each in its own work. three cut from main so they cannot step on each other's toes. Now, not everything fits a single agent though. For something bigger like a PRD, I asked the dispatcher to hand the work to a whole team instead. An orchestrator coordinates a coder, a reviewer, an auditor, a tester, and a release agent.

06:38 Each with its own role. They are not even the same agents. Cloode code, Codex, Open Code, and PI all work on the same PRD, and they're not running the same models either. Some models are better than others at certain tasks, and some are cheaper while still being more than capable of doing a specific job. So, each role gets whatever fits it best. Now, I will not go into why splitting the work like that matters since I did already that in one of the videos.

07:09 It should be somewhere there. All that all that runs on a dedicated machine, the mini PC in my office, not on my laptop. My laptop holds plenty of things agents have no business seeing and it goes to sleep whenever I close the lid. Now, when I was micromanaging a single agent, that did not matter since I had to be there anyway. Now that I'm not, there's no point keeping my laptop awake just so that agents can work.

07:36 Which means that once the work is handed out, I can walk away. I detach. The agents keep running on the mini PCN and I go do something else. Later that night, I come back to check. All three units are done. Triple requests each with a short list of what's still needed before it can be merged. A review, a couple of checks, the agents couldn't run on that box, and my go-ahad.

08:01 From here, I can dig into any of them. approve or send it back with corrections. There's a problem with that picture, though. Some of those agents finished hours ago. This one worked for almost 3 hours and then just sat there, right? They're just sitting there waiting for me. Agents should be working all the time, as many of them as the machine they're on can handle.

08:24 They should not be waiting for me to show up with the next task. A manager who hands out one task at a time and then just disappears ends up with a team that spends most of its day waiting. So instead of handing out work a few items at a time, I just give the dispatcher a queue, right? 20 more issues. It decides whether each one gets a single agent or a whole team and it keeps up to three of them working in parallel.

08:53 It fills the three slots right away and when one of them finishes, the dispatcher checks its pull request and sends out the next one. Why only three, you might ask? Because I want the team busy without pushing that mini PC past what it can handle. A team can only be as big as the environment it works in. And the mini PC is out of room, right? If the team is going to grow, it needs more hardware.

09:23 So, I add a server in in motion cloud. I don't set it up myself. Who does that anymore? I ask an agent on my laptop to do it and it takes care of the rest. Once it's ready, I connect the InMotion server and there I start another dispatcher with its own queue of 20 issues and up to six working in parallel. Now, notice how specific I have to be though.

09:48 I list exactly which issues this dispatcher gets because the mini PC is already working on others. It fills all six slots right away. Two teams in two places and neither neither knows the other exists. The only coordination between them is whatever I put in their prompts. Now remember that because it will matter later. Now a few hours later I open GitHub.

10:13 18 open pull requests. Most of them opened while I was away. Each of them each of them went through the same process as the very first one. Take that first pull request as an example. Codo summarized it and reviewed it. Review agents review workflows validate. And then there's the approval agent running in GitHub actions. Its job is to confirm that everything everything is green and that every finding from the reviewer was resolved.

10:40 Only then only then does it approve. The result is a pull request with the approval it needs and all the checks passing and waiting for someone to decide whether it goes in. And that's where it starts breaking down. Not the agents and not the hardware visibility. Seeing what one team does on one machine works fine more or less. I open agent deck, there's a list of agents and I can tell who's working, who's done, and who's waiting for me.

11:11 But now you have a team on the mini PC, another one in in motion and a few agents on my laptop. And each of them knows only about itself. Every machine is a separate tab in my terminal and I jump between them hoping I didn't miss the one that needed an answer ago. That falls apart after a couple of machines. The more the fleet grows, the less of it I can see and I cannot delegate, unblock or review what I cannot see.

11:42 A manager with teams in several offices needs one place to see all of them and a way to reach any one of them when it needs attention. That's why I built the desktop version of agent deck. When I'm focused on one agent and working through something with it in depth, the terminal is still where I want to be. But when the question is what's going on with the whole fleet, I want one app that brings all of it, all of it together.

12:12 So here it is. The 45 agents are mentioned at the start. All three machines in one place. 12 of them are running right now. The first group is my laptop with a few agents I use for investigation. Below is the mini PC. Seven agents, seven agents running, 19 waiting. Waiting doesn't mean stuck, right? Those agents finish their work and are waiting for me to review what they did.

12:38 An agent with a question for me would show up differently is waiting for input. Anyways, either way, they need me. And this is where I find out. Now scroll further down and there's the in motion server with its own agents. Five running, 11 waiting. When I want to work with one of them, I open it and this is the part I care about the most. What's in that terminal is the agent itself is the real cloud code session.

13:05 The same one I would get if I connected to that machine from a terminal reached out over SH through the agent deck demon on that box. The app doesn't pull its own interface between me and the agent slash command skills hooks key bindings every everything I've invested in works exactly exactly the way it always does now that distinction matters I don't want tools that wrap agents in their own UI clo codeex open code and the rest ship improvements every week every day maybe multiple times a day and the wrapper is always

13:40 a step behind them what agents whichever ones you're using don't give me is an overview of every agent on every machine. So that's what a central app should do. The conversation itself is something agents already do better than anyone. So the app should take me to the real thing and get out of the way. If you think you can do better, build a better agent.

14:03 Don't build a wrapper around someone else's. Let's step back for a second and look at what happened. One agent I didn't trust became one I did because my instructions got better and the pipeline code the rest. A dispatcher kept a whole team of agents busy until the mini PC ran out of room and the team spread onto another machine. And somewhere along the way, the problem stopped being the agents and became seeing what they do.

14:35 Remember the week or two of work I mentioned at the very start? That's what those pull requests add up to. It took hours, not even a full day. And that's when the real work starts. All of it has to be merged. Even when most of that is automated, merging one pull request creates conflicts in others. Resolving those conflicts, invalidates approvals, and around it goes.

14:58 Ideally, ideally, each one would be merged and released the moment it's done. But that brings its own complications. And no, I'm I'm not going to review every line of every pull request myself. I don't do that anymore. That would be insane. And other agents already did that. Instead, I focus on the parts that matter, especially the parts users see like the UX and the documentation.

15:27 Visibility was the first bottleneck. Once I can see the whole fleet, the next bottleneck is it's me. And there's one more gap. Each machine has its own team and those teams don't talk to each other. The dispatcher on the mini PC has no idea what the one in in motion is doing which is exactly exactly why I had to tell each of them which issues to take.

15:49 So think of them as teams in different offices of the same company to be really efficient they will need to talk to each other and hand work across machines. So that's what I'm working on right now and uh it's coming maybe in a future video. Who knows? Until then, everything you saw is agent deck uh with agents running on my laptop, a mini PC, and a server in in motion.

16:13 It's my pet project. It's what I use for all my work with agents. And then it's open source. Use it. Tell me what's missing. Open issues. And if you feel like it, you can contribute as well. Thank you for watching. See you in the next one. Cheers.