Part 4 of 6

/team — Parallel & Cross-Domain Execution

ai cagents claude team parallel waves strategic

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

/run works one task end to end. /team works many at once, because the three pages you have to build, the four blog posts you have to write, or the five test suites you have to stand up don't depend on each other — and running them one after another means waiting for each to finish before the next starts.

The difference isn't only speed. /team adds a coordination layer: work gets grouped into waves, each wave runs in parallel, and a quality gate validates before the next wave begins. If something fails in one wave, you know before the next wave builds on top of it. That's the gap between working through a list and running a team — and when the work spans more than one business domain, it's the same command that runs the whole organization.

When to reach for it

Reach for /team when you have three or more independent items that could run at the same time, or when the work crosses domains:

Building multiple pages or features that don't share dependencies
Writing a batch of content pieces on different topics
Standing up test suites for separate modules
Coordinating a launch where engineering, marketing, and docs all ship at once

Use /run instead for a single task, or when each step needs the previous step's output. Chaining dependent work through /team gains you nothing — the waves end up sequential anyway. The same task delegated to the wave engine is /run <task> --team; reach for it when a /run you've already framed turns out to be more parallelizable than you thought.

The practical minimum is three items. Two run faster as back-to-back /run calls — the second starts the moment the first returns, with none of the wave overhead. At three or more, /team starts paying for itself.

How waves work

/team doesn't throw everything at a wall at once. It builds a dependency graph and groups work into waves. A wave is a batch of teammates fired together; all of them finish, a quality gate runs, and only then does the next wave start.

The teammates are not the workers. Each teammate is a controller — it questions specialists, synthesizes, and spawns its own execution agents to do the actual work. A teammate never edits a file directly. That separation is what lets one /team run hold a dozen moving pieces without any one of them implementing past its brief.

The shape of a full multi-wave run is consistent:

Wave 0 — scaffolding and contracts. Before anyone implements, one wave establishes the shared surfaces: the interfaces, the file layout, the contracts every later wave builds against. Get this wrong and every parallel wave downstream inherits the mistake, which is exactly why it goes first and gets gated.
Middle waves — parallel implementation. Independent work runs simultaneously, each teammate controlling its own slice against the Wave 0 contracts.
Final wave — integration and validation. The pieces come together, the validator checks the whole against the original ask, and the run reports.

Agents, three ways

"Agent" collides across products. A cAgents Agent is a primitive of this plugin — a teammate or an execution agent spawned inside a /team run. It is not a Claude Code subagent (the file at .claude/agents/<name>.md) and not a Cowork Agent (the web-product runner). Same word, three surfaces — see the glossary entry for the full disambiguation. Inside this article, agent always means the cAgents kind.

A quality gate failure is reported in the wave summary; check it before assuming everything passed. The gate is what separates /team from running several /run commands in separate tabs — you get one coherent view of what succeeded, what didn't, and whether it's safe to proceed.

Wave 0:  [contracts / scaffolding]
              ↓  quality gate
Wave 1:  [Task A] [Task B] [Task C]   ← parallel teammates, each a controller
              ↓  quality gate
Wave 2:  [integration + validation]

For a small batch — "build these three pages," "write these four posts" — the work collapses into a single parallel wave with one gate at the end. The full Wave-0-through-final shape shows up on larger, more entangled jobs.

How many waves, how many teammates

Wave count tracks complexity. A Tier 3 (complex) request defaults to five to seven waves; the engine decides the split from the dependency graph. You can set a floor with --waves <N> — it's a minimum, not an exact count, so the engine can add waves if the graph demands them but won't drop below your number.

Teammates per wave default to five (--members <N>). That caps parallelism per wave, not total agent count: eight independent items with --members 4 run as two waves of four rather than one wave of eight. Lower it to manage API cost or to review intermediate results; raise it when you genuinely want the whole batch live at once and you've accepted the load.

--members is a per-wave ceiling. The engine still spawns one teammate per item — the flag only governs how many run concurrently before the next batch starts.

Walkthrough — building pages in parallel

/run built the homepage and navigation from the design spec. Three pages are left — About, Portfolio, and Blog listing — and none depends on another's output. The panel on the right has the prompt that drafts this task list and composes the invocation; here is the shape of what comes back once you submit it.

[team] Analyzing task list...
[team] Identified 3 independent tasks → assigning to Wave 1
[team] Spawning teammates (each controls its own execution agents)...

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

All three controllers run simultaneously, each spawning execution agents under it. You see interleaved progress, then the gate:

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

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

Three pages that would have taken three sequential /run invocations — and the wait for each to finish before the next started — are done in the time it takes to build one.

Walkthrough — research-then-output across two waves

Now the dependency is real. Three podcast episodes each need a research package first, then a script built from that research — you can't write a historically accurate narrative without the sources. /team detects the dependency and splits the work:

[team] Analyzing task list...
[team] Detected dependency: scripts require research packages as input
[team] Wave 1: 3 research tasks (parallel)
[team] Wave 2: 3 script tasks (parallel, depends on Wave 1)

Wave 1 builds three research packages in parallel. The gate runs before any script is written — and it can forward a note into the next wave's brief:

[quality-gate] Reviewing Wave 1 outputs...
[quality-gate] research-2-lead ✓ PASS - 14 sources, timeline complete
[quality-gate] research-3-lead ✓ PASS - 12 sources; NOTE: episode intersects
              with a sensitive historical event. Sensitivity flag added
              to the Wave 2 brief.
[quality-gate] research-4-lead ✓ PASS - 11 sources, timeline complete

[team] Wave 1 complete. 3/3 passed. 1 note forwarded to Wave 2.
[team] Spawning Wave 2 teammates...

The wave structure is the guarantee: the research is validated before anyone writes a word of script, and the sensitivity flag propagates automatically. That's what /team earns over six separate /run commands — the gate between waves does more than check word counts, it carries context forward.

When the work spans domains: strategic mode

Everything above is parallel work inside one domain — three pages, four posts, three research packages. The moment the work crosses business domains, the problem changes shape. A launch isn't parallel; it's coordinated. Engineering ships a feature, marketing announces it, docs explains it, and all three have to describe the same product on the same day. Run those as independent waves and marketing announces a feature engineering cut.

/team handles this with strategic mode. It auto-enables the moment the router detects two or more domains in your request (domain_count >= 2) — you don't ask for it, the work asks for it. Strategic mode prepends a C-suite coordination layer to the front of the wave plan:

Wave 0 — executive analysis. The CEO agent reads the initiative and sets strategic framing: what success looks like, what the constraints are, how the domains should prioritize. Each domain lead — CTO for engineering, CMO for marketing, CPO for product — analyzes its own slice against that framing.
Wave 1 — deliberation. The domain plans are checked against each other before any work starts. This is where the cross-domain conflicts surface: marketing's plan referencing a feature that isn't in engineering's scope, two domains booking the same slot, a resource one domain assumes that the org doesn't have.
Wave 2 — unified strategic brief. The reconciled plan becomes a single brief every downstream domain executes against. One source of truth, written before a line of work is done.
Wave 3..N — per-domain dispatch. Each domain's work runs as its own quality-gated wave, controlled by that domain's lead — tech-lead driving engineering, marketing-strategist driving growth — exactly the wave mechanics from the first half of this article, now riding on top of a coordinated brief.

The difference from flat multi-wave is the planning pass. Flat /team runs parallel work and gates between waves. Strategic mode runs a full cross-domain planning pass first, so marketing's announcement references the features engineering actually committed to, and the user guide documents the product that actually shipped.

graph TD
    CEO[CEO Agent<br/>strategic framing]:::exec --> CTO[CTO → tech-lead<br/>Engineering]:::lead
    CEO --> CMO[CMO → marketing-strategist<br/>Marketing]:::lead
    CEO --> CPO[CPO<br/>Docs / Product]:::lead
    CTO --> E[Deploy + QA waves]:::work
    CMO --> M[Announcement + social waves]:::work
    CPO --> D[User guide + FAQ waves]:::work
    classDef exec fill:#14b8a6,stroke:#14b8a6,color:#141414
    classDef lead fill:none,stroke:#ca8a04,color:#f4f4f5
    classDef work fill:none,stroke:#14b8a6,color:#f4f4f5

You can force the framing onto a single-domain request with --strategic — useful when one domain's work is big enough to want an executive plan over it. You can suppress it with --no-strategic when the router over-detects and you want flat parallel waves. Most of the time you touch neither flag; the domain count decides.

Strategic mode is the heaviest way to run cAgents. It spins up an executive layer, multiple domain leads, and execution agents under each — a full planning pass plus per-domain waves. That's real runtime and real token usage. It earns its keep when the outputs genuinely have to agree with each other from the start. When the work is actually sequential — finish engineering, then hand to marketing — that's two /run calls, not a strategic run.

Walkthrough — launching a website (strategic mode)

The site is built. Launching it is no longer an engineering task: engineering deploys and runs final QA, marketing writes the announcement and social posts, docs writes a quick-start guide. Three domains, three outputs that have to land together and agree with each other. Because the request names more than one domain, strategic mode enables on its own — the panel on the right has the prompt that scopes the domains and composes the invocation. The run opens with the executive layer:

[team] domain_count = 3 → strategic mode enabled

Wave 0 — CEO Agent: Analyzing initiative scope...
  → 3 domains identified: Engineering, Marketing, Docs
  → CTO (tech-lead): plan deploy + final QA
  → CMO (marketing-strategist): plan announcement + social thread
  → CPO: plan quick-start guide

Wave 1 — Deliberation:
  → Marketing plan references feature list — pulling from Engineering scope
  → Docs plan references site structure — pulling from Engineering scope
  → No conflicts. Plans consistent.

Wave 2 — Unified strategic brief written.
  → Proceeding to per-domain dispatch...

Then the per-domain waves run with the same gate mechanics as flat /team, and the run closes with a synthesis check across domains:

Wave 3..N — per-domain execution:
[Engineering] ✓ Final QA (1 issue found + fixed), deployed to production
[Marketing]   ✓ Launch announcement + 6-post social thread
[Docs]        ✓ Quick-start guide (three main sections)

CEO Agent: Synthesizing outputs...
  → Announcement references the feature set that actually shipped ✓
  → User guide sections match live site structure ✓
  → Social posts link to correct URLs ✓

Launch package ready.

All three tracks ran, cross-checked each other, and produced a coherent package. The synthesis pass is the payoff — without it you'd be passing context between three sessions by hand, checking that the social copy says what the docs say.

Walkthrough — a cross-domain catch the gate makes for you

The value of strategic mode is the conflict you didn't know was there. A restaurant opening names three domains — operations, marketing, staffing — and the deliberation wave catches that two of them booked the same event:

Wave 1 — Deliberation:
  → ⚠ Coordination dependency detected: the influencer dinner (Marketing)
    and the soft-opening dinner (Operations) are the same night, same venue.
    Consolidating into a single joint plan in the unified brief.

Marketing planned a curated influencer event. Operations planned a soft-opening test run for the kitchen. Same date, same room, two planning documents with different guest counts and different purposes. The deliberation pass merged them into one event that serves both goals before either domain executed against the wrong assumption. A flat parallel run would have produced two conflicting dinners; the planning pass produced one.

When a domain output later wants a fix — the press release lists a menu item that got cut, the staffing schedule misses the all-hands — that's a follow-up /run on the specific artifact, not a re-run of the whole organization. Route the heavy planning once; patch the leaves cheaply.

Flags worth knowing

Flag	What it does
`--waves <N>`	Set a floor on wave count. The engine can add more if the dependency graph needs them, but won't drop below `N`. Tier 3+ defaults to 5–7.
`--members <N>`	Cap teammates running concurrently per wave (default: 5). With more items than this, the wave splits into batches. Lower for cost or intermediate review.
`--strategic`	Force the C-suite planning layer onto a single-domain request.
`--no-strategic`	Suppress strategic mode when the router over-detects domains. Runs flat parallel waves.
`--dry-run`	Show the wave plan and groupings without executing. A few seconds; catches a misread before you spend real time.
`--template <id>` / `--no-template`	Apply (or skip) a saved wave template for a recurring batch shape.

What to watch for

Write each item like a brief, not a specification. Tell the teammate 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 altitude. The implementation is the teammate's job; over-specify and you've wasted the controller layer that was supposed to make those calls.

Dry-run a large batch first. The wave plan shows how items grouped and which dependencies the engine detected. It takes seconds and catches a misunderstanding — a hidden dependency, an over-eager strategic detection — before you spend real time on execution.

Don't force dependent tasks into the same wave. If task B needs task A's output, the engine should put them in separate waves — and it usually detects that. But if you write the briefs so the dependency is invisible, B starts in the same wave as A with nothing to read. Name the dependency in the brief, or run A as a /run first.

Teammates don't share memory mid-wave. When several are building parts of one system — three pages of one site — the brief is the only coordination channel. Point all of them at the same style guide, design spec, or component library. Anything you need consistent across parallel outputs has to live in the brief, repeated per item, not assumed.

When you're done

The website has a homepage (from /run) and three more pages (from a flat /team wave). The launch shipped through strategic mode, with engineering, marketing, and docs coordinated under one brief and reconciled at the end. The same command did both jobs — the domain count decided which shape it took.

What you haven't seen yet is where all of that was recorded. Every wave, every teammate, every gate verdict, every synthesis flag landed on disk as the run executed, in a session directory you can open and audit.

Previous: Part 3 — /run: Execute Tasks with Agents is the single-domain pipeline /team parallelizes.

Next: Part 5 — Sessions: Under the Hood opens the directory where every /team run leaves its record, so you can resume, audit, and trust what the waves did.

The panel on the right has the prompts that run a wave end to end — flat or strategic — and leave a deterministic record of what you ran and what came back.

Part 4 of 6