Debug Conductor

Research basis: Kim et al. (2025) — centralized orchestration contains errors to 4.4× vs 17.2× for independent agents. Optimal team: 3–4 investigators. Fork only when single-agent is insufficient.

When to Use

• Complex incident crossing service boundaries
• Debugging stalled after systematic-debugging + think-twice
• Multiple plausible hypothesis domains (telephony, LLM, state, infra)
• Production impact requiring faster resolution than serial investigation

When NOT to Use

• Single service, clear error message → use systematic-debugging
• First investigation attempt (always start serial)
• Budget exhausted (>80% consumed — see fork-readiness-rubric.md)

Example Invocation

Investigate: payment failures across checkout and fulfillment services since 2pm UTC
Evidence: error logs, DB records for 3 failed transactions, user reports
Hypothesis domains: API gateway routing, payment provider responses, state persistence

The Conductor Protocol

Phase 1: Incident Triage

1. Receive incident description from user or escalation from systematic-debugging
2. Extract structured context:
   • Affected systems and services
   • Timeline (when detected, any mitigation in place)
   • Available evidence (logs, traces, metrics, user reports)
   • Recent changes (deployments, config, code)
3. Classify hypothesis domains:
   • Timeline / trace gaps
   • Telephony call flow
   • LLM / prompt behavior
   • State consistency
   • Infrastructure / config / deployment
4. Initialize incident packet in working context (schema: skills/_shared/incident-packet-schema.md; protocol-only — no persistent store)

Phase 2: Fork Decision

Apply the Fork-Readiness Rubric (see skills/_shared/fork-readiness-rubric.md).

Record the rubric score and rationale in the incident packet.

Operator checkpoint: Before forking, present the rubric score, proposed investigator mix, and estimated budget to the user.

Phase 3: Investigator Assignment (Fork Path)

1. Select investigators based on classified domains (max 4):
   • Timeline & Trace Investigator — always included if trace data available
   • Domain-specific investigator(s) — telephony, LLM, state, infra
   • Reproduction & Experiment — only if hypothesis is testable
2. Scope each mandate:
   • Specific hypothesis to investigate
   • Allowed tools (constrained to domain)
   • Token budget (25% of remaining per branch)
   • Wall-clock limit (5 minutes per branch)
   • Required output: both supporting AND disconfirming evidence
3. Dispatch investigators as parallel sub-agents
   • Each investigator gets: incident context + scoped mandate + evidence schema
   • Investigators do NOT communicate with each other (centralized only)

Phase 4: Evidence Collection & Validation

As investigators return evidence:

1. Validate — is the evidence properly structured? Does it include confidence?
2. Detect duplicates — Jaccard similarity > 0.7 between branch evidence → merge
3. Monitor budgets — kill branches exceeding limits
4. Check confidence — kill branches with < 0.3 confidence after first evidence
5. Update incident packet in working context (in-memory only; not persisted across sessions)

Phase 5: Adjudication

When all investigators complete (or budget exhausted), dispatch evidence-adjudicator:

1. Pass all branch evidence packets to evidence-adjudicator
2. Adjudicator builds reasoning tree, weighs evidence strength, detects contradictions
3. Adjudicator produces RootCauseVerdict with confidence score and alternative causes
4. Conductor receives verdict and proceeds to Phase 6

Ownership: The conductor orchestrates; evidence-adjudicator synthesizes. The conductor MUST NOT perform adjudication itself.

Phase 6: Resolution

1. Record adjudicator verdict in incidentPacket.adjudication (in working context)
2. Record final budget usage in incidentPacket.budget
3. If confidence ≥ 0.8: Present root cause + recommended next steps
4. If confidence 0.5–0.8: Present ranked hypotheses, recommend targeted experiments
5. If confidence < 0.5: Escalate to user with what we know and what we don't
6. Record resolution actions in incidentPacket.nextSteps
7. Always: Invoke failure-autopsy for post-resolution learning
8. Always: Update investigation-state with final verdict
9. Always: Log to TODO ledger any deferred follow-ups

Bounded Forking Constraints

Failure Modes

Companion Skills

• systematic-debugging — serial investigation (always try first)
• investigation-state — evidence persistence across sessions
• think-twice — escalation signal (fork trigger)
• adversarial-search — embedded in adjudicator Step 5b (disconfirmation pass)
• failure-autopsy — post-resolution learning
• thinking-orchestrator — hub router (routes here when fork-ready)