Skip to content

DR-009: Single sop.manager with Mission pattern for domain SOP authoring

Status

Accepted — 2026-04-15 · CEO-approved during Phase 1 executive rollout planning (CRO + COO kickoff authoring session)

Context

During CRO and COO kickoff package authoring on 2026-04-15, Rick asked whether sop.manager as a single agent creates a throughput bottleneck when the v1.2 operating model needs SOPs authored across 4 departments (Executive/PMO, Marketing, Revenue, Development, Operations). Two options surfaced:

  1. Single central sop.manager (current design) — one agent owns the SOP library, template, voice, versioning, and authoring workflow
  2. Multiple department-embedded sop.managers — one per department (e.g., sop.manager.rev, sop.manager.dev, sop.manager.ops, sop.manager.mkt), each with deep domain context

The concern with Option 1 is bottleneck: one agent authoring SOPs for a multi-department operating model looks single-threaded and risks becoming the critical path for process improvement. The concern with Option 2 is governance fragmentation: handoff SOPs that span departments (e.g., SOP-REV-marketing-to-sales-handoff) have ambiguous ownership and risk drifting apart when authored by siloed agents.

The tension surfaced because the SOP library at /Claude/system/sops/INDEX.md is nearly empty and sop.manager is just activating (still mid-flight on Mission M-2026-0414 authoring SOP-EXEC-council-review-v1.0). This is the right moment to lock the pattern before the backlog scales.

Decision

Keep sop.manager as a single central agent. Solve throughput via the Mission pattern (Section 10A), not via agent multiplication.

sop.manager is the Orchestrator of SOP authoring Missions. She does not author every SOP as the sole worker. Instead, for domain-specific SOPs she dispatches fresh-context workers from the department that owns the domain knowledge, then synthesizes their output into a canonical draft under her own authorial voice, versioning, and template.

Role split

Role Who What they own
Orchestrator sop.manager SOP library index, template consistency, voice, versioning (SOP-{DEPT}-{NAME}-v{X.Y}), Validation Contract authoring, council review dispatch, publication handoff to COO
Worker(s) Department agent(s) with domain expertise Domain content: criteria, thresholds, workflow steps, data requirements, tool invocations specific to their department
Scrutiny Validator chief.staff or peer agent independent of domain Structural review, cross-SOP conflict check, Section 10A.7 independence
User-Testing Validator qa.testing or QA specialist Black-box exercise of the SOP against a real scenario
Publication Approver coo Final signoff per CLAUDE.md Section 10 (interim path: CEO via chief.staff until COO Active)

Example — authoring SOP-REV-lead-qualification as a Mission

  • Orchestrator: sop.manager
  • Worker 1: vp.sales — qualification criteria, pipeline stage definitions
  • Worker 2: sales.ops — CRM field enforcement, data quality gates
  • Worker 3: category.positioning — ICP match criteria, category alignment
  • Scrutiny Validator: chief.staff (independent of revenue domain)
  • User-Testing Validator: qa.testing (black-box against a real lead)
  • Publication Approver: COO

Workers run in parallel with fresh context. sop.manager synthesizes their output into one canonical draft, invokes council review per SOP-EXEC-council-review-v1.0 trigger matrix, dispatches validators, and routes to COO for publication signoff.

Alternatives considered

Option A — Single central sop.manager with all authoring single-threaded through her

Rejected as a straw man. This was the option that created the bottleneck concern. It assumes sop.manager writes every SOP alone, which would in fact single-thread authoring. It's not the actual design.

Option B — Single central sop.manager with Mission pattern for domain SOPs (this decision)

Accepted. Combines single-voice authorial consistency with parallel domain-expert contribution via the Mission Worker pattern. Four benefits:

  1. Single voice and structural consistency — sop.manager enforces the template so all SOPs read the same way
  2. Domain expertise — workers contribute from their actual department context, not abstracted guesses
  3. Parallel execution — workers run in fresh context, not single-threaded through the Orchestrator
  4. Cross-functional coherence — sop.manager sees the whole library and catches conflicts a siloed author would miss

Option C — Multiple department-embedded sop.managers (e.g., sop.manager.rev, sop.manager.dev, sop.manager.ops, sop.manager.mkt)

Rejected. Recreates the exact problem v1.1 was designed to solve: agents optimizing for their own department without cross-functional coherence. Specific failure modes:

  • Handoff SOPs have ambiguous ownership. SOP-REV-marketing-to-sales-handoff — does the marketing sop.manager or the revenue sop.manager author it? Both sides have legitimate claims; neither has full visibility. Merge conflicts become governance debates.
  • Template drift. Each sop.manager evolves her own format. Six months in, reading across SOPs feels like reading documentation from four different companies.
  • Registry fragmentation. One INDEX.md becomes four. Version numbering diverges. Cross-SOP references break.
  • Council review gatekeeping diverges. Each department interprets trigger classes differently; mandatory triggers become advisory in one department and ignored in another.
  • Premature expansion violates Section 4. CLAUDE.md Section 4 explicitly prohibits preemptive agent expansion. New agents only on documented incident trigger. None of the four triggers have fired for sop.manager.

Option D — Hybrid: central sop.manager with lightweight department-embedded SOP editors

Keep sop.manager as the central authority; add Sonnet/Haiku-tier "SOP editor" agents embedded in each department that draft department-specific content and feed it to sop.manager for synthesis.

Rejected as redundant. This is the Mission Worker pattern by another name. The Mission pattern already gives us this — department agents serve as fresh-context workers dispatched by sop.manager. Adding "editor" agents would duplicate the capability and add coordination overhead. If the Mission pattern proves insufficient at 90-day review, revisit this as an incremental refinement.

Consequences

What becomes easier:

  • Library coherence is structural, not aspirational. One owner, one template, one voice, one versioning scheme.
  • Handoff SOPs have clear ownership. sop.manager arbitrates because she sees both sides.
  • Registry stays singular. /Claude/system/sops/INDEX.md remains the one authoritative registry; one owner.
  • Onboarding new agents is predictable. When a new department agent activates, they know where SOPs come from — sop.manager, orchestrated as Missions, with them as Workers.
  • Council review discipline stays consistent. sop.manager authored SOP-EXEC-council-review-v1.0, so she applies it uniformly across all SOP authoring Missions.

What becomes harder:

  • sop.manager must delegate aggressively. The failure mode of this model is sop.manager trying to author every SOP herself instead of dispatching Mission Workers. chief.staff must watch for this pattern and coach her toward delegation when load rises.
  • Per-SOP timeline is slightly slower than a parallel 4-agent team in naive measurement. The Mission pattern closes most of the gap but not all of it. Trade-off accepted: coherence over raw throughput at current scale.
  • Single agent = single point of failure. If sop.manager has a session-crashing bug or a cutover gap, the entire SOP pipeline stalls. Mitigation: chief.staff can temporarily cover sop.manager's Orchestrator role in emergencies (she's already the executive sponsor for SOP governance per Section 10).

Trade-off accepted: Slightly slower per-SOP throughput in exchange for library coherence, cross-functional visibility, and alignment with Section 4 expansion policy.

Review trigger (90-day revisit)

Review date: 2026-07-14 (90 days from decision date)

Revisit conditions (any one triggers review):

  1. Concurrent Mission load — sop.manager routinely orchestrating more than 3 SOP authoring Missions simultaneously for more than 2 weeks (Section 4 load trigger)
  2. Shipped timeline drift — average per-SOP shipping timeline above 5 business days from Mission launch to Active status
  3. Cross-department feedback — department agents reporting that sop.manager doesn't "get" their domain, or that Mission Worker output isn't landing cleanly into her drafts
  4. Conflict count — any SOP ships with a cross-functional contradiction that a siloed author would have caught
  5. Quality trigger — sop.manager produces conflicting outputs on unrelated SOPs (Section 4 quality trigger)
  6. Synthesis trigger — chief.staff's rollup of sop.manager's work takes more than 5 minutes (Section 4 synthesis trigger)

If a review trigger fires, the remediation order is:

  1. First — coach aggressive delegation. Is sop.manager actually using the Mission Worker pattern, or is she trying to single-thread? Fix the behavior before expanding the roster.
  2. Second — revisit Option D (lightweight department SOP editors). Add editor agents only if Mission Worker dispatch is already maximal and still insufficient.
  3. Third — revisit Option C (multiple sop.managers). Only if Option D proves insufficient and the governance fragmentation risk is judged acceptable for the throughput gain.

Adding agents is the last resort, not the first.

Heuristic for executives (derived from this decision)

When any executive is facing a high-stakes authoring or design decision, the question to ask is:

"Would a thoughtful outsider catch something I can't see from inside my own work?"

  • If yes and the stakes are high, invoke council review (whether or not the trigger matrix mandates it)
  • If no or the stakes are low, ship on the normal QA path

This heuristic applies to any agent, not just sop.manager. Council review is self-service for any agent with skill access — sop.manager authored the rules but does not gatekeep the skill.

  • [[CLAUDE]] Section 4 — Agent expansion policy
  • [[CLAUDE]] Section 10 — SOP Governance
  • [[CLAUDE]] Section 10A — Missions Execution Pattern (the throughput enabler for this decision)
  • [[DR-005-21-agent-compressed-roster]] — baseline roster philosophy (fewer agents with broader responsibility)
  • [[SOP-EXEC-council-review-v1.0]] — authored by sop.manager, defines council review trigger matrix (8 classes)
  • /Claude/missions/M-2026-0414-council-review-sop-authoring/ — the Mission where sop.manager is recursively applying this pattern to her own first SOP
  • /Claude/sessions/coo/kickoff-package.md — where the sop.manager reporting relationship nuances are laid out

Date: 2026-04-15 · Author: chief.staff · Stakeholders: ceo, chief.staff, coo, sop.manager · Next review: 2026-07-14