/org - Cross-Domain Orchestration

ai cagents claude org orchestration strategy cross-domain

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

This is Part 5 of a 10-part series on cAgents. Previous: /team - Parallel Multi-Agent Execution | Next: /optimize - Performance and Efficiency

Most tasks live in one domain. You're building a feature (engineering), writing a post (content), or auditing a process (operations). /run and /team handle those well. But some tasks don't respect domain boundaries - launching a product, shipping a rebrand, rolling out a new service. These require engineering and marketing and docs to move together, and coordinating them manually is where things fall apart.

/org is built for that. It spawns a layer of C-suite agents - CEO, CTO, CMO, and whichever domain leads the task requires - that treat your initiative like an executive team. The CEO sets the strategic direction. Each domain lead plans their piece. Execution agents do the actual work. Results roll up and get reconciled into a coherent outcome.

You won't need this most days. I use it maybe once a month. But when a launch requires engineering, marketing, and docs to ship coherent outputs at the same time, it's the right tool - and doing it manually is the kind of coordination work that eats a whole day.

When to Use This

Use /org when your task genuinely spans two or more business domains and those domains need to coordinate - not just run in parallel, but produce outputs that reference each other.

Good fits:

Launching a product or service (engineering ships it, marketing announces it, docs explains it)
Running a campaign with cross-functional dependencies (content, sales enablement, customer support)
Executing a rebrand (design, engineering, marketing, legal all involved)
Building out a new business function that touches multiple teams

"Cross-domain" means different disciplines with different goals, not just multiple tasks. Writing five blog posts is parallel content work - use /team. Writing a blog post, a pitch deck, and a support FAQ that all need to align on messaging? That's cross-domain - use /org.

Use /run or /team instead when:

The work stays within one domain, even if it's complex
You need parallel execution without strategic coordination
The task is a single deliverable, even a large one

/org is the most resource-intensive command in cAgents. Match the tool to the task.

How C-Suite Agents Work

When you run /org, it doesn't just fire off a batch of agents. It instantiates an organizational hierarchy that mirrors how functional teams actually work.

The CEO agent reads your initiative and sets the strategic framing - what success looks like, what the constraints are, how the domains should prioritize. Each domain lead (CTO for engineering, CMO for marketing, VP of Support for docs, etc.) receives that framing and produces a domain-specific execution plan. Those plans are checked against each other for consistency before any work starts. Then execution agents carry out the work within each domain, under the coordination of their domain lead, and results roll back up to be synthesized.

The key difference from /team is the coordination layer. /team runs tasks in parallel and applies quality gates between waves. /org runs a full planning pass first, ensuring the work across domains is coherent before execution begins - so marketing's announcement references the features engineering actually built, and the user guide documents the product that actually shipped.

graph TD
    CEO[CEO Agent] --> CTO[CTO - Engineering]
    CEO --> CMO[CMO - Marketing]
    CEO --> VP[VP Support - Docs]
    CTO --> E1[Deploy site]
    CTO --> E2[Final QA]
    CMO --> M1[Write announcement]
    CMO --> M2[Social media plan]
    VP --> D1[User guide]
    VP --> D2[FAQ]

Each domain lead reports back to the CEO agent, which reconciles the outputs and flags any inconsistencies - for example, if marketing's post mentions a feature that wasn't included in the engineering scope.

Walkthrough -- Launching a Website

You've spent the past few articles building a website. The homepage is done, the inner pages are built, the content is polished. Now you're launching - and that's not just an engineering task anymore.

Engineering needs to deploy the site and run final QA. Marketing needs to write the launch announcement and line up the social posts. Docs needs a user guide so visitors can actually get value from day one. These three outputs need to be consistent with each other, and they need to land at the same time.

Here's how you run it:

/org "Launch the new portfolio site. Engineering: deploy to production and run final QA. Marketing: write a launch announcement post and a social media thread. Docs: write a quick-start user guide covering the three main sections of the site."

What you'll see:

/org initializing...

CEO Agent: Analyzing initiative scope...
  → 3 domains identified: Engineering, Marketing, Docs
  → Coordinating domain leads...

CTO: Planning engineering execution
  Wave 1: Pre-deployment checklist, final QA pass
  Wave 2: Production deployment, smoke test

CMO: Planning marketing execution
  Wave 1: Draft launch announcement post
  Wave 2: Social media thread (Twitter/X, LinkedIn)
  → Coordinating with Engineering for feature list

VP Support: Planning docs execution
  Wave 1: Site structure outline
  Wave 2: Quick-start guide (three main sections)
  → Coordinating with Engineering for accurate feature details

CEO Agent: Cross-domain plan validated. No conflicts.
  Proceeding to execution...

[Engineering] ⚠ QA pass - 1 issue found (broken image path on portfolio page)
[Engineering] ✓ Issue fixed, re-validated
[Engineering] ✓ Deployed to production
[Marketing]   ✓ Launch announcement drafted (823 words)
[Marketing]   ✓ Social thread drafted (6 posts)
[Docs]        ✓ Quick-start guide complete (1,200 words)

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

Launch package ready.

All three tracks ran, cross-checked each other's outputs, and produced a coherent launch package. No manual coordination required on your end. Ask Claude "show me the launch package" and it will pull together the outputs from all three domains.

Walkthrough -- Content Strategy Launch

You've built out a content marketing strategy over the past few articles - you have a channel plan, four published posts, and clear messaging. Now it's time to activate the full launch: get the word out, equip the sales team, and prepare support for incoming questions.

That means marketing (social media launch plan), sales (pitch deck with the content angle), and support (FAQ for common questions about the content program). Three domains, all needing to reflect the same strategy.

/org "Full launch of the content marketing program. Marketing: write a social media launch plan for the first two weeks. Sales: create a one-page pitch deck showing the content program as a trust-building asset. Support: write an FAQ covering the top 10 questions customers are likely to ask about the new content."

The org layer handles the coordination that would otherwise fall on you:

CEO Agent: Analyzing initiative scope...
  → 3 domains identified: Marketing, Sales, Support
  → Strategic framing: content program as trust/credibility signal

CMO: Drafting two-week social launch plan
  → Platform breakdown: LinkedIn (primary), newsletter, Twitter/X
  → Coordinating with Sales on messaging tone

CSO: Creating one-page pitch deck
  → Positioning: content program as sales enablement asset
  → Pulling key stats and messaging from Marketing plan

VP Support: Writing customer FAQ
  → 10 questions identified from strategy documents
  → Coordinating with Marketing to align on program description

CEO Agent: Cross-domain plan validated.

[Marketing]  ✓ Two-week social launch plan (8 posts, 3 platforms)
[Sales]      ✓ One-page pitch deck (5 slides, PDF ready)
[Support]    ✓ FAQ document (10 Q&As, 1,400 words)

CEO Agent: Synthesizing outputs...
  → Pitch deck messaging consistent with social plan ✓
  → FAQ description of content program matches Marketing copy ✓

Launch package ready.

Without /org, you'd be passing context between three separate sessions, manually checking that the pitch deck says the same things as the social copy, and making sure support isn't describing the program in a way that contradicts marketing. The CEO agent does that work. When it's done, just ask Claude to show you the results - it knows where everything landed.

Key Flags

Flag	What It Does
`--domains <d1,d2>`	Specify which C-suite domains to involve. Skips auto-detection. Example: `--domains "engineering,marketing,legal"`
`--dry-run`	Generate the org structure and execution plan without running it. Useful for scoping before committing.

Tips & Gotchas

Start small. Before reaching for /org, ask whether /run or /team would do the job. Most tasks that feel cross-functional are actually sequential - finish the engineering work, then hand off to marketing. That's two /run calls, not an /org. Use /org when the outputs genuinely need to be consistent with each other from the start.

Use --interactive the first few times you run /org. Reviewing the cross-domain plan before execution lets you catch scope mismatches early - for instance, if the CEO agent pulled in Legal when you didn't need it, or if Marketing's scope is broader than you intended. It's much cheaper to adjust the plan than to re-run execution.

/org is the heaviest command in cAgents by a significant margin. It spins up multiple domain leads plus execution agents in each domain, runs a full planning and synthesis pass, and produces substantially more output than other commands. This translates to longer runtime and higher token usage. Don't default to it because it sounds impressive - use it because the task actually requires cross-domain coordination.

The CEO agent's synthesis pass catches obvious inconsistencies but isn't infallible. Always review the final outputs, especially where domains reference each other's work. Check that the announcement post reflects what engineering actually built, and that the FAQ describes the product that actually shipped. The synthesis pass reduces the review burden - it doesn't replace it.

The progression from /run to /team to /org maps roughly to task complexity. Single task → /run. Multiple parallel tasks in one domain → /team. Work that spans multiple domains with coordination requirements → /org. When in doubt, start simpler - you can always escalate, and the simpler commands give you faster feedback.

Up next: The site is live and the content is out - but performance isn't where you want it. Part 6: /optimize - Performance and Efficiency covers how to detect and fix performance issues with rollback safety and before/after metrics.

Previous: /team - Parallel Multi-Agent Execution | Next: /optimize - Performance and Efficiency