Orchestration Design

Date: 2026-04-21 Status: Approved

---

The orchestration layer for CCOS2 — how work enters the system, how it gets routed, how it gets decomposed, and what templates govern each type of work. Dev templates are fully defined here. Other department templates are deferred pending further design sessions.

---

Three tiers:

`` COO (future) — cross-department DAG coordination, parallel workstream management └── Claire — department-level routing, template selection, decomposition, brief validation └── Workers — execute one step, post result, know nothing about the workflow ``

COO is future-state. When cross-department projects need dependency tracking across departments, the COO decomposes them and posts department-scoped tasks to roles.orchestrator. Claire handles everything within a department.

Claire is active now. She pulls from roles.orchestrator, validates the brief, selects the template, assesses size, decomposes if needed, and dispatches work to role topics. She is the only agent that advances workflow state.

---

Five departments. Each owns a set of roles. Agents fill roles — Justin fills exec roles today; other departments have dedicated agents (current or planned).

| Department | Roles | |---|---| | dev | ba, developer, reviewer, architect | | sales_and_marketing | bdr, sales, customer_success, content, designer, podcast | | governance | finance, legal | | knowledge | researcher, librarian | | exec | justin, coo (future) |

---

Work arrives on roles.orchestrator as a task.available message:

``json { "type": "task.available", "task_id": "uuid", "department": "dev", "work_type": "dev_task", "brief": "...", "priority": "low | normal | high | urgent", "depends_on": [], "posted_at": "ISO8601" } ``

• department + work_type together select the template. Claire does not infer either.
• depends_on is optional. Array of task_ids that must complete before this task dispatches.
• priority flows through to all sub-tasks Claire creates.
• Cross-department projects arrive as multiple messages — one per department, each with their own depends_on if sequencing is needed.

---

Claire validates the brief before dispatching to brainstorm. She checks for presence only — not quality. Missing fields block the task and route to justin for completion.

| work_type | Required fields | |---|---| | hotfix | What is broken, what done looks like | | dev_task | Goals, who it serves | | initiative | Goals, who it serves, timeline, context |

Validation is inline behavior — not a formal template step. If the brief passes, Claire dispatches. If not, she posts to justin with the specific missing fields.

Brainstorm handles quality. Claire only checks presence. If a stated goal is vague or a timeline is unrealistic, brainstorm surfaces that — not Claire.

---

Single isolated bug fix. No spec, no architect.

| Step | Role | |---|---| | 1. brainstorm | ba | | 2. code | developer | | 3. pr | developer | | 4. review | reviewer |

Standard feature or improvement.

| Step | Role | |---|---| | 1. brainstorm | ba | | 2. spec | ba | | 3. arch | architect | | 4. code | developer | | 5. pr | developer | | 6. review | reviewer |

Multi-phase project. Claire decomposes into phases after arch completes.

| Step | Role | |---|---| | 1. brainstorm | ba | | 2. arch | architect | | 3. decompose | Claire (inline) | | 4+ | Each phase = dev_task workflow |

• Each phase is a full dev_task (brainstorm → spec → arch → code → pr → review)
• Phases declare depends_on other phases
• Claire dispatches phases as their dependencies resolve — parallel where possible, sequential where declared
• Phases are the unit of dependency, not individual steps

---

``json { "slug": "dev_task", "name": "Dev Task", "department": "dev", "description": "Standard feature: brainstorm → spec → arch → code → pr → review", "steps": [ { "step_num": 1, "name": "brainstorm", "role": "ba" }, { "step_num": 2, "name": "spec", "role": "ba" }, { "step_num": 3, "name": "arch", "role": "architect" }, { "step_num": 4, "name": "code", "role": "developer" }, { "step_num": 5, "name": "pr", "role": "developer" }, { "step_num": 6, "name": "review", "role": "reviewer" } ] } ``

---

Templates for sales_and_marketing, governance, and knowledge are not defined here. Each department has distinct workflows that require more detailed design. These will be addressed in a follow-up session with voice access.

Departments and roles are defined above — implementation can proceed with dev templates and the full department/role topology. Non-dev templates slot in when ready without any structural changes.

---

• [ ] Define sales_and_marketing templates: bdr, sales, customer_success, content, design, podcast
• [ ] Define governance templates: finance, legal
• [ ] Define knowledge templates: research, library
• [ ] Design COO agent and its relationship to Claire
• [ ] Define exec role topic and escalation pattern