Learn to orchestrate multi-agent systems using the TeamCreate tool.
Most Claude Code sessions involve one agent handling one task. You give it a prompt,
it works through a to-do list, and you review the output. This works well for focused tasks.
But complex projects have multiple workstreams. A web application has a frontend, a backend,
and a QA review. A research project has gathering, synthesis, and critique. When these
workstreams can run in parallel, a single agent becomes the bottleneck.
The TeamCreate tool solves this.
Agent teams are groups of specialized sub-agents that:
- Are created and managed by your main Claude Code session (the orchestrator)
- Share a common task list
- Can communicate directly with each other
- Run in parallel on their respective workstreams
Standard sub-agents work independently and send their result back to the main agent.
Agent teams work collaboratively -- agents hand off to each other and review each other work.
The canonical example: a front-end developer and a back-end developer both submit work to
a QA agent. The QA agent finds three critical issues. The main orchestrator sends the work
back. On the second pass, all three issues are resolved -- without human intervention.
Agent teams are disabled by default. To enable them:
Follow this structure when creating a team:
State the goal first. Agents wake up with no prior context. Tell the main agent a clear
goal so each sub-agent understands what it is building and why its teammates are present.
Define each agent by role and output. Be specific about deliverables.
Name the communication paths. Tell each agent when to message which teammate and why.
Example structure (using 4-space indented code block):
Goal: build a full-stack app with REST API and React frontend.
Create a team of three agents using Sonnet:
- Backend developer: build the REST API. When complete, message the frontend developer.
- Frontend developer: wait for the backend message, then build the React interface.
- QA agent: review all code. Identify critical issues and return findings.
Final deliverables: running app, QA report, architecture doc.
This loop runs without human involvement. The pattern adapts to other domains:
- Writer, Editor, and Fact-Checker (content production)
- Researcher, Strategist, and Critic (analysis projects)
One of the most powerful yet least-known Claude Code features is plan approval mode. When you launch an agent team, you can require every agent to show its plan before it executes.
How to enable it:
/plan
Or in a TeamCreate prompt:
Use plan mode for all agents. Each agent must show its plan and wait for my approval before proceeding.
In plan approval mode, each agent will:
1. Read its task
2. Draft a step-by-step execution plan
3. Pause and display the plan
4. Wait for your thumbs-up before taking any action
This is invaluable when the task is high-stakes, unfamiliar, or involves production systems. You see exactly what each agent intends to do before any files are created, deleted, or APIs are called.
For routine tasks you have seen many times before, you can skip plan mode and let agents execute autonomously. For new workflows or client work, plan mode is the professional standard.
Each agent in a team operates with a permission set. Claude Code passes down the permission set from the session to all spawned sub-agents by default. But you can restrict individual agents.
Common permission patterns:
You configure this in the TeamCreate prompt or by setting agent-specific instructions in the shared CLAUDE.md.
The principle of least privilege applies to agents the same way it applies to systems. A research agent that accidentally has write access can corrupt files. Lock it down at creation time, not after something goes wrong.
When you run a team of agents, each one gets a numbered terminal pane if you are in tmux. You can watch all agents simultaneously.
tmux setup for agent teams:
tmux new-session -d -s agents
tmux split-window -h
tmux split-window -v
tmux select-pane -t 0
tmux split-window -v
Each pane runs one agent. You can see their progress, spot errors, and intervene without stopping the entire team.
Without tmux, you rely on log files. The pattern:
agent-researcher.log
agent-writer.log
agent-reviewer.log
Each agent appends to its own log file. You tail all three at once in separate terminals. This is the minimum viable monitoring setup for any production agent team.
Stopping an agent team cleanly matters. If you kill agents mid-task, you can end up with half-written files, incomplete API calls, or orphaned processes.
The graceful shutdown pattern:
In practice, this means your orchestrator agent needs a shutdown handler in its instructions:
If you receive a STOP instruction, finish your current step only.
Do not start any new tasks. Write a summary of what was completed and what was not.
Then exit.
This pattern prevents data corruption and gives you a clean audit trail of what was finished and what needs to be picked up in the next session.
| Scenario | Single Agent | Agent Team |
|---|---|---|
| Simple one-file edit | Yes | No — overkill |
| Research and write a report | Yes | Optional |
| Build a feature across multiple files | Yes | Optional |
| Full product build (frontend + backend + docs) | Possible | Preferred |
| Production system with multiple domains | No | Yes |
| Parallel independent workstreams | No | Yes |
| Task that benefits from QA after production | Optional | Yes — Builder + Reviewer |
| Campaign: research + copy + images + scheduling | No | Yes |
The rule of thumb: if the task naturally breaks into independent parallel workstreams, or if quality matters enough to warrant a dedicated reviewer, use a team. If the task is linear and fits in one context window, a single agent is simpler and faster.
The Classic Two-Agent:
- Builder + Reviewer
- Builder produces output, Reviewer checks it against spec
- Best for: code, content, reports, any output with defined quality criteria
The Research Pipeline:
- Researcher + Summarizer + Publisher
- Researcher pulls raw data, Summarizer distills it, Publisher formats and sends
- Best for: newsletters, weekly digests, competitive intel reports
The Full-Stack Team:
- Frontend Agent + Backend Agent + Database Agent + QA Agent
- Each owns its domain, QA runs at the end
- Best for: full product builds, multi-service integrations
The Campaign Team:
- Strategist + Copywriter + Designer (image prompts) + Scheduler
- Each handles its lane, all hand off to the next
- Best for: marketing campaigns, launch sequences, social media rollouts
These two videos cover the full agent teams system. If you want the live demonstration of TeamCreate, plan approval mode, and the QA pattern in action, these are the ones to watch.
Stop Learning n8n in 2026 (youtube.com/watch?v=pkSxISewcw8) — 19 min
The case for agent teams over n8n, with the three-wave automation model and team structures
How to Build Agent Teams Better Than 99% (youtube.com/watch?v=hAUlLQOPIU94) — 17 min
Live demo of TeamCreate, shared task list, QA pattern, plan approval mode, and tmux monitoring
You have covered the full stack of AI-powered work:
| Module | What you learned |
|---|---|
| Module 1 | Why prompts fail and how to fix them |
| Module 2 | Client knowledge bases and reusable skills |
| Module 3 | Claude Code installation, CLAUDE.md, and project structure |
| Module 4 | OpenClaw -- what it is and what to know |
| Module 5 | The daily AI workflow and the 3-layer system |
| Module 6 | Agentic workflows, memory, automation, agent teams |
What to do next:
The tools in this course compound. Every skill you add makes the ones you already have more powerful.
Questions? Reach out to Prime on Slack.
Found a bug or outdated info? Flag it -- this course is updated monthly.
Want to go further? Check the official Claude Code changelog at code.claude.com/docs/en/changelog.
HivePowered AI — AI Like a Pro Training