Claude Code's Agent Teams Are Insane - Multiple AI Agents Coding Together in Real Time

Take a look at this. I have four instances of Claude Code working at the exact same time together to perform a code review on my code base. And this is all thanks to the new Agents Teams feature that Anthropic has built into Claude Code. And man, let me tell you, it really does look like I'm peering into the future of Agentic Engineering when I am using it. So we have our primary lead agent on the left-hand side. And in real time, I watched it spin up each one of these team... Tmux terminals to create these agents to collaborate on the same task. Now, people have been doing this sort of split-pane, multi-Tmux terminal sort of setup for a while now, so it's not really new. But there are a couple of things that make this super novel. The first is that our primary agent, it actually decided the team to form based on the request that I gave it. And the other part of this that makes it so powerful is that under the hood, each one of these agents is working on the exact same task list together so this goes way beyond sub agents these agents actually talk to each other like oh let me complete this before you work on this they have that kind of communication that makes it so that we can take this idea of parallel agents a lot further So in this video, I want to cover how Agent Teams works with you. It's a new experimental feature that you have to enable. We'll talk about how to set it up. I also really want to cover how Agent Teams is different from sub-agents. A lot of people are confused by this right now because they operate really similarly. The main difference is we have collaboration versus isolation. There are pros and cons here that I want to cover. Agent Teams is really powerful, but it is not perfect. So we'll get into that, which will also lead into... a template that I have for you. This is a command that I've built. Basically, you can use this to give instructions for Cloud Code on how to use Agent Teams better. Because believe it or not, even though this is a feature built into Cloud Code, it's not actually that good at using it. And so I'll show you how to really take advantage of this new feature to do some pretty incredible things. Now, this code review demonstration that I have for you is just a really simple example of what we can do with Agent Teams. Anthropic has published a couple of articles where they've shown how far we can push this idea. For example, Anthropic used 16 agents running together with this new agent team's feature to build an entire C compiler. And let me tell you, building a compiler from scratch is not easy. If you were to hire a dev team to do this, it would probably be hundreds of thousands of dollars, but they were able to do it. with only $20,000 in API costs, which, yes, that is still an insane amount of money. Agent Teams is very token heavy, which is one of the downsides we'll talk about in a little bit. But it's still really cool to see how far they were able to push what is possible with coding agents just running together, collaborating autonomously. They literally just threw this in essentially a RELF loop where they forced it to write, I believe, hundreds of thousands of lines of code to create this. So it's very, very incredible. The kind of thing that they... say later in this article, there's no way that a single agent would have been able to do, even if you were to give this whole task to, you know, Opus 4.6, for example. All right, so really quickly, I want to show you how you can get your first agent team up and running in just a couple of minutes. And then we'll get into how it's different from sub agents because it is really important to understand. So I will have a link to this page in the description. This is the official guide on agent teams from Anthropic. However, there is a lot of information here. It's pretty overwhelming. And so I just want to break it down nice and simple for you right now. So the first thing you have to do, because this is an experimental feature that is far from perfect, trust me, you have to enable it. And so you can either set this environment variable on your computer or in just a terminal session, or you can add this to your settings.json. So this is one of the config files for Cloud Code. you've probably worked with this before because it's where you set things like your MCP servers and your hooks. And so we can set this at either the global dot cloud level or in the dot cloud project directory. And so you can enable agent teams just for specific projects if you want. So the other thing that you have to set up if you want that split pane mode where you can see all the terminals at the exact same time is you need to install either TMUX or iTerm2. These are terminal applications that support the split pane mode. And these are just the two that are supported by Claude Code right now. So if you install TMUX, which is my recommendation or iTerm2, then Claude Code can leverage that directly to create those terminals and you can watch them appear. in real time. We'll see that in a second. It is really, really cool. And so the instructions is a bit different depending on your operating system, but actually in the agent team skill resource that I have for you, I have a read me that gives you the installation instructions. So really, really easy. Just keep in mind for Windows, you do need WSL. And so I actually have that. So I got my Linux subsystem here on Windows. I'm running on Windows right now. And so the first thing you have to do is you have to set that environment variable. So either like this or in that settings.json file. So Cloud Code, Experimental Agent Teams. Boom, there we go. So now the next time I go into Cloud, agent teams is available to me. So now just like with sub agents, all we have to do is tell Claude, we want to use the agent team feature, and it's going to know exactly what we mean. And so for a very simple example, I'm going to send in this request right here. So I'm asking it to create an agent team to review my code base similar to the demo I showed you earlier. That was a lot longer of a prompt though. But for simplicity, I'm just going to say have one agent focus on security, one on code quality, and the other on documentation. Now we could use sub-agents for this as well. But the collaboration we have here, even for a simple example like this, I think is really powerful. Because for example, the review on security might affect the way that we see documentation. Like maybe we need to make sure we document any potential security issues that exist in the code base. I think you get the idea of how that collaboration, even for a review, but especially for when we're diving into actually writing code, that is really, really necessary. And so the lead agent here, it's going to do its initial analysis, think about the team to generate, and then it'll spin those off. So I'll pause and come back once we've gotten to that point. So here we go. Usually the indicator is something like, let me create the tasks and spawn all three review agents, because it defines the task list that is shared between all the agents once they collaborate. And then in just a second here, we'll see the first pane spin up on the right-hand side, and then it'll do all three one by one. one. And boom, there we go. We have our security reviewer to start. And you can see the command that the lead agent runs. It's just starting another cloud code session, but it's passing in the prompt to give it that context around its role. It is the security reviewer and then giving it the task list and access to manage that with the other agents. And yeah, a lot is happening here. A lot of buzz on my screen, but it has started all three agents now really, really quickly. And each one of them is focused on their individual task, but they'll start communicating. with each other. Now, one thing that I will say is you have to watch the logs very, very closely just to get a sense for when the agents are actually talking to each other. So maybe that's one of the gripes that I have with agent teams right now is there's really not that much visibility into the actual collaboration. And so I have seen examples as I've been testing things. And if you ask the lead agent after how the agents collaborated, it will give you a good answer. But for a lot of it, I just feel like I'm trusting that the agents really are working on the task list together, there's not a really good way to dive into it. Now, one thing you can do is you can press control B, and then you can press an arrow key to navigate between the different TMUX terminals. And so I can chat with any one of the agents here to ask it like, what are you currently working on? How are you collaborating with this agent? It's also really powerful to go to the primary agent, ask that as well, like give me a status update on the task list and what the agents are working on. And then, by the way, once all of the agents in the team are done, the lead agent will spin down all those terminals, and you're brought back to the simple view here, where you can continue to work with the primary Cloud Code agent, or spin up another team if you want. So I want to take a little bit of a different break from the video than I usually do. I'm speaking at an event this March which I am super excited to tell you about. It is the Sonar Summit, which is Sonar's first ever global virtual event. And I'm doing a fireside chat on building self-validation and guardrails into AI coding systems. And this has been a big focus of mine, because here's the thing. AI is already writing 30 to 40% of new code at major tech companies, so adoption is pretty much universal. But teams are realizing that shipping code faster does not necessarily mean also shipping quality faster. Review times are climbing, incidents are up, and security vulnerabilities just slip through. So for my session, I'll be covering what I call the AI validation pyramid. This is a framework that allows us to define the validation requirements before we even write a single line of code. So it's a part of our plan. And we have our agent handle the foundation, all the easy things like the type checking and linting, and our initial round of testing. And then we as the humans control the layers that matter most. And besides my event, there is a lot more going on at the Sonar Summit. There are four tracks in total, with keynotes on the future of software development in the AI era, deep dives into SonarCube, sessions on integrating code quality into CICD pipelines, a lot of awesome events to attend. And by the way, it's free to come to Sonar Summit, and they are running this virtual event in pretty much every single time zone. And so if you want to know how to ship quality at speed, not just code at speed, I would... highly recommend checking it out, and I will have a link in the description. So hopefully the value of agent teams and how to run them is clear to you. Now I want to talk about how they are different from sub-agents, and this is a really important distinction, because now whenever you want to do parallel work with Claude Code, you have to make that decision. Should I ask Claude to use sub-agents, or should I ask Claude to spin up an agent team? And spoiler, there still are a lot of times where you want to use sub-agents instead, especially because of a couple of problems with agent teams that I'll talk about that'll lead really nicely into this skill that I have built for you. This makes Claude a lot better at using agent teams, so I'm really excited to show you this, but first let's talk about sub-agents. So the primary idea with sub-agents is context isolation. We want some way to be able to dish out a request that could take tens or even hundreds of thousands of tokens, but all we need back is a summary. So our primary agent knows general what happened, but it doesn't have to be polluted by the context of the entire task. And this is important because context is the most precious resource when you're using an AI coding assistant. But this context isolation has downsides to it because there is no coordination between sub agents and the entire process is just a black box because it is only the summary, the final output that is given back to our primary agent. And so that is why I say that sub-agents are generally used for focused tasks, usually something like research, because all we care about is the result, that summary at the end of the research. If we're doing something like coding and we have a sub-agent actually write code, then we don't have any idea into the process of the sub-agent. And so the main agent loses a lot of context as to what was actually implemented, which is why I say research over implementation. There's no coordination at all. These sub-agents were completely in isolation, which does make them very token efficient because they're honed in on a single task. and they're only communicating a little bit back to the primary agent. But sometimes you need a lot more than that. Sometimes you need your agents to coordinate with each other, manage a task list together, and that is where Agent Teams comes in. With Agent Teams, we still have a primary agent spinning off the subprocesses, but the difference here is they're actually talking to each other. So they have this shared task list, they're updating each other on their progress, communicating to the main agent as well, and you can instruct Claude Code in a lot of different ways how this communication actually takes place. We'll talk about that in a little bit. So we have true peer to peer coordination. And this is so powerful for implementation. Because for example, our backend agent might change something in an API endpoint where it would have to tell the frontend agent, hey, I changed this API. Make sure you update the frontend component that uses the API as well. And it can actually do that. When we had subagents in the past doing that kind of implementation, those kinds of things would break all the time because they're not talking to each other. So you'd step on each other's toes, but not know they're doing so. And so it was up to the main agent after to find all those bugs and fix it. And it was just a complete mess. And so agent teams is a lot better for implementation. But you have to keep in mind that sub agents are a lot more token efficient. It takes a lot of tokens to set up this task list, maintain that collaboration and the communication between the lead agent and all of the other agents in the team. And so this is a really, really rough estimate. But yeah, oftentimes when you're using agent teams, it's like two to four times the token usage compared to just using cloud code by itself or using sub agents. And so you oftentimes need the collaboration for coding. So generally, I would say if you want a really simple rule of thumb right now. You should use sub agents for any kind of research, like diving into a code base or searching the web. And then you should use agent teams for your actual implementation. And so a lot of times when you're working with a single conversation of cloud code, you might start with sub agent research, like analyzing the code base, and then create that task list and spin up the agent team to knock out the plan that you created from the research. So again, it's sub agents for research. feed that into a plan, and then send that plan into an agent team. Now, as powerful as agent teams are, there are two more issues that I want to talk about with you, and then we'll get into the template where I've been starting to address this and experiment with some things to make agent teams more reliable. So the first problem that I've encountered, as I've done a lot of testing on both Linux and Mac, is that a lot of times you have to be very specific with Claude. Like you have to say, create an agent team with four teammates to do this and this and this. If you aren't really specific, it just kind of hallucinates. It'll make weird teams. Sometimes it doesn't understand how to handle the Tmux terminals. Most of the time it will work, but there's just those odd instances I ran into where it just totally fell flat on its face. And then the other problem that I've encountered is sometimes even with the agents communicating with each other, they can't truly run in parallel. For example, I had it happen once where I had my database and backend agent run at the same time. The database agent defined a bunch of the schema. And then by the time it told the backend agent what the schema actually was, the backend agent... almost was done with its work. So it created this entire backend based on a completely incorrect schema. So I had to go back and do a lot of work. And so yes, the communication was there for it to fix itself, but it would have been a lot more token efficient if we just did database agent first, then the backend agent. And so I have been working hard through a lot of experimentation to address both of these things with this skill that I, of course, will have links in the description. This is giving instructions for Claude Code on how to more reliably create agent teams and manage the issue of sometimes things can't be totally parallel and being really specific for how to use the terminals and how to create good teams. And so I have this clone locally ready to go to create a brand new project. And by the way, you can use this skill. I'll show you how to in a little bit to create brand new projects or features in existing code bases. And so everything is driven from these instructions here, which I'm not going to get too in the weeds with this right now, but essentially all we have to do is give it a plan, something we've created with sub-agent research or whatever, like here's the next feature we want to build. So we give it the plan and then it'll use these instructions to figure out what's the optimal team to address this plan. Should we create a backend, frontend, and database agent for the team? Like what should it be? Also giving instructions for how to manage the terminals effectively to reduce some of those hallucinations. And then most importantly, I have this process called contract first spawning. So we're not doing everything in parallel. Well, we're setting the stage up front for some of that work that has to be done before we can just kick off all the agents. Like here's our database schema, for example. Then we send the agents to work in parallel. And this has gotten very reliable results for me versus just telling Claude, spin up an agent team to do XYZ without any additional instructions. And running this is super easy. So all you have to do is follow the instructions in the readme. And like I showed earlier, I even have instructions for how to install Tmux and then enable the experimental feature, copy this into the skills directory, either global or for your project. And then that'll give you the command. And so you can run slash build with agent team. You give it the path to the plan that you've created already, and then you can define the number of agents for the team or also let Cloud Code figure that out based on your plan. So it can be very, very dynamic. So I have an example here in my Tmux terminal. I pointed it to a plan for a brand new project. So I'm starting something from scratch and I'm going to have a team of three agents. And so I'll send this in and it'll look very similar to the demo that I showed you earlier for the code review. But this one's a lot more intricate. We're building an entire project that has to think quite deeply about the agent team that it'll create. And we'll see it spin that up in a little bit here. All right, so take a look at this. It's a fresh project, and it's defined the contract chain. So we need things to be set up at least partly in the database before we can even go to the back end. And then same thing with back end before we go to the front end. So it made the decision here. This is all dynamic, just based on the instructions I gave it, to spawn the database agent first. So it's the most upstream in the contract chain. So its first job, oh, I lost that there. Its first job is to build the database layer and then send me its contract. So it doesn't have to be... done done. It just has to send the contract, then it can spin up the backend agent. So we're still going to have some parallel work, but there's a little bit of the groundwork it has to lay first. And there we go. The database agent sent the contract back to the lead agent. So the groundwork was done. The lead agent knew that. And so it started the backend agent as well. And then I kicked off another request. So the database agent keeps working actually. And so we're seeing this all happen in parallel still, but we had a much smarter flow. And so we'll see the front end start in a bit as well. I'm not going to show this full example here because the point more is to show the intelligence up front. And I really encourage you to try this command for yourself. Just see the consistency for creating these teams based on the plans, managing the terminals. It's so powerful. Once you have a bit of instruction to cloud code for how you specifically want to use agent teams. So I'd also encourage you to adjust the skill and the command as you're using it, make it more to your use case and how you want to work with these teams because there's a lot of customization that you can do for the specific coordination as well. Like I'm doing this contract first approach. You can do whatever your heart desires. So that, my friend, is all that I got for you right now on the new Agent Team feature. Super powerful stuff. Like I said at the start of the video, I really feel like I am peering into the future of agentic development. But like we've talked about, it is far from perfect right now. And so I'll definitely be covering it in the future as Anthropic continues to improve it once it's beyond the experimental feature. And also once I work on the skill and continue to use agent teams better and better. And so if you appreciate this video and you're looking forward to more things on agent teams and agentic coding, I would really appreciate a like and a subscribe. And with that, I will see you in the next video.

Claude just shipped Agent Teams and it changes the game of AI coding. Instead of one agent doing everything sequentially, you can now spin up multiple agents that communicate with each other in real time, share a task list, and coordinate their work.

This is fundamentally different from subagents. Subagents work in isolation and report back. Agent Teams actually talk to each other, divide work intelligently, and you can interact with each agent directly. I'll show you exactly how it works, how to set it up (Windows, Mac, and Linux), and the use cases where it absolutely dominates traditional coding workflows.

~~~~~~~~~~~~~~~~~~~~~~~~~~

- Join me at the Sonar Summit (free global virtual event) on March 3rd! I'll be speaking on building self-validation and guardrails into AI coding systems.
https://fandf.co/4rjEkz0

~~~~~~~~~~~~~~~~~~~~~~~~~~

- The Dynamous Agentic Coding Course is now FULLY released - learn how to build reliable and repeatable systems for AI coding: 
https://dynamous.ai/agentic-coding-course

- Agent team skill to tackle any plan (my resource for you):
https://github.com/coleam00/context-engineering-intro/tree/main/use-cases/build-with-agent-team

- Excalidraw diagram (subagents vs. agent teams):
https://github.com/coleam00/context-engineering-intro/blob/main/use-cases/build-with-agent-team/AgentTeamsVsSubagents.png

- Agent Teams docs: 
https://code.claude.com/docs/en/agent-teams

- C compiler blog post: 
https://www.anthropic.com/engineering/building-c-compiler

~~~~~~~~~~~~~~~~~~~~~~~~~~

0:00 Intro to Claude Code Agent Teams
3:14 Get Started Quick
5:15 Demo: Creating an Agent Team
8:16 Sonar Summit
9:52 Agent Teams vs. Subagents
14:12 Limitations of Agent Teams
15:41 My Custom Agent Team Skill
17:34 Advanced Building Demo
19:39 Final Thoughts

~~~~~~~~~~~~~~~~~~~~~~~~~~

Join me as I push the limits of what is possible with AI. I'll be uploading videos weekly - at least every Wednesday at 7:00 PM CDT!