/team - Parallel Multi-Agent Execution

Created: March 27, 2026 | Modified: March 27, 2026

This is Part 4 of a 10-part series on cAgents. Previous: /run - Execute Tasks with Agents | Next: /org - Cross-Domain Orchestration

You've got three pages to build, four blog posts to write, or five test suites to stand up - and they don't depend on each other. Running them one at a time with /run works, but it means waiting for each task to finish before the next one starts. /team runs them all at once.

The difference isn't just speed. /team introduces a coordination layer: tasks are grouped into waves, each wave runs in parallel, and there's a quality gate before the next wave begins. If something fails in wave 1, you know before wave 2 starts building on top of it. It's the difference between working through a list and actually running a team.

When to Use This

Use /team when you have three or more independent tasks that could run simultaneously:

Building multiple pages or features that don't share dependencies
Writing a batch of content pieces on different topics
Setting up test suites for separate modules
Implementing several unrelated bug fixes
Creating documentation for a set of distinct features

Use /run instead when you have a single task, or when each step depends on the output of the previous one. Chaining dependent tasks through /team doesn't give you anything over /run - the waves will end up sequential anyway.

Use /org instead when the work crosses business domains - for example, when engineering, marketing, and documentation all need to happen together as part of a coordinated launch.

The practical minimum is three tasks. Two tasks in parallel is fine with /run - the overhead of wave coordination isn't worth it. Once you're at three or more, /team starts paying for itself.

How Waves Work

When you run /team, it doesn't just throw everything at a wall simultaneously. It builds a dependency graph and groups tasks into waves.

Here's the basic flow:

Analysis - The orchestrator reads your task list and identifies which items depend on each other and which are truly independent.
Wave grouping - Independent tasks get grouped into the same wave. Anything that depends on a wave-1 result goes into wave 2.
Parallel execution - All tasks in a wave run at the same time, each handled by its own agent.
Quality gate - Before wave 2 starts, all wave-1 outputs are validated. If something fails, you get a report. Important: by default, a quality gate failure does not block the next wave - it reports the failure and continues. Use --interactive if you want to approve each wave before proceeding.
Next wave - Wave 2 proceeds with the validated outputs from wave 1 as inputs.

For most simple use cases - "build these three pages" or "write these four posts" - everything lands in wave 1 and the quality gate runs once at the end.

Wave 1:  [Task A] [Task B] [Task C]  ← all run in parallel
              ↓
         Quality Gate
              ↓
Wave 2:  [Task D]  ← depends on A+B output

The quality gate is what separates /team from just running multiple /run commands in separate terminal tabs. You get a coherent view of what succeeded, what didn't, and whether it's safe to proceed.

Walkthrough -- Building Pages in Parallel

In the previous article, /run built the homepage and navigation from the design spec. Now you have three pages left - About, Portfolio, and Blog listing - and they're all independent. None of them depend on each other's output. This is exactly what /team is for.

/team "Build the remaining three pages for the portfolio site:
1. About page - bio, skills, and a contact form. Pull from the /designer spec at design/about-spec.md
2. Portfolio page - project grid with filtering by technology. Pull from design/portfolio-spec.md
3. Blog listing page - article cards with tag filtering and pagination. Pull from design/blog-spec.md

Each page should match the design system established in the homepage."

Once you submit, /team starts analysis:

[team] Analyzing task list...
[team] Identified 3 independent tasks → assigning to Wave 1
[team] Spawning agents...

[wave-1] about-agent    → Starting: About page
[wave-1] portfolio-agent → Starting: Portfolio page
[wave-1] blog-agent     → Starting: Blog listing page

All three agents are running simultaneously. You'll see interleaved progress:

[about-agent]     Creating components/About/Bio.tsx
[portfolio-agent] Creating components/Portfolio/ProjectGrid.tsx
[blog-agent]      Creating components/Blog/ArticleCard.tsx
[about-agent]     Creating components/About/ContactForm.tsx
[portfolio-agent] Implementing tag filter logic
[blog-agent]      Adding pagination controls

When all three finish, the quality gate runs:

[quality-gate] Reviewing wave 1 outputs...
[quality-gate] about-agent    ✓ PASS - About page complete, form validation included
[quality-gate] portfolio-agent ✓ PASS - Portfolio grid renders, filter works
[quality-gate] blog-agent     ✓ PASS - Listing page complete, pagination functional

[team] Wave 1 complete. All 3 tasks passed quality gate.
[team] No wave 2 required.

Summary:
  ✓ About page        components/About/
  ✓ Portfolio page    components/Portfolio/
  ✓ Blog listing      components/Blog/

Three pages that would have taken three sequential /run invocations - and the wait for each to finish before starting the next - are done in the time it takes to build one. The first time I ran /team on a batch like this, I kept checking the terminal because I didn't believe all three were actually running. They were.

Walkthrough -- Writing Posts in Parallel

In the previous article, /run produced the first blog post from the content strategy spec. Now you need four more posts to fill out the first month's content calendar. They're all on different topics, they don't reference each other, and they all follow the same brief. This is textbook /team territory.

/team "Write four blog posts for the first month's content calendar.
Each post should follow the voice and format guidelines in content/style-guide.md.

Posts to write:
1. '5 Things I Learned Migrating to Kubernetes' - audience: mid-level DevOps engineers
2. 'Why Your Monitoring Setup Is Lying to You' - audience: SREs and platform engineers
3. 'The Case for Boring Technology' - audience: engineering leads and CTOs
4. 'Git Workflows for Small Teams' - audience: developers at startups

Target length: 1200–1500 words each. SEO metadata included."

Four agents spin up immediately:

[team] 4 independent tasks identified → Wave 1
[team] Spawning agents...

[wave-1] post-1-agent → Starting: Kubernetes post
[wave-1] post-2-agent → Starting: Monitoring post
[wave-1] post-3-agent → Starting: Boring technology post
[wave-1] post-4-agent → Starting: Git workflows post

Each agent works independently, writing its post to match the style guide. No agent is waiting for another. When all four finish:

[quality-gate] Reviewing wave 1 outputs...
[quality-gate] post-1-agent ✓ PASS - 1,340 words, metadata included
[quality-gate] post-2-agent ✓ PASS - 1,280 words, metadata included
[quality-gate] post-3-agent ✓ PASS - 1,420 words, metadata included
[quality-gate] post-4-agent ✓ PASS - 1,190 words, needs minor length adjustment

[team] Wave 1 complete. 4/4 tasks passed quality gate.

Outputs:
  ✓ content/posts/kubernetes-lessons.md
  ✓ content/posts/monitoring-lies.md
  ✓ content/posts/boring-technology.md
  ✓ content/posts/git-workflows.md

A month's content calendar, written in parallel. The quality gate flagged the fourth post as slightly short - not a hard failure, just a note in the report. You can decide whether to follow up with /run "Expand git-workflows.md to 1200 words" or leave it.

Key Flags

Flag	Description
`--members <n>`	Max number of agents to run per wave (default: 5). Reduce this if you're managing API costs or want to limit parallel load.
`--dry-run`	Show the wave plan and task groupings without executing. Good for previewing how tasks will be assigned before committing.
`--interactive`	Pause at each quality gate and ask for your approval before proceeding to the next wave.

The --members flag controls parallelism per wave, not total agent count. With 8 tasks and --members 4, you get two waves of 4 rather than one wave of 8. This can help when you want to review intermediate results before the full set completes.

Tips & Gotchas

Write your task list like a brief, not a specification. Each task description should tell the agent what to produce and who it's for - not how to implement it. "Build a contact form with name, email, message fields and client-side validation" is the right level of detail. The implementation is the agent's job.

Use --dry-run before running a large batch. The wave plan shows you how tasks are grouped and which dependencies were detected. It only takes a few seconds and catches misunderstandings before you spend real time on execution.

Don't use /team for dependent tasks. If task B needs task A's output as its input, force them into sequence - either put them in separate waves explicitly, or use /run for task A first. Running dependent tasks as parallel wave-1 items will fail: task B will start before task A finishes and have nothing to work with.

A quality gate failure in wave 1 does not stop wave 2 by default - it reports the failure and continues unless you've used --interactive. Check the wave summary before assuming all tasks passed. With --interactive, you get a prompt after each wave so nothing proceeds without your sign-off.

Consistency across parallel outputs. When multiple agents are building parts of the same system - like three pages of one site - they need shared context to stay consistent. Give them all a pointer to the same style guide, design spec, or component library. Agents don't share memory during a wave, so the brief is the only coordination mechanism.

What's Next

The website now has a homepage (from /run) and three more pages (from /team). The content calendar has five posts ready to go. Next up: launching all of it - and a launch isn't just deploying the site. It means engineering, marketing, and documentation all moving at once.

That's where /org comes in. Where /team coordinates parallel work within one domain, /org coordinates work across domains - C-suite agents handling strategy while execution agents handle implementation.

Continue to Part 5: /org - Cross-Domain Orchestration

Series navigation: Getting Started · /designer · /run · /team · /org · /optimize · /debug · /review