06 — Agentic Workflows#

Part of Agentic-Native SDLC for Regulated Medical Device Engineering. Status: Working draft — May 2026. All numeric thresholds are placeholders pending calibration in 05-evaluation-and-validation.md. Scope: how individual and multi-agent workflows are designed, bounded, gated, and governed across the SDLC under IEC 62304, ISO 13485/QMSR, ISO 14971, FDA CSA, 21 CFR Part 11, and GAMP 5.

This document operationalizes the seven principles into concrete, buildable workflows. It assumes the reference architecture in 03-reference-architecture.md (K8s, MCP tool plane, A2A, Argo Workflows, gVisor/Kata sandboxes, policy server, deterministic hooks, durable memory, OpenTelemetry trajectory tracing) and the model fleet tiers (S/M/L/V/E) in 04-model-strategy-and-finetuning.md.

1. Workflow design principles in a regulated setting#

A workflow is a versioned, validated, change-controlled artifact — not an ad-hoc prompt chain. Every workflow MUST satisfy the following structural invariants before it is permitted to execute against a Class A/B/C codebase.

The harness is the product (P5). Workflows are expressed declaratively as Argo Workflow templates whose steps invoke agents through the harness; the LLM is a swappable component (see §3, Agent = Model + Harness). The cost-per-green-PR metric (P6) is the primary economic objective function for every workflow (see 08-token-and-gpu-economics.md).

flowchart LR
    G[Generate<br/>probabilistic] --> V[Verify<br/>deterministic gate]
    V -->|fail| R[Repair<br/>bounded loop]
    R --> V
    V -->|pass| GA[Gate<br/>policy + eval + HITL]
    GA -->|reject| R
    GA -->|approve| M[(Mainline)]
    V -->|budget/iter breach| ESC[Abstain → Escalate]
    R -->|budget/iter breach| ESC
    classDef det fill:#e8f0fe,stroke:#1a73e8;
    classDef prob fill:#fce8e6,stroke:#d93025;
    class V,GA det;
    class G,R prob;

This Generate → Verify → Repair → Gate loop is the atomic unit of every workflow in this document and is the realization of the 99.9% release-gate correctness system property (P1): individual model calls are unreliable; the loop is engineered to be reliable.

2. Operating modes: Conductor vs Orchestrator#

Two operating modes cover the spectrum from synchronous developer assistance to autonomous async batch work. A given task is routed to a mode by the policy server based on safety class, change size, and required latency.

A workflow may hand off between modes: a developer in Conductor mode dispatches a bounded task to the Orchestrator ("expand coverage on pump_controller"), reviews the resulting PR, and pulls it back into Conductor for final touch-ups. All handoffs are A2A messages with attached context manifests.

sequenceDiagram
    participant Dev as Developer (IDE)
    participant C as Conductor Agent
    participant O as Orchestrator (Argo)
    participant Sub as Sub-agents (A2A)
    Dev->>C: "implement story PUMP-142"
    C->>C: scope check (safety class B)
    C->>O: dispatch bounded task + context manifest
    O->>Sub: fan-out Planner/Coder/Test/Review
    Sub-->>O: gated PR + evidence
    O-->>Dev: HITL checkpoint (PR review)
    Dev->>C: pull back for local refinement

3. Agent anatomy — Agent = Model + Harness#

The platform's first axiom: an agent is not a model. An agent is a model wrapped in a deterministic harness that supplies capability, constraint, and evidence. The model is the only probabilistic component; everything else is engineered software under change control.

flowchart TB
    subgraph Agent
      direction TB
      M[Model — fleet tier S/M/L/V/E<br/>self-hosted, fine-tuned, open-weight]
      subgraph Harness
        I[Instructions / rule files<br/>AGENTS.md, specs/, BDD/Gherkin]
        T[MCP tool plane<br/>typed, permissioned tools]
        S[Sandbox<br/>gVisor/Kata, ephemeral, egress-deny]
        OR[Orchestration<br/>Argo steps + A2A handoffs]
        H[Hooks / guardrails<br/>pre-tool, post-edit, pre-commit]
        ME[Memory<br/>durable sessions + scoped scratch]
        OB[Observability<br/>OpenTelemetry trajectory tracing]
        PS[Policy server<br/>structural + semantic gating]
      end
    end
    M <--> I
    M <--> T
    T --> PS
    T --> S
    M --> H
    M --> ME
    Agent --> OB

The policy server sits between the model and every tool: a model may propose a write_file or run_command, but the action only executes if it passes structural rules (path allowlist, diff size, no secret egress) and semantic rules (change consistent with the active spec). This is how "determinism wraps probabilism" (P2) is enforced at the tool boundary.

4. Multi-agent decomposition pattern#

The Orchestrator decomposes a unit of work into specialized sub-agents connected by A2A handoffs. Each handoff crosses a deterministic gate. Humans sign at safety-class-appropriate checkpoints.

flowchart LR
    H[Human request / story] --> PL[Planner]
    PL -->|A2A: plan| SP[Spec / Story agent]
    SP -->|A2A: spec + Gherkin| G1{Spec gate<br/>policy + eval}
    G1 -->|approve| HC1[[HITL: spec sign-off]]
    HC1 --> CO[Coder]
    CO -->|A2A: diff| G2{Build/lint gate}
    G2 --> TE[Test agent]
    TE -->|A2A: tests+coverage| G3{Test+coverage gate}
    G3 --> RV[Review agent]
    RV -->|A2A: findings| G4{Review gate<br/>policy + eval}
    G4 --> HC2[[HITL: PR approval<br/>Class C = dual control]]
    HC2 --> IN[Integrator]
    IN -->|A2A: merge req| G5{Release gate ≥99.9%}
    G5 --> M[(Mainline / deploy)]
    G1 -.reject.-> SP
    G2 -.reject.-> CO
    G3 -.reject.-> CO
    G4 -.reject.-> CO

• Policy server is invoked inside every gate (G1–G5) and on every tool call within each sub-agent.
• Eval gates (deterministic evaluation harness, 05) sit at G1, G4, G5.
• Humans sign at HC1 (spec) and HC2 (PR); Class C requires two independent approvers at HC2 (P3).
• A2A messages are content-addressed and carry the evidence manifest forward so the Integrator can assemble a complete Part 11 record.

5. Per-SDLC-phase workflows#

Sub-template used for every phase: Goal · Agent role · Inputs/context · Tools · Deterministic gates · HITL checkpoint · Evidence · IEC 62304 activity · Model tier.

5.1 Requirements / planning#

5.2 Design / architecture#

5.3 Implementation#

stateDiagram-v2
    [*] --> Plan
    Plan --> Generate: bounded task
    Generate --> Verify
    Verify --> Repair: gate fail
    Repair --> Verify
    Verify --> Abstain: iter/budget breach
    Verify --> PR: all gates green
    Abstain --> Escalate
    PR --> [*]: diff review (HITL)

5.4 Test / QA#

flowchart LR
    C[Code under test] --> TA[Test agent]
    TA --> GEN[Generate tests]
    GEN --> R{Run tests}
    R -->|fail to author| TA
    R -->|pass| COV{Coverage ≥ θ?}
    COV -->|no| TA
    COV -->|yes| MUT{Mutation ≥ θ?}
    MUT -->|no| TA
    MUT -->|yes| TR{Req-trace complete?}
    TR -->|yes| QA[[HITL: QA review]]

5.5 Code review#

sequenceDiagram
    participant PR as Pull Request
    participant RA as Review Agent
    participant PS as Policy Server
    participant Ev as Eval Gate
    participant Hu as Human Reviewer(s)
    PR->>RA: diff + context
    RA->>PS: semantic + structural check
    PS-->>RA: pass/findings
    RA->>Ev: deterministic review eval
    Ev-->>RA: score ≥ θ
    RA->>Hu: findings + recommendation
    Hu-->>PR: approve (dual for Class C)

5.6 Deployment#

5.7 Maintenance / legacy modernization#

6. Concrete worked example workflows#

6.1 Feature implementation on a Class B module#

Scenario: Story PUMP-142 adds a configurable alarm threshold to infusion_rate_monitor (Class B).

Budget cap: workflow aborts and escalates if token+GPU spend exceeds the per-PR cap (P6, 08). No auto-merge — Class B requires human diff review (§10 anti-pattern).

6.2 AI-generated test-coverage expansion#

Scenario: Raise coverage on dosage_calculator from 71% to ≥ target without changing behavior.

flowchart LR
    BL[Baseline coverage] --> GAP[Coverage-gap analysis<br/>code graph]
    GAP --> TA[Test agent: synth tests]
    TA --> RUN{Tests green?}
    RUN -->|no| TA
    RUN -->|yes| FLK{Flaky? quarantine check}
    FLK -->|stable| MUT{Mutation ≥ θ}
    MUT -->|yes| BEH{No behavior change<br/>vs baseline}
    BEH -->|confirmed| QA[[HITL: QA lead]]
    BEH -->|drift| TA

Key controls: tests must be additive and behavior-preserving — any test that would have failed against unchanged production code is flagged as a latent defect and escalated rather than silently "fixed." Mutation testing guards against vacuous tests. Evidence: coverage delta, mutation score, requirement-test trace.

6.3 Bug fix in forensic mode (failing-test-first, evidence prompting)#

Scenario: Field complaint → defect DEF-908 in battery_health_estimator (Class C). Forensic mode enforces reproduce-before-repair.

stateDiagram-v2
    [*] --> Reproduce
    Reproduce --> WriteFailingTest: capture defect as test
    WriteFailingTest --> ConfirmRed: test fails on current code
    ConfirmRed --> RootCause: evidence-prompted analysis
    RootCause --> Fix: bounded minimal diff
    Fix --> Green: failing test now passes
    Green --> Regression: full suite + characterization
    Regression --> DualReview: Class C dual control
    DualReview --> CAPA: link to problem resolution
    CAPA --> [*]

• Failing-test-first: the defect is encoded as a test that is red before any fix; this becomes permanent regression evidence.
• Evidence prompting: the root-cause step is required to cite specific code-graph nodes, traces, and the failing assertion — no unsupported hypotheses.
• Class C: dual human control at review; fix is linked to CAPA / IEC 62304 §9 problem resolution.
• Minimal-diff policy: the repair loop is bounded to the smallest change that turns the test green; scope expansion triggers escalation.

6.4 Legacy modernization / framework migration at scale#

Scenario: Migrate ~400 modules from a deprecated UI framework to the supported one, behavior-preserving, across Class A/B code.

flowchart TB
    SC[Scope intake] --> GRAPH[Graph-native code understanding<br/>build dependency + call graph]
    GRAPH --> CHAR[Characterization test harvest<br/>pin current behavior]
    CHAR --> PART[Partition into wave batches<br/>by risk + coupling]
    PART --> FAN[Fan-out sub-agent pipeline]
    subgraph perModule[Per-module pipeline]
      MIG[Migration coder] --> EQ{Behavioral equivalence}
      EQ -->|fail| MIG
      EQ -->|pass| RV2[Review agent]
    end
    FAN --> perModule
    RV2 --> HITL[[HITL: batch review]]
    HITL --> INT[Integrator: staged merge]
    INT --> M[(Mainline)]

• Graph-native understanding: the migration is planned over the actual code/dependency graph, not file-by-file, so coupling and ordering are respected.
• Characterization tests pin pre-migration behavior; the equivalence gate is the deterministic guarantee of behavior preservation.
• Batching by risk: Class A modules may use lighter checkpoints; Class B retain mandatory diff review; any Class C in scope keeps dual control.
• Cost discipline: per-module budget caps and tier routing (M for mechanical edits, L for complex ones) keep cost-per-green-PR within bounds at scale.

7. Human-in-the-loop design#

HITL is the mechanism for risk-proportional autonomy (P3). Checkpoint placement is a function of IEC 62304 safety class.

Design measures to keep HITL effective without inducing approval fatigue:

• Dual-control for Class C: two independent qualified humans; the system enforces approver disjointness (no self-approval, no single person satisfying both).
• Batching: related low-risk approvals are grouped into a single review surface with shared context, reducing context-switch cost while preserving per-item evidence.
• Digital quiet hours: the Orchestrator respects configured quiet windows; checkpoints queued during quiet hours are surfaced at the next active window, never auto-escalated to auto-approval.
• Conditional-LGTM (merge on green): permitted only for Class A, additive, non-safety-critical changes that pass the full deterministic gate chain and the release gate; explicitly disabled for Class B/C. Every conditional-LGTM merge still produces a full evidence record and is sampled into the audit pipeline.
• Escalation routing: abstentions and budget breaches route to a named human queue, not into a silent retry storm.

8. Continuous code-review and repo-watcher agents#

Continuous agents observe the repository and act on events (PR opened, push, scheduled scan). They are deployed in three tiers by integration depth.

All tiers route every proposed action through the policy server and post evidence to the Part 11 store. Repo-watcher agents (T3) operate under strict budget caps and an action allowlist; they may propose remediation PRs but never merge to Class B/C without the §7 HITL path. Findings are linked to requirements/risk items for traceability.

9. Workflow governance#

A workflow is a validated software item in its own right and is managed under the QMS (ISO 13485/QMSR, GAMP 5).

Versioning. Each workflow (Argo template + agent configs + rule files + tool permissions) is a content-addressed, semantically-versioned artifact. The exact model+harness versions used by a run are pinned and recorded (P7 reproducibility).

Validation (tie to 05). Before promotion, a workflow is validated against the deterministic evaluation harness: golden task sets, gate-correctness measurement toward the ≥99.9% release-gate property, abstention calibration, and cost envelope. Validation evidence is part of the workflow's release record. CSA-aligned, risk-based validation depth scales with the highest safety class the workflow may touch.

Change control. Workflow changes follow the same change-control and approval path as code: proposed diff → review → eval gate → approval → versioned release. A workflow change that alters gate behavior or autonomy level requires re-validation.

flowchart LR
    WF[Workflow change proposal] --> RV[Review]
    RV --> EV[Eval harness validation\n→ 05]
    EV -->|meets ≥99.9% + cost| AP[Approval / change control]
    EV -->|fails| WF
    AP --> REL[Versioned workflow release]
    REL --> REG[(Registry — pinned)]

Cost guardrails in-loop (tie to 08). Per-step and per-workflow token/GPU/wall-clock budgets are enforced at runtime by the orchestrator and hooks. Breach behavior is deterministic: pause → abstain → escalate. Cost telemetry feeds the cost-per-green-PR metric (P6) and the economics dashboards.

Failure handling and rollback. Every workflow defines: (a) idempotent steps over ephemeral sandbox branches; (b) a one-command rollback to the last known-good mainline state; (c) a quarantine path for flaky/unstable artifacts; (d) escalation to HITL on repeated gate failure. No partial state ever reaches mainline — integration is transactional behind the release gate.

10. Anti-patterns#

Cross-references#

01-requirements.md · 02-maturity-model.md · 03-reference-architecture.md · 04-model-strategy-and-finetuning.md · 05-evaluation-and-validation.md · 07-security-and-compliance.md · 08-token-and-gpu-economics.md · 09-adoption-roadmap.md