Agent Orchestration Mapping: WO QMS → CODITECT Agents

Document Type: Architecture Specification
Version: 1.0 | Date: 2026-02-13
Pattern: Orchestrator-Workers with Evaluator-Optimizer for compliance

---

1. Agent Topology

1.1 Agent Roster

Agent	CODITECT Pattern	Autonomy	Model Tier	Checkpoint Triggers
WO Orchestrator	Orchestrator	High	Sonnet/Opus	Architecture decisions, dependency conflicts
Asset Manager	Worker	Medium	Sonnet	Production system state changes
Scheduler	Worker	Medium	Haiku/Sonnet	Resource conflicts, over-allocation
Experience Matcher	Worker	High	Haiku	Staffing gaps (no qualified person)
QA Reviewer	Evaluator	Low (advisory)	Opus	Always (human decision required)
Vendor Coordinator	Worker	Low	Sonnet	All vendor interactions
Documentation	Worker	Medium	Haiku/Sonnet	Controlled document updates

1.2 Communication Pattern

                         ┌─────────────────────────────────────┐
                         │       WO ORCHESTRATOR AGENT          │
                         │  ─────────────────────────────────── │
                         │  • Task classification               │
                         │  • Master WO decomposition           │
                         │  • State machine enforcement         │
                         │  • Child WO coordination             │
                         │  • Human checkpoint management       │
                         └───────┬───┬───┬───┬───┬───┬─────────┘
                           ┌─────┘   │   │   │   │   └──────┐
                           ▼         ▼   │   ▼   ▼          ▼
                    ┌──────────┐ ┌──────┐│┌──────┐┌───────────────┐
                    │  Asset   │ │Sched-││ │Exper-││  Vendor       │
                    │  Manager │ │uler  │││ience ││  Coordinator  │
                    │          │ │      ││ │Match ││               │
                    └──────────┘ └──────┘│└──────┘└───────────────┘
                                         │
                                         ▼
                               ┌──────────────────┐
                               │   Documentation   │
                               │   Agent           │
                               └──────────────────┘

                    ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─

                         ┌─────────────────────────────────┐
                         │   QA REVIEWER (Evaluator Loop)   │
                         │  ─────────────────────────────── │
                         │  Reviews → Feedback → Re-review  │
                         │  ALWAYS requires human approval   │
                         └─────────────────────────────────┘

---

2. Message Contracts

2.1 Intent Messages (Orchestrator → Workers)

// Master intent: triggers full WO decomposition
interface MasterWorkOrderIntent {
  type: 'MASTER_WO_INTENT';
  intent_description: string;     // "Upgrade lab workstation Win10→Win11"
  item_id: string;                // Asset being changed
  regulatory_flag: boolean;
  originator_id: string;
  job_plan_template_id?: string;  // Pre-defined decomposition template
  priority: number;
  metadata: Record<string, any>;
}

// Sub-intents: dispatched to workers
interface AssetChangeRequest {
  type: 'ASSET_CHANGE_REQUEST';
  work_order_id: string;
  asset_id: string;
  action: 'REMOVE_FROM_PRODUCTION' | 'DECOMMISSION' | 'UPDATE_STATUS' | 'TRANSFER';
  target_state: string;
  evidence_required: string[];    // ["ticketing_confirmation", "asset_tag_photo"]
}

interface SchedulingRequest {
  type: 'SCHEDULING_REQUEST';
  work_order_id: string;
  job_plan_id: string;
  constraints: {
    earliest_start: DateTime;
    latest_end: DateTime;
    required_experience: { experience_id: string; min_rating: number }[];
    required_tools: { tool_id: string; quantity: number }[];
    required_persons: { role_label: string; headcount: number }[];
  };
}

interface StaffingRequest {
  type: 'STAFFING_REQUEST';
  work_order_id: string;
  experience_requirements: { experience_id: string; min_rating: number }[];
  preferred_persons?: string[];   // Optional preference
  exclude_persons?: string[];     // Conflict of interest
}

interface VendorTaskRequest {
  type: 'VENDOR_TASK_REQUEST';
  work_order_id: string;
  vendor_id: string;
  task_description: string;
  deliverables: string[];         // ["IQ_OQ_report", "installation_evidence"]
  sla_hours: number;
}

interface DocumentationUpdateRequest {
  type: 'DOCUMENTATION_UPDATE_REQUEST';
  work_order_id: string;
  documents: {
    document_id: string;
    update_type: 'NEW_VERSION' | 'NEW_DOCUMENT' | 'ARCHIVE';
    description: string;
  }[];
  golden_image_required: boolean;
}

interface QAReviewRequest {
  type: 'QA_REVIEW_REQUEST';
  work_order_id: string;
  regulatory_flag: boolean;
  artifacts: {
    artifact_type: string;        // "IQ_OQ", "golden_image", "WI_update"
    artifact_ref: string;
    verified: boolean;
  }[];
  child_wo_summary: {
    id: string;
    status: string;
    approval_status: string;
  }[];
}

2.2 Result Messages (Workers → Orchestrator)

interface AssetChangeResult {
  type: 'ASSET_CHANGE_RESULT';
  work_order_id: string;
  success: boolean;
  asset_id: string;
  new_status: string;
  external_ticket_ref?: string;
  evidence_collected: string[];
  error?: string;
}

interface ScheduleProposal {
  type: 'SCHEDULE_PROPOSAL';
  work_order_id: string;
  proposed_start: DateTime;
  proposed_end: DateTime;
  assigned_persons: { person_id: string; role: string }[];
  confidence: number;             // 0.0 - 1.0
  alternatives?: ScheduleProposal[];
}

interface StaffingProposal {
  type: 'STAFFING_PROPOSAL';
  work_order_id: string;
  candidates: {
    person_id: string;
    experience_match_score: number;
    availability: boolean;
    conflicts: string[];
  }[];
  gaps: string[];                 // Unmet requirements
}

interface QAReviewDecision {
  type: 'QA_REVIEW_DECISION';
  work_order_id: string;
  decision: 'APPROVED' | 'REJECTED' | 'NEEDS_REWORK';
  qa_user_id: string;             // ALWAYS a human
  signature_id: string;           // Electronic signature (Part 11)
  comment: string;
  deficiencies?: string[];
}

// Guard violation: any agent can emit
interface GuardViolation {
  type: 'GUARD_VIOLATION';
  work_order_id: string;
  guard_name: string;
  violation_detail: string;
  blocking: boolean;              // true = cannot proceed
  suggested_resolution?: string;
}

---

3. Orchestration Flow: Win10 → Win11 Upgrade

3.1 Sequence

Step 1: MasterWorkOrderIntent received
        → Orchestrator creates Master WO (DRAFT)
        → Orchestrator decomposes into 6 child WOs using job plan template

Step 2: Child WO 1 — "Remove from production via ticketing"
        → Orchestrator → AssetManager: AssetChangeRequest(REMOVE_FROM_PRODUCTION)
        → AssetManager creates CMMS ticket, updates asset status
        → AssetManager → Orchestrator: AssetChangeResult(success, ticket_ref)
        → Child WO 1 transitions: DRAFT → PLANNED → SCHEDULED → IN_PROGRESS → PENDING_REVIEW

Step 3: Child WO 2 — "IT build workstation to Win11"
        → Orchestrator → Scheduler: SchedulingRequest(IT build job plan)
        → Scheduler → ExperienceMatcher: StaffingRequest(Win11 build experience)
        → ExperienceMatcher → Scheduler: StaffingProposal(candidates)
        → Scheduler → Orchestrator: ScheduleProposal(timeline, assigned persons)
        → Child WO 2 lifecycle executes

Step 4: Child WO 3 — "Vendor install instrument software + IQ/OQ"
        → Orchestrator → VendorCoordinator: VendorTaskRequest(vendor_id, deliverables)
        → VendorCoordinator manages external coordination
        → VendorCoordinator → Orchestrator: VendorArtifactAttached(IQ_OQ_report)
        → Child WO 3 lifecycle executes
        [DEPENDENCY: Waits for Child WO 2 completion]

Step 5: Child WO 4 — "Configure system + validation + golden image"
        → Orchestrator → Documentation: DocumentationUpdateRequest(golden_image, WI updates)
        → Documentation captures golden image, links to WO
        → Child WO 4 lifecycle executes
        [DEPENDENCY: Waits for Child WO 3 completion]

Step 6: Child WO 5 — "User account setup"
        → Parallel with Step 5
        → Orchestrator → Scheduler: SchedulingRequest(user admin job plan)

Step 7: Child WO 6 — "Decommission Win10 machine"
        → Orchestrator → AssetManager: AssetChangeRequest(DECOMMISSION)
        → AssetManager updates asset lifecycle, creates disposal ticket
        [DEPENDENCY: Waits for Child WOs 4 and 5 completion]

Step 8: Master WO Review
        → All children at PENDING_REVIEW or COMPLETED
        → Orchestrator → QAReviewer: QAReviewRequest(all artifacts)
        → QAReviewer prepares checklist for HUMAN QA
        → [HUMAN CHECKPOINT: QA approves/rejects]
        → QAReviewer → Orchestrator: QAReviewDecision(APPROVED, signature_id)

Step 9: Master WO Completion
        → Orchestrator transitions Master WO: APPROVED → COMPLETED
        → Final audit trail entries generated
        → All records locked (immutable)

3.2 CODITECT Pattern Mapping

WO Concept	CODITECT Pattern	Implementation
Master WO	Orchestrator	Central coordination, state machine
Child WOs	Workers	Independent execution, report back
Dependencies	Prompt Chaining	Sequential gate conditions
Resource matching	Routing	Experience/availability scoring
QA review	Evaluator-Optimizer	Review → feedback → re-review loop
Parallel children	Parallelization	Independent child WOs run concurrently
Cancellation cascade	Circuit Breaker	Failure in one child can halt others
Token budgets	Token Budget Controller	Per-child allocation with overflow

---

4. Circuit Breaker Integration

4.1 Failure Scenarios

Scenario	Circuit Breaker Action	Recovery
Worker agent timeout	Open circuit for that worker; route to backup	Half-open probe after 60s
Vendor API unreachable	Open circuit for VendorCoordinator	Notify human, manual fallback
Database unavailable	Open ALL circuits	Queue events, retry on recovery
QA rejection	Not a failure — normal flow	Create new revision, re-enter lifecycle
Dependency deadlock	Detected by DAG validator	Block and escalate to human
Budget exhaustion	Hard stop at 95%	Checkpoint: request budget increase

4.2 Agent Health Monitoring

interface AgentHealthMetrics {
  agent_id: string;
  success_rate_1h: number;        // 0.0 - 1.0
  avg_latency_ms: number;
  active_tasks: number;
  token_consumption_rate: number; // tokens/minute
  circuit_state: 'CLOSED' | 'OPEN' | 'HALF_OPEN';
  last_failure?: {
    timestamp: DateTime;
    error_type: string;
    work_order_id: string;
  };
}

---

5. Token Budget Allocation for WO Orchestration

Complexity	Master WO Budget	Per-Child Budget	QA Review Budget	Total
Simple (1–2 children)	5,000	2,000	3,000	12,000
Moderate (3–4 children)	10,000	3,000	5,000	27,000
Complex (5–7 children)	20,000	5,000	10,000	65,000
Win10→Win11 (6 children)	15,000	4,000	8,000	47,000

Model routing per agent:

Agent	Default Model	Regulatory Override
WO Orchestrator	Sonnet	Opus (if regulatory_flag)
Asset Manager	Sonnet	Sonnet
Scheduler	Haiku	Sonnet (if >10 persons)
Experience Matcher	Haiku	Haiku
QA Reviewer	Opus	Opus (always)
Vendor Coordinator	Sonnet	Opus (if regulatory_flag)
Documentation	Haiku	Sonnet (if controlled doc)

---

This mapping defines how the Work Order QMS domain model translates into CODITECT's multi-agent architecture. Every agent operates under delegated human authority with mandatory checkpoints at compliance-critical transitions.

---

Copyright 2026 AZ1.AI Inc. All rights reserved. Developer: Hal Casteel, CEO/CTO Product: CODITECT-BIO-QMS | Part of the CODITECT Product Suite Classification: Internal - Confidential