Why One AI Agent Is Never Enough Transcript, AI Summary & Key Points

00:39 When I used to give an AI agent a task, it would finish in one go. Write the code, declare victory, done. Now, with the setup I'm about to show you and the logic behind it, the same task can take tens of iterations before the work is considered finished. The output is dramatically better and I'm spending less time on it, not more. The reason is that there is no longer a single agent doing the work.

01:06 There's a team. One agent writes the code, another reviews it, a third audits for security, a fourth ships it. They run on different models with fresh context each time and they push back on each other until the work actually holds up. I just play games until something generally needs me. In this video, I will walk through what that pipeline looks like, why each role exists, and how I run all of it end to end.

01:31 By the end, you'll have a complete picture of how to set this up yourself and a slightly uncomfortable realization about what your job becomes when the agents do the coding. Let's take a short break to introduce you to the sponsor of this video, an open-source observability project called Coroot with over 7.6 K stars on GitHub. Here's the pitch. Every minute of downtime costs money and finding the root cause usually means wading through mountains of logs and metrics and traces.

02:06 That kind of work typically requires senior-level expertise and can take hours. Coroot is trying to change that equation. It is Apache 2.0 licensed and it uses eBPF to automatically collect logs, metrics, traces, and profiles and to build a real-time map of services with no code changes. No changes to the code. On top of that, Coroot has a free AI agent that performs root cause analysis for you showing where an anomaly occurred, what happened, and the exact commands to fix it.

02:40 Open source users get 10 AI-powered incident investigations a month and the enterprise edition is fully self-hosted at $1 per CPU core per month with no charges for ingestion, egress, or hosts. So, if observability is something you care about, head over to coroot.com and check it out. Big thanks to Coroot for sponsoring this video and now let's get back to the main subject.

03:12 Process is the foundation of any good engineering work. It does not matter if it's a single developer working on a side project, a five-person team, one AI agent, or a fleet of agents. The principle is the same. You need to define workflow that says who does what, when, and in what order. Now, some parts of that workflow should be rigid. If a change touches production, there's a pull request.

03:36 Tests must pass. CI must be green. Those are not suggestions. Now, other parts can be flexible. A type-o fix in, let's say, readme doesn't need three reviewers and a steering committee. So, use your judgment. Without process, you have chaos. People stepping up on each other, code shipping without review, releases breaking because nobody validated them.

04:01 That's true for human teams, and it's even more true for AI agents, which are very, very, very enthusiastic and will happily ship broken code straight to main if you let them. Now, orchestration is just that same process applied to AI agents. Same principle, different workers. The same logic applies to tracking. You need a file, some kind of a document that describes what should be done, what's already been done, what's blocked, and what's coming next.

04:30 Call it a PRD, a task list, a roadmap, what whatever you want. The format matters less than the existence of the thing. You would want that file regardless of how the work gets done. A single developer needs it because memory is finite, and a week later they've forgotten what they decided. A team needs it because not everyone is in every conversation.

04:52 A single agent needs it because its context is finite and conversations get compacted away. A fleet of agents needs it the most because none of them, none of them share memory with each other. That file is the source of truth that survives everything. It survives you going on vacation. It survives a teammate joining mid-project. It survives an agent hitting its context limit.

05:17 As long as the file exists and is kept current, the work can continue. So, why agent orchestration specifically? Right? Start with the goal. Let's start with that. What we actually want is for agents to do the whole thing. You hand off a task, a feature spec, a PRD, a bug to fix, and agents take it all the way to a merged PR. They write the code, they review it, they audit it, they ship it, and so on and so forth.

05:48 You step in only when there's something that generally needs a human, a design decision, a final approval before merge. Otherwise, you just walk away and do something else. Now, you cannot get there with a single agent doing everything. You You cannot. A single agent has the same problems a single human would have. No separation of concerns, no independent reviews, no specialization.

06:13 Now, imagine it, right? Imagine the agent just as a person that wrote the code would be the same that is telling you that the code is good. That's not a review. That's a self-assessment. Self-assessments are biased by default. Whether the assessor is a human or a model, it does not matter, really. On top of that, as the agent keeps working, its context fills up with implementation details, debugging sessions, error traces, and conversation history.

06:44 Quality drops as focus spreads thin. So, all in all, orchestration is how you get there. One agent codes, another reviews, a third audits for security, a fourth handles the release, and so on and so forth. Each one starts fresh on its task with a clean context focused on a single concern. The review happens with fresh eyes, not the same eyes that wrote the code.

07:07 You hand off a task at the top of the pipeline, and the merge PR comes out at the bottom when they're all working together. Now, there is a practical constraint that comes with all that. To get end-to-end autonomy with optional human intervention, you cannot run agents in headless mode. You need to see what they're doing, sure, but you also need to be able to answer their questions, grant to them permissions, course correct when they go off track.

07:37 Cloud-p and other non-interactive modes give you visibility, but not interaction. That means full-blown interactive agents, the same ones you would run in your terminal day-to-day. The whole point of orchestration is that you are occasionally in the loop. And being in the loop means the agents have to be reachable when they need you. Okay. Now, with that motivation in mind, let's walk through what the pipeline actually looks like.

08:07 The shape is always the same. An orchestrator on top and a set of specialist agents underneath. The orchestrator is always there, right? Specialists, on the other hand, depend on what you're doing. For development work, which is the example we will go through, you would typically have a coder, a reviewer, an auditor, and a releaser. For a different type of work, the lineup would look different, but the orchestrator is always present because someone has to coordinate.

08:35 So, let's start at the top with the orchestrator. Its job is to delegate tasks to specialists and keep track of what's happening overall. It doesn't write code. It doesn't review code. It doesn't ship code. It coordinates. Now, that distinction matters because it shapes how much context the orchestrator carries. It doesn't need every implementation detail from the coder, every comment from the reviewer, every CV the auditor flagged.

09:05 It only needs enough context to know what to delegate next and to whom. That keeps its context lean. Ideally, the orchestrator never hits its context limit. It just keeps coordinating task after task after task. Nevertheless, sometimes it's unavoidable, right? It will hit the limit, maybe, who knows, and you are not lost. The tracking file, the one we talked about earlier, is still there.

09:32 The orchestrator can be compacted or even restarted from scratch, read the file, and pick up where it left off. That file is the safety net. Now, let's walk through each of the specialists starting with the coder. The coder is the agent that actually writes the code. When orchestrator hands off a task, the coder opens files, modifies them, writes the tests, runs the tests, and reports back when it's done.

09:57 It's the most labor-intensive role in the pipeline, which is why you typically point your most at it. Implementation is the hardest work in the chain, and shortcuts here show up downstream as broken builds or bad reviews. Then we have the reviewer. Once the coder reports done, the reviewer takes a look at the change. Its job is to find problems, bugs, missed edge cases, sloppy patterns, everything everything that should not ship.

10:25 The reviewer runs independently of the coder with its own fresh context, its own instructions. That alone removes most of the bias because the reviewer doesn't carry around the implementation conversation or the coder's reasoning. On top of that, you would ideally point the reviewer at a different model than the coder. Same model reviewing itself tends to share the same blind spots and the same convictions about what good code looks like.

10:54 A different model brings generally different judgment. Now, that's not mandatory, but it's a meaningful upgrade when you can swing it. Alongside the reviewer is the auditor. Same idea in terms of independence and ideally different model, but with a different focus. The reviewer is looking at code quality and correctness. The auditor is looking at security, like unsafe patterns, injection risks, RBAC scope creep, sloppy handling of secrets, anything that could turn into an incident later.

11:27 Those two roles are split because the questions are generally different. A reviewer is asking, "Hey, is this code clean?" And that's not the same as an auditor asking, "Can this code be exploited?" Different lens, different findings. You could merge them all into one agent, but the quality of both passes drops because the agent is context switching between two unrelated mental models on a single pass.

11:52 Now, the last in the lineup is the releaser. Its job is the easiest of four because it doesn't require any creativity. It just runs a recipe. Create a branch, push, open a PR, wait for CI, merge, close the issue, make it's mechanical. It's repeatable work. That's why the releaser is the role where you can comfortably use your weakest model. There's no judgment to exercise, no edge cases to spot, no clever code to write.

12:20 Just steps to execute in order and results to report back. A small, cheap, fast model handles this perfectly well, and you save your premium budget for the coder and reviewer and auditor, uh you know, the things that actually matter. Okay, now, with all four roles defined, let's look at how they actually work together. Everything flows through the orchestrator.

12:44 A task arrives, the orchestrator delegates the implementation to the coder, and when the coder is done, it reports back. The orchestrator then delegates to the reviewer and the auditor in parallel. If either flags something, the orchestrator sends it back to the coder with the finding. The orchestrator is the only one that sees the full picture and the only one making delegation decisions.

13:09 Now, there's an important distinction in how the specialists handle context. The coder, reviewer, and auditor always start fresh. New invocation, clear context, focused on whatever task the orchestrator hands them. This is deliberate. If the coder kept context across tasks, it would start carrying around irrelevant baggage from previous work, and the focus would degrade exactly the way a single agent's focus degrades.

13:39 Fresh context is the whole reason this works. There's an exception, and that's releaser. It keeps its context across the release flow. That's because the release is a stateful process. You create a branch, you push, you open a PR, you wait for CI, you handle the failures, you merge. All of that has to thread together. If the releaser cleared its context every step, it would lose the PR URL, the branch name, the CI status.

14:05 Stateful work needs persistent memory. And finally, there's the loop. The orchestrator does not assume success. If the reviewer or auditor flags something, the orchestrator sends it back to the coder with the specific feedback. The coder fixes it, the reviewer and auditor look at the fix. If they're happy, the orchestrator hands off to the releaser.

14:26 The releaser executes the release flow, and the change ships as a merged PR. The same pattern applies if the release itself runs into trouble. If CI fails, the releaser reports back the failure, the orchestrator hands the fix to the coder, the coder addresses it, and then the orchestrator tells the releaser to pick up the release from where it stopped.

14:50 The releaser doesn't restart. It continues. Now, there's one more thing before we move on. Everything we walked through, the four roles, the parallel review and audit, the failure loop, the stateful releaser, is one shape of orchestration. It's the one I use for development work, and it's the one we will see in action shortly. But, but but but it's an example, not a template.

15:13 A research workflow might have a planner, a fact checker, a writer, and an and Then, let's say. A data pipeline might have an extractor, a transformer, a validator, and a loader. The pattern stays the same. The roles change with the work. Okay. One last thing before we get our hands dirty. Uh a note. The tool we are about to look at handles the orchestration, the delegation, the parallel reviews, the loops, the context handoffs, all of it.

15:46 What it doesn't handle is the tracking file we talked about earlier. You bring your own. Uh PRD, task list, what whatever you use. I I don't care. The tool doesn't care about it, either. And uh the only thing important is that you need one. You always need it. Another thing, one more, actually, probably the last one. It also doesn't manage Git work trees.

16:08 If you want to use them, and there are good reasons to, you set them up yourself. I assume you're not a kid playing with uh toys, right? You're a software engineer who knows at least the basics. Otherwise, this is not for you. I don't Why are you watching this? Just go away. And now we're done, right? Everything else, the multi-agent coordination, the model selection role, uh the failure loop, all of it, is what we're about to look at.

16:38 The tool we're going to use is my pet project called Agent Deck. I covered the non-orchestration features in a separate video called You will find it. It's somewhere, probably over there. Uh if you've never seen Agent Deck before, that's one worth to watch for the basics, right? Today, we're focused on orchestration, specifically. Now, before we can orchestrate anything, we need an orchestration config.

17:01 The deck doesn't generate that out of thin air. It generates it by asking an agent to analyze your project. So, our very first step is to spin up a regular deck, not because we're going to use it for real work, but because that's the path to getting a config file written for this project. Once the config exists, we will throw this initial deck away and start a fresh orchestration tab that actually uses it.

17:29 So, with that in mind, press Ctrl M to open a new deck dialog, navigate into the project directory you want to set up, use enter to step into a directory, and space to select it, right? It's It's easy as long as you know how to use Vim or similar tools. And then, you type whatever command you want to use to launch your agent in the command field. That could be Claude or open code or anything else, right?

17:53 Depending on which agent you prefer. In my case, I'm using devbox run agent, which launches Claude Code inside a devbox shell. I'm freaky. I know that most of you don't use it, but that's fine. Now, what you should see at this point is the new agent dialog with the project directory filled in, a default name derived from that directory, and the command field ready for your input.

18:16 With the deck created, we can move on to generating the orchestration config itself. To trigger the generation, just press Ctrl D to enter the command mode, and press G to generate a config for this project. The deck pops up a confirmation asking whether you want to instruct your agent to analyze the project and create a new one. Just select yes, and then hit the enter key.

18:38 Now, what happens next is that the deck sends a long structured prompt to the agent which just launched. It tells the agent to look at the code base, understand what kind of project it is, figure out which roles make sense, and produce a config file with sensible defaults. The agent does the work. We just wait. Once the agent reports that it's done, let's take a look at what it produced.

19:03 We can do that with without leaving the deck, right? The exclamation mark prefix in the prompt tells the agent to run a small command on our behalf, So, we I'm going to ask it to print out the generated config file. That over there is the entire orchestration config. So, let's unpack what's in it. At the top, there's an orchestrator orchestrator role to be more specific.

19:24 That one is the master of ceremonies. The agent that delegates and coordinates everything else. Underneath, we have coder, reviewer, auditor, and release, right? Exactly the four specialists we walked through earlier. Each role has a small set of fields that define how it behaves. The command field is the shell command that actually launches the agent for that role.

19:47 That's where That's where you choose which CLI, which model, and which configuration the role runs with. The clear field controls whether the agent starts with a clean context on each delegation. Now, notice that the release is the only one with clear set to false because, as we discussed earlier, the release flow is stateful and the agent needs to remember the PR URL or the branch name or stuff, right?

20:10 Then, we have description field. That's what the orchestrator reads to decide when to use a given specialist. And finally, the prompt template is the role-specific brief that gets injected into the agent's context on top of whatever instructions the deck adds automatically. A word of warning, the AI is not going to nail this on the first try. It's It's It's not going to happen.

20:34 It produces a reasonable starting point, but you should expect to spend some time fine-tuning the config file after using the orchestrator orchestration, actually, for a while. Maybe the reviewer's prompt is a bit too vague. Maybe the coder is missing a project-specific rule. Maybe you want to switch one role to a different model. Treat this file the same way you would treat any other piece of project configuration.

20:58 It evolves with the project. Now, you might be wondering how the AI knows which models to assign to each to which role, the answer is that it inspected the project and figured out the launch mechanism from what was already there. In my case, that turned out to be that box. In your case, it could be a shell script, make file target, plain code or open code commands or anything else you happen to use to start an agent.

21:25 The agent looks at the project, sees what's available and adopts the config to match. Now, let me show you what that looked like for me. The part that matters here is the script section near the bottom. That's where I've defined different agent profiles one per role. There is agent orchestrator running Claude with Opus model. There is agent coder also on Lopus because, you know, implementation is is the hard work.

21:49 There's agent reviewer and auditor both running open code with the GPT model deliberately on a different family to bring in independent judgment and there's agent release which uses Claude with the Haiku model because, you know, mechanical release work doesn't need a premium budget. Okay, now with the config in place, let's switch over to a project where I already done all of this, right?

22:16 Uh the config is set up the way I like it. There are open PRDs ready to be worked on and we can see the orchestration run end-to-end. So, same shortcut as before, press control N to open a new deck dialog and navigate to the project directory using enter and space. This time though, there is a mode field available because the project has a config file sitting at its root.

22:37 So, pick the orchestration mode, hit enter a few times to confirm the rest of the fields and the deck spins up a new tab with all five agents already running. What you see on the left-hand side is the deck panel listing five sessions, the orchestration on top, then the coder, reviewer, auditor, release each in its own pane. On the right, the orchestrator's console is already up and it's waiting for the instructions.

23:05 Now, let's give orchestrator something to do. I'm using a skill called PRD full, which tells the agent to read a PRD file, figure out which tasks still need work, and keep that PRD up to date as it goes. It also instructs the orchestrator to keep working without stopping until a PR is created. Now, you can drive the orchestrator any any way you like.

23:30 The point of using a PRD file is the safety net we talked about earlier. If the orchestrator's context fills up and needs to be compacted, the PRD file is what lets it pick up where it left off. That skill, along with the rest of the workflow skills I use, is part of the project. You're welcome dev tools. There's somewhere over there, right? You're welcome to grab it, try it out, and so on and so forth.

23:53 Uh, what matters is that that's unrelated and you can do it any way you like. Okay, so off we go, the team is working. The deck panel on the left isn't just a list of agent names, it's a live activity overview. Each pane shows what its specialist is currently doing. You can see at a glance who's busy, who's idle, and roughly what they're working on.

24:18 And you can do all that without without having to switch into each agent and read the whole conversation. In this run, the orchestrator has delegated the first task to the coder. You can see the coder pane on the left lit up with the implementation activity. On the right, on the other hand, you can see the orchestrator's console shows the delegation message and is now waiting.

24:42 It's just waiting for the coder to report back. Now, if you really like watching things, you can watch the coder in its pane and you can watch it work in real time. And I do that sometimes out of curiosity, but that's not the point. The point of all this is that you leave the orchestration running, [music] and you switch to watching YouTube, you or you go to sleep, or you work on something else entirely, and then you come back later to validate the end result.

25:10 And that's usually when a PR is shown up, created, right? When you do come back, the orchestrator is the agent worth checking first. It has the bird's-eye view of what happened across the whole pipeline, of who did what, what got fixed, what's still pending. So, most of your time, when you're actually paying attention, uh you will land on the orchestrator pane.

25:37 Okay, now, fast forward, and the coder reports back that the first task is done. The orchestrator then reads the summary, decides the work is in good enough shape to move on, and delegates the next stage. And as you can see right now, probably on the screen, uh it kicks off the reviewer and the auditor in parallel. Both of them get the diff, both start a fresh context, both look at the same change, but through a different lens.

26:09 And the orchestrator then just waits. Just waits for them to report back. And that's the loop in action, right? Orchestrator receives findings from the reviewer and the auditor, and if either of them flag something that needs to change, it sends the work back to the coder with a specific feedback. The coder fixes it, the reviewer and auditor look at the fix, round and round and round and round and round it goes until everyone is happy.

26:34 And then the orchestrator moves onto the second task, the third, the fourth, and so on and so forth, until the whole PRD is complete. When the implementation is done, the orchestrator hands off to the release agent. If something breaks during the release, like CI failing, it it routes it them back to the coder for one more pass. Actually, not to the coder, to the orchestrator.

26:59 Eventually, the whole thing wraps up and the orchestrator either waits for me to approve the polished PR or it merges it directly if that's what I told it to do at the start. So, that's the mechanics of it. But, the more interesting question is what this actually changes about your day-to-day. Because, if you've been paying attention, you will notice that the thing I just described doesn't sound like a developer's workflow anymore.

27:26 It sounds like something else. So, let's talk about what that something else is. The whole point of all this is to have agents working on one or more features across one or more projects by themselves. You stay out of the way until something generally needs you. A design decision, a judgment call, a final review of the PR before it gets merged. Outside those moments, the orchestration runs without you and you spend your time doing something else.

28:01 With a single agent, sometimes the code was good, sometimes it wasn't and I found out the hard way later, right? With this setup or some similar setup, the failures get caught before they ship. The reviewer pushes back, the coder fixes, the auditor catches something, the coder fixes again. They go back and forth, back and forth until all three are satisfied.

28:23 The whole thing takes much longer, much longer in wall clock time than a single agent run. But, since I'm not the one sitting there watching, the duration barely matters. My time is going into the work that actually requires me. Planning the next feature, writing PRD files, deciding what to build, not how to build it. All that brings us to the part where the job title quietly changes.

28:52 You're not a coder anymore. Not really. You're a tech lead, an architect, a manager. The person who decided not to micromanage. You have a team of agents working for you. 10 of them, maybe a hundred eventually. And your job is to set direction, to write clear specs, and step in only when something interesting comes up. You're effectively the CTO of a very small company where everyone else is a model.

29:21 The skills that matter shift. Writing tight loops becomes less important. Writing tight PRD becomes more important. Reviewing diffs becomes less important. Reviewing the shape of the work, the architecture, the trade-offs, that's what becomes much more important. That's the pitch. If any of this sounds useful, head over to Agent-X, try the app. Star it if you find it valuable.

29:46 Fork it if you want to bend it to your own workflow. And please, please, please send me feedback. I built this for myself because I wanted to orchestrate my own agents, and now I'm sharing it with you. Tell me what works. Tell me what doesn't. Tell me what's missing. Thank you for watching. See you in the next one. Cheers.