Multi-Agent Orchestration PRD

The orchestration challenge: Single-agent AI systems fail at complex software development because:

• Context overload — one agent can't hold requirements, architecture, code, tests, and documentation in context simultaneously
• Specialization gap — security review requires different expertise than UI design or database optimization
• Quality drift — without checkpoints, agents produce placeholder code, skip tests, and violate requirements
• Scope creep — agents add features not in the spec or ignore critical requirements
• Intent misalignment — agents optimize for speed when you wanted security, or vice versa

Multi-agent orchestration solves this by decomposing work into specialized agents with formal handoffs, quality gates, and requirement tracing. Instead of one overwhelmed agent, you get a coordinated team where each agent has a clear role, deliverables, and verification criteria.

Every task is classified into TRIVIAL, MINOR, STANDARD, or MAJOR tier using a weighted 5-signal matrix:

Calculation: score = (scope × 0.30) + (type × 0.25) + (risk × 0.25) + (ambiguity × 0.20) + (intent_sensitivity × 0.25)

Why intent_sensitivity matters: A simple CSS change (scope=1) normally scores TRIVIAL. But if it's changing the color of a security warning that users must notice, intent_sensitivity=4, escalating the tier to ensure proper review.

Each tier uses a different workflow. Higher tiers add more phases and stricter gates.

TRIVIAL Tier (1.0-1.5)

Characteristics: Single agent, no critic gates, no BRD extraction. For quick fixes and cosmetic changes.

MINOR Tier (1.6-2.3)

Characteristics: Split planning/implementation, advisory-only gates (log findings but don't block).

STANDARD Tier (2.4-3.2)

Characteristics: Full workflow, most gates advisory, PRE-RELEASE and COMPLETENESS gates BLOCKING. Pentest required.

MAJOR Tier (3.3-4.0)

Characteristics: Every checkpoint must pass before progression. Maximum scrutiny.

Quality gates are checkpoints where the conductor-critic agent validates deliverables. Gates can be:

• BLOCKING — workflow stops until issue resolved
• ADVISORY — findings logged, workflow continues
• SKIP — gate not executed (TRIVIAL tier only)

Critical insight: PRE-RELEASE and COMPLETENESS gates are ALWAYS blocking in STANDARD+ tiers. This ensures no half-finished implementations or broken deployments.

Every project starts with a Business Requirements Document (BRD). The workflow ensures 100% BRD traceability:

1. Requirements gathering — conductor-research agent creates BRD with numbered requirements (REQ-001, REQ-002, ...)
2. BRD extraction (MANDATORY BLOCKING GATE) — every requirement extracted to BRD-tracker.json:
   { "requirements": [ { "id": "REQ-001", "description": "User can log in with email/password", "category": "functional", "priority": "critical", "acceptance_criteria": ["...", "..."], "status": "pending", "todo_file": null, "is_placeholder": false } ] }
3. Specification decomposition — conductor-architect creates TODO spec for each requirement, links in BRD-tracker.json
4. Implementation tracking — conductor-builder updates status: pending → in_progress → implemented → tested → complete
5. Final verification (MANDATORY BLOCKING GATE) — 100% requirements must be "complete" before release

The conductor uses a capability matrix to route tasks to the right agent. Each agent declares:

• accepts — task types this agent can handle
• produces — artifacts this agent generates
• requires — dependencies that must exist before handoff
• constraints — rules this agent must follow
• intent_constraints — how this agent respects intent objectives and hard limits

Example: conductor-builder capability

Handoff validation: Before dispatching, conductor checks:

This turns agent orchestration into a type-checked workflow.

Intent engineering solves the "agent guesses wrong trade-off" problem. Instead of hoping the agent picks the right balance (speed vs security, simplicity vs features), you declare intent upfront.

The intent block in conductor-state.json has four sections:

1. Objectives (what success looks like)

2. Trade-offs (resolved upfront)

3. Delegation boundaries (what requires human approval)

4. Hard limits (never violate these)

Intent-aware agent behavior

Agents with intent_constraints in the capability matrix:

• Check trade-offs before decisions — "User wants security over speed, so I'll use bcrypt with cost=12 instead of MD5"
• Respect delegation boundaries — "This architectural change requires human approval, pausing for review"
• Never violate hard limits — "Hard limit says no GPL, rejecting this MIT+GPL dual-licensed library"
• Log intent alignment — Every decision logged with rationale referencing intent objectives

Critic validation of intent alignment

At every checkpoint, conductor-critic validates:

Hard limit violations escalate tier. A TRIVIAL task (score=1.2) that touches a hard limit (e.g., "No unauthenticated PII routes") auto-escalates to STANDARD tier (minimum) for blocking gates.

The workflow survives session restarts via conductor-state.json. Schema excerpt:

Recovery: /conduct resume reads state, verifies no steps were skipped, continues from current_step.

The conductor-completeness-validator agent runs exhaustive checks across 12 domains:

Output: completeness-report-<timestamp>.json with verdict (PASS/FAIL) and findings per domain.

When it runs: Phase 7 (after all code changes). In STANDARD+ tier, BLOCKING gate — workflow cannot complete until PASS.

The conductor-qa-review agent runs multi-model consensus reviews at checkpoints:

• Claude Opus 4.6 — primary reviewer
• Google Gemini 2.0 — adversarial perspective
• OpenAI GPT-4o — tie-breaker (if available)

Consensus logic:

Escalation rule: If 1/3 models flag CRITICAL and others don't, escalate to user. Never auto-dismiss.

Profile selection by tier:

• TRIVIAL: quick profile (single-pass, no consensus)
• MINOR/STANDARD: standard profile (2-model consensus)
• MAJOR: thorough profile (3-model consensus + adversarial prompts)

After implementation, the code-hardener agent runs automated security fixes:

• SAST scan (Semgrep, Bandit, ESLint security rules)
• Secret detection (TruffleHog, detect-secrets)
• Dependency vulnerability scan (npm audit, safety, Snyk)
• Auto-fix safe issues (unused imports, weak crypto → strong crypto)
• Generate TODO specs for complex issues requiring human review

Integration point: Runs in Phase 3 after conductor-builder, before conductor-critic POST-IMPLEMENTATION gate. Ensures security issues caught before final review.

Every agent invocation receives a unique Non-Human Identity instance ID following the pattern nhi_{agent}_{YYYYMMDD}_{hex8}. This extends agent identity from static manifest to per-invocation tracking.

The conductor tracks active NHIs in conductor-state.json under agent_instances. Each entry maps an NHI ID to its agent_id, manifest_id, spawned_at timestamp, status, parent_nhi_id, and tool_count. This enables:

• Forensic reconstruction — trace exact agent invocation chains across multi-agent workflows
• Cost attribution — associate token usage with specific invocations
• Confused deputy detection — identify when a legitimate agent is tricked into malicious actions

Hard-coded kill switches for behaviors that should never occur, regardless of manifest permissions or trust level. These are checked in the PreToolUse hook before any policy engine evaluation.

Two conductor-level protections against operational risk:

External Audit Sink

All security-relevant events are emitted to an external syslog endpoint (Wazuh compatible) in addition to local SQLite. Provides a tamper-resistant audit trail — even if an agent compromises the local audit database, the external copy persists. Fail-open: syslog delivery failures never block operations.

Cost Tracking (Denial of Wallet)

Tracks token consumption per agent invocation and per workflow. Configurable thresholds prevent runaway costs:

Cost data stored in conductor-state.json under cost_tracking with fields: token_budget, tokens_used, cost_estimate_usd, halt_on_exceed.

The conductor-ciso agent generates a C-BOM at STANDARD+ tiers — a comprehensive inventory of all cryptographic implementations in the target project with PQC readiness assessment.

Output includes migration recommendations: quantum-safe alternatives (ML-KEM, ML-DSA, SLH-DSA per NIST standards), estimated migration effort, and CNSA 2.0 compliance status. Stored in conductor-state.json under project_characteristics.crypto_implementations and project_characteristics.pqc_readiness.

6.1 Why Tiered Workflows Instead of One-Size-Fits-All?

A CSS color change and a payment processing system need different rigor levels. One-size-fits-all means:

• Over-engineering trivial tasks — running pentest on a typo fix wastes time
• Under-engineering critical tasks — skipping security review on auth changes causes breaches

Tiered workflows solve this by matching rigor to risk. The 5-signal matrix ensures objective classification.

6.2 Why Intent Engineering Over Implicit Optimization?

Without explicit intent, agents guess trade-offs:

• "Should I optimize for speed or security?" — agent guesses speed, introduces vulnerability
• "Should I add this feature?" — agent adds scope creep
• "Can I change this architecture?" — agent breaks system without approval

Intent engineering declares upfront what matters. Agents don't guess, they consult intent block. Misalignment detected at gates, not in production.

6.3 Why BRD Extraction as MANDATORY BLOCKING GATE?

Without forced extraction, agents:

• Infer requirements from vague descriptions — build wrong thing
• Skip "obvious" requirements — forget error handling, accessibility
• Lose traceability — can't prove all requirements implemented

The blocking gate ensures 100% requirements captured before any design work. No progression until BRD-tracker.json complete.

6.4 Why Capability Matrix Over Ad-Hoc Task Passing?

Without capability validation, you get:

• Type mismatches — architect produces "page_mockups", builder expects "specification"
• Missing dependencies — dispatch agent before BRD exists
• Ignored constraints — builder produces placeholder code despite "no stubs" constraint

The capability matrix turns orchestration into a type-checked workflow. Handoffs validated at dispatch, not at failure.

6.5 Why Adversarial Multi-Model Review?

Single-model review has blind spots:

• Model biases — Claude might miss SQL injection patterns Gemini catches
• Overconfidence — single model says "looks good", ships with bugs

Multi-model consensus provides defense in depth. If 3/3 agree it's safe, high confidence. If 1/3 flags CRITICAL, escalate — never auto-dismiss.

6.6 Why Completeness Validator in Phase 7?

Agents claim "done" but:

• Imports don't resolve (dev machine had package installed globally)
• Links broken (forgot to update nav after renaming page)
• Tests pass but app crashes on startup (missing env var)

Completeness validator is the "does it actually work" gate. Runs after all code changes, checks 12 domains, blocking in STANDARD+ tier.

6.7 Why State Persistence?

Software projects take days/weeks. Without state:

• Session restart = start over — lose all progress
• Can't resume from checkpoint — re-run completed phases
• No audit trail — can't prove which gates passed

State persistence in conductor-state.json enables resume from any step. Workflow survives network failures, session timeouts, even machine reboots.

7.1 With Plugin Ecosystem

Conductor is a Claude Code plugin. It uses:

• SessionStart hook — injects workflow state if conductor-state.json exists
• PostToolUse hook — validates conductor-state.json against schema after writes
• Skills — workflow-reference skill provides tier templates and phase workflows
• Commands — /conduct command is user entry point

7.2 With Memory Systems

Conductor integrates with memory plugins for:

• Procedure storage — save successful workflows as reusable procedures
• Learning extraction — capture agent improvements from retrospective analysis
• Pattern recognition — detect when current task matches known patterns

7.3 With Governance Systems

Governance plugins enforce compliance during orchestration:

• Approval gates — block external communication (e.g., email stakeholders) until user approves
• Data classification — prevent processing third-party data without classification
• Audit logging — log every agent dispatch, gate verdict, state transition
• NHI tracking — governance assigns NHI instance IDs, conductor tracks them in state
• MCP firewall — DLP screening prevents data exfiltration through MCP tool calls
• Prohibited behaviors — hard-coded kill switches block dangerous operations before policy evaluation
• Cost tracking — token budgets prevent denial-of-wallet attacks on multi-agent workflows
• External audit — syslog sink provides tamper-resistant event trail for SIEM integration

7.4 With Code Hardener

Code hardener runs in Phase 3 after conductor-builder:

Hardener auto-fixes safe issues (weak crypto → strong crypto). Complex issues generate TODO specs routed back to conductor-builder.

7.5 With Testing Infrastructure

Testing runs at multiple checkpoints:

• Phase 2 — conductor-qa creates test plan and executable tests
• Phase 3 — conductor-qa executes tests after implementation
• Phase 7 — completeness-validator verifies full test suite passes

Tests stored in git, run in Docker container (testing-security-stack) for isolation.

7.6 With CI/CD Pipelines

Phase 6 (deployment) integrates with CI/CD:

• conductor-devops generates GitHub Actions workflows
• Multi-stage Docker builds with non-root user, resource limits
• Smoke tests on staging before production deployment
• conductor-observability sets up Prometheus + Grafana dashboards

Multi-agent orchestration transforms software development from single overwhelmed agent to coordinated specialist team:

• Tier classification matches rigor to risk via 5-signal matrix
• BRD-driven development ensures 100% requirement traceability
• Intent engineering eliminates trade-off guessing
• Capability routing validates handoffs at dispatch
• Quality gates enforce verification at checkpoints
• Completeness validation catches what agents miss
• Adversarial review provides defense in depth
• State persistence enables resume from any step

The result: production-ready code with no placeholders, 100% test coverage, security validated, and every requirement proven complete.