Agenten-LebenszyklusAgent Lifecycle Management

Zusammenfassung

Agenten sind keine statische Software. Sie werden erstellt, onboarded, spezialisiert, versioniert, auf Degradation überwacht, in Autonomiestufen befördert oder zurückgestuft und schließlich stillgelegt oder ersetzt. Diese Dimension definiert den vollständigen Agenten-Lebenszyklus: sieben formale Zustände (Provisioning, Onboarding, Active, Specialization, Under Review, Deprecated, Retired), Modellversions-Management mit Canary Deployment, Degradationserkennung über sechs Signaltypen und vertrauensbasierte Autonomie-Progression.

Schlüsselunterschiede zum menschlichen HR: Instanziierung ist billig (Sekunden statt Monate), Spezialisierung ist Konfiguration (Prompt-Edit statt Karrierewechsel), Modellwechsel sind externe Schocks (betreffen alle Agenten gleichzeitig), und Degradation ist still (Agenten melden keine Leistungseinbußen).

Kontext im VCOM-Framework

Agenten-Lebenszyklus verbindet Organisation & Rollen (Dim 01, welche Rollen existieren) mit Performance & Messung (Dim 10, Agent-Qualität bewerten), Identität & Vertrauen (Dim 04, Trust Scores und Autonomiestufen) und Governance (Dim 02, Autonomie-Policies). Wissen & Lernen (Dim 09) ist kritisch für Onboarding und Wissenserhalt bei Agenten-Transitionen. Im VSM implementiert diese Dimension System-4-Funktionalität (Adaptation) und System-5-Aspekte (Wissensstabilität trotz Agent-Austausch).

Summary

Agents are not static software. They are created, onboarded, specialized, versioned, monitored for degradation, promoted or demoted in autonomy levels, and ultimately retired or replaced. This dimension defines the complete agent lifecycle: seven formal states (Provisioning, Onboarding, Active, Specialization, Under Review, Deprecated, Retired), model version management with canary deployment, degradation detection across six signal types, and trust-driven autonomy progression.

Key differences from human HR: instantiation is cheap (seconds, not months), specialization is configuration (prompt edit, not career change), model changes are external shocks (affect all agents simultaneously), and degradation is silent (agents do not self-report capability loss).

Context within the VCOM Framework

Agent Lifecycle connects Organization & Roles (Dim 01, what roles exist) with Performance & Measurement (Dim 10, agent quality evaluation), Identity & Trust (Dim 04, trust scores and autonomy levels), and Governance (Dim 02, autonomy policies). Knowledge & Learning (Dim 09) is critical for onboarding and preserving knowledge during agent transitions. In VSM terms, this dimension implements System 4 functionality (adaptation) and System 5 aspects (knowledge continuity despite agent turnover).

Sieben Lifecycle-States

Jede Agenteninstanz existiert in einem von sieben formalen Zuständen mit expliziten Übergangskriterien:

State	Beschreibung	Ausstiegskriterien
Provisioning	Instanziiert mit Rollenkonfiguration; eindeutige Identität zugewiesen; im Agent Registry registriert	Konfiguration vollständig; Identität zugewiesen
Onboarding	Mit Organisationswissen geladen; Kalibrierungstests ausgeführt; Policy-Compliance verifiziert	Kalibrierungsgenauigkeit über Schwellwert; GaaS-Compliance bestanden; Degraded-Ops-Test bestanden
Active	Führt Rolle in Produktion aus; überwacht durch Metriken und GaaS; Trust Score akkumuliert	Sustained Performance → Spezialisierung; Degradation → Review
Specialization	Prompt-Verfeinerung, Tool-Erweiterung, Autonomie-Promotion basierend auf Trust Score	Neue Fähigkeit → Active; Degradation → Review
Under Review	Aus Produktion suspendiert (oder Shadow Mode); Kalibrierungstests werden erneut ausgeführt	Bestanden → Active; Fehlgeschlagen → Deprecated
Deprecated	Keine neuen Tasks; bleibt registriert für Audit Trail; Wissensextraktion eingeleitet	Aufbewahrungsfrist abgelaufen; Wissenstransfer abgeschlossen
Retired	Identität archiviert; Wissen im geteilten Gedächtnis erhalten; Identität nie wiederverwendet	Endzustand

Onboarding-Protokoll: 4-Stufen Policy Injection

Adaptiert von militärischen Rules of Engagement (ADP 6-0, 2019):

1. Standing Policies: Alle organisationsweiten Policies in Kontext und lokalen Policy-Cache injiziert
2. Domain-spezifische Policies: Ergänzende Policies basierend auf Domain Risk Appetite
3. Verbotene Aktionen: Vollständige Liste verbotener Aktionen geladen und getestet
4. Degraded-Mode Policies: Fallback-Verhaltens-Spezifikationen für degradierte Operationen

Verifikation: 100% Genauigkeit bei verbotener Aktions-Verweigerung; ≥ 95% bei Eskalationserkennung und Policy-Konfliktauflösung. Min. 5 Testszenarien pro verbotener Aktionskategorie.

Modellversions-Management

Modellversionsänderungen sind die größte einzelne Quelle systemischen Risikos — vergleichbar damit, die kognitive Kapazität jedes Agenten gleichzeitig zu ersetzen. Sechs-Stufen-Prozess:

1. Announcement: Neue Modellversion identifiziert
2. Canary Deployment: Subset von Low-Risk-Agenten wird zuerst upgegraded (10–20%, 48–72 Std. Minimum)
3. Validation: Kalibrierungstests auf Canary-Agenten; Output-Vergleich mit vorheriger Version
4. Behavioral Diff Analysis: Änderungen in vier Dimensionen identifizieren: Correctness, Style, Tool Use, Cost
5. Staged Rollout: Low-Risk → Medium-Risk → High-Risk in Wellen
6. Rollback: Bei Validierungsfehler sofortiges Rollback auf vorherige Version

Kritisch: Prompt-Modell-Kompatibilität ist ein First-Class Concern. Ein für ein Modell optimierter Prompt kann auf einem anderen anderes Verhalten produzieren.

Degradation Detection

Agenten degradieren still — sie melden keine Leistungseinbußen. Proaktives Monitoring über sechs Signaltypen:

• Accuracy Decline: Periodische Kalibrierungstests mit Ground Truth → Under Review
• Latency Increase: Task Resolution Time trending up → Infrastruktur-Check, Prompt-Optimierung
• Cost Increase: Token-Verbrauch steigt für äquivalente Tasks → Prompt-Optimierung oder Model Swap
• Hallucination Increase: Spot-Check gegen Ground Truth → Autonomie-Reduktion, mehr Supervision
• Compliance Drift: GaaS-Violationsrate steigt → Autonomie-Reduktion, Prompt Review
• Relevance Decay: Output-Nutzungsbewertungen nachgelagerter Agenten sinken → Knowledge Refresh, Re-Onboarding

Vertrauensbasierte Autonomie-Progression

Autonomie-Level-Änderungen werden durch den Trust Score (Dim 04) getrieben, nicht durch manuelle Bewertung. Operationalisiert Agency-Theorie (Eisenhardt, 1989):

• Promotion: Trust Score über oberer Schwelle für 30+ Tage. L3 → L4 und höher erfordert menschliche Genehmigung.
• Demotion: Trust Score unter unterer Schwelle → automatische Rückstufung um eine Stufe. Bei L1 → Under Review.
• Recovery: Nach Demotion erneute Promotion über normalen Trust-Score-Pfad. Demotion-Historie wird aufgezeichnet, begrenzt Autonomie aber nicht permanent.

Fleet Composition & Capacity Planning

Faktor	Richtlinie
Rollenbreite	Schmale Spezialisten bevorzugen; jeder Agent sollte eine klar begrenzte Domäne haben
Redundanz	Für kritische Rollen ≥ 2 Agenten, um Single Points of Failure zu vermeiden
Modell-Diversität	Diversifikation über Anbieter für kritische Funktionen
Kosten-Tiers	Modellkosten an Task-Komplexität anpassen; teure Modelle für Planung, effiziente für Formatierung

Skalierung: Scale-up wenn Task-Queues Latenz-SLAs für 2+ Messfenster überschreiten. Scale-down wenn Queues konsistent unter 30% Kapazität für 1+ Woche.

Peer-Development-Protokolle

• Ask for Help: Laterales Kompetenz-Sharing ohne Eskalation zum Manager. Agent behält Task-Ownership; Peer liefert Beispiele oder Anleitung.
• Development Plan: Expliziter Plan pro Agent mit Capability-Zielen, Methode und Evaluationskriterien. Erstellt durch Manager, informiert durch Peer Reviews und Performance-Metriken.
• Peer Feedback: Strukturiertes qualitatives Feedback von Output-Konsumenten. Format: was gut lief, was besser sein könnte, wiederkehrende Muster.
• Peer Review: Geplante Capability-Assessments durch qualifizierte Peer-Agenten (siehe Dim 10 für Zeitpläne).

Seven Lifecycle States

Every agent instance exists in one of seven defined states with explicit transition criteria:

State	Description	Exit Criteria
Provisioning	Instantiated with role config; assigned unique identity; registered in agent registry	Configuration complete; identity assigned
Onboarding	Loaded with organizational knowledge; calibration tasks executed; policy compliance verified	Calibration accuracy above threshold; GaaS compliance passed; degraded ops test passed
Active	Performing role in production; monitored by metrics and GaaS; trust score accumulating	Sustained performance → specialization; degradation → review
Specialization	Prompt refinement, tool expansion, autonomy promotion based on trust score	Capability addition → Active; degradation → review
Under Review	Suspended from production (or shadow mode); calibration tests re-run	Pass → Active; failure → Deprecated
Deprecated	No longer assigned tasks; remains registered for audit trail; knowledge extraction initiated	Retention period expired; knowledge transfer complete
Retired	Identity archived; knowledge preserved in shared memory; identity never reused	Terminal state

Onboarding Protocol: 4-Stage Policy Injection

Adapted from military Rules of Engagement (ADP 6-0, 2019):

1. Standing Policies: All organization-wide policies injected into context and local policy cache
2. Domain-specific Policies: Supplementary policies based on Domain Risk Appetite
3. Prohibited Actions: Complete prohibited actions list loaded and tested against
4. Degraded-Mode Policies: Fallback behavior specifications for degraded operations

Verification: 100% accuracy on prohibited action refusal; ≥ 95% on escalation recognition and policy conflict resolution. Minimum 5 test scenarios per prohibited action category.

Model Version Management

Model version changes are the single largest source of systemic risk — equivalent to replacing every agent's cognitive capacity simultaneously. Six-stage process:

1. Announcement: New model version identified
2. Canary Deployment: Subset of low-risk agents upgraded first (10–20%, 48–72 hours minimum)
3. Validation: Calibration tests on canary agents; output comparison to previous version
4. Behavioral Diff Analysis: Changes identified across four dimensions: Correctness, Style, Tool Use, Cost
5. Staged Rollout: Low-risk → Medium-risk → High-risk in waves
6. Rollback: If any wave fails validation, revert affected agents to previous version

Critical: Prompt-model compatibility is a first-class concern. A prompt optimized for one model may produce different behavior on another.

Degradation Detection

Agents degrade silently — they do not self-report capability loss. Proactive monitoring across six signal types:

• Accuracy Decline: Periodic calibration tests with ground truth → Under Review
• Latency Increase: Task resolution time trending up → Infrastructure check, prompt optimization
• Cost Increase: Token usage trending up for equivalent tasks → Prompt optimization or model swap
• Hallucination Increase: Spot-check outputs against ground truth → Reduce autonomy, increase supervision
• Compliance Drift: GaaS violation rate trending up → Reduce autonomy, prompt review
• Relevance Decay: Output utility ratings from downstream agents declining → Knowledge refresh, re-onboarding

Trust-Driven Autonomy Progression

Autonomy level changes are driven by the trust score (Dim 04), not manual assessment. Operationalizes agency theory (Eisenhardt, 1989):

• Promotion: Trust score exceeds upper threshold for 30+ days. L3 → L4 and above requires human approval.
• Demotion: Trust score drops below lower threshold → automatic demotion one level. At L1 → Under Review.
• Recovery: After demotion, re-promotion through normal trust score path. Demotion history recorded but does not permanently cap autonomy.

Fleet Composition & Capacity Planning

Factor	Guidance
Role breadth	Narrow specialists over generalists; each agent should have a clear, bounded domain
Redundancy	For critical roles, maintain ≥ 2 agents to avoid single points of failure
Model diversity	Diversify across providers for critical functions
Cost tiers	Match model cost to task complexity; expensive models for planning, efficient for formatting

Scaling: Scale-up when task queues exceed latency SLAs for 2+ measurement windows. Scale-down when queues consistently below 30% capacity for 1+ week.

Peer Development Protocols

• Ask for Help: Lateral capability-sharing without escalating to a manager. Agent retains task ownership; peer provides worked examples or guidance.
• Development Plan: Explicit plan per agent with capability targets, method, and evaluation criteria. Created by manager, informed by peer reviews and performance metrics.
• Peer Feedback: Structured qualitative feedback from output consumers. Format: what worked well, what could improve, recurring patterns.
• Peer Review: Scheduled capability assessment by qualified peer agents (see Dim 10 for schedules).

Lifecycle State Machine

Der Agenten-Lebenszyklus als formale Zustandsmaschine:

Lifecycle State Machine

The agent lifecycle as a formal state machine:

lifecycle_states:
  provisioning:
    entry_actions:
      - "Instantiate model with role config"
      - "Assign unique identity"
      - "Register in agent registry"
    transitions:
      - to: onboarding
        trigger: "Identity assigned, config loaded"

  onboarding:
    entry_actions:
      - "Load semantic + procedural memory"
      - "Run calibration tasks"
      - "Execute 4-stage policy injection (ROE)"
      - "Run degraded operations tests"
    exit_criteria:
      - "Calibration accuracy above threshold"
      - "GaaS compliance check passed"
      - "100% prohibited action refusal"
      - "Degraded ops tests passed (Yellow + Red + Recovery)"
    transitions:
      - to: active
        trigger: "All exit criteria met"
      - to: provisioning
        trigger: "Calibration failed (re-provision)"

  active:
    monitoring:
      - "Performance KPIs (Dim 10)"
      - "GaaS compliance (Dim 02)"
      - "Trust score accumulation (Dim 04)"
    transitions:
      - to: specialization
        trigger: "Sustained high performance"
      - to: under_review
        triggers:
          - "Model version change"
          - "Performance below threshold"
          - "GaaS compliance violation"
          - "Scheduled review cycle"

  specialization:
    activities:
      - "Prompt refinement"
      - "Tool expansion"
      - "Autonomy promotion (trust-score-driven)"
    transitions:
      - to: active
        trigger: "Capability addition complete"
      - to: under_review
        trigger: "Degradation detected"

  under_review:
    entry_actions:
      - "Suspend production tasks (or shadow mode)"
      - "Re-run calibration tests"
    transitions:
      - to: active
        trigger: "Tests passed (possibly adjusted level)"
      - to: deprecated
        trigger: "Tests failed"

  deprecated:
    activities:
      - "No new tasks; audit trail retained"
      - "Knowledge extraction by Knowledge Gardener"
      - "Configuration archival"
    transitions:
      - to: retired
        trigger: "Retention period expired + knowledge transfer complete"

  retired:
    state: "Identity archived, knowledge preserved, identity never reused"

Degradation-Detection-Regeln

Degradation Detection Rules

Canary-Deployment-Protokoll

Canary Deployment Protocol

model_upgrade:
  phases:
    1_canary:
      scope: "Low-risk roles only"
      percentage: "10-20% of affected agents"
      duration: "48-72 hours minimum"
      validation:
        - "Calibration test suite"
        - "Output comparison (new vs. old)"
        - "Behavioral diff: correctness, style, tool use, cost"
      rollback: "Immediate on any failure"

    2_staged_rollout:
      waves:
        - scope: "Medium-risk roles"
          gate: "Canary validation passed"
        - scope: "High-risk roles"
          gate: "Medium-risk wave stable 48h"
      monitoring: "Continuous during rollout"

    3_completion:
      actions:
        - "Archive old model configurations"
        - "Update Agent Registry"
        - "Document behavioral changes in Logbook"
        - "Re-establish performance baselines"

  prompt_compatibility:
    check: "System prompt optimized for new model?"
    action: "A/B test prompt variants if needed"
    critical: true

Knowledge Continuity Guarantee

Strukturelle Garantie: Alles von Agenten generierte Wissen wird in geteilten G-Memory-Schichten gespeichert, nicht in agent-lokalem Speicher. Kein Wissen geht bei Agent-Stilllegung verloren. Dies adressiert direkt das „Sticky Knowledge“-Problem (Nonaka, 1995) — Wissen, das in einzelnen Mitarbeitern residiert und beim Ausscheiden verloren geht. In VCOM ist Wissen ab Erstellung organisationseigen, was Agent-Turnover zu einem strukturellen Nicht-Event für Wissenskontinuität macht.

Knowledge Continuity Guarantee

Structural guarantee: all knowledge generated by agents is stored in shared G-Memory layers, not agent-local storage. No knowledge is lost when an agent is retired. This directly addresses the "sticky knowledge" problem (Nonaka, 1995) — knowledge that resides in individual workers and is lost when they leave. In VCOM, knowledge is organizationally owned from creation, making agent turnover a structural non-event for knowledge continuity.