Der Software Development Lifecycle wurde über vier Jahrzehnte verfeinert. Anforderungen, Design, Implementierung, Test, Deployment, Wartung — der SDLC funktioniert, weil die Systeme, die er steuert, deterministisch sind. Gleicher Input, gleicher Output. Wenn sie scheitern, werfen sie Exceptions. Wenn sie Tests bestehen, funktionieren sie. Wenn sie ausgeliefert sind, bleiben sie ausgeliefert, bis jemand den Code ändert.
KI-Agents sind nichts davon. Bei identischem Input kann ein Agent unterschiedliche Outputs liefern — abhängig von Model-Temperatur, Inhalt des Kontextfensters und der stochastischen Natur des Token-Samplings. Wenn sie scheitern, werfen sie keine Exceptions, sondern produzieren selbstbewusste, sauber formatierte, falsche Antworten. Wenn sie zum Deployment-Zeitpunkt durch die Evaluation kommen, können sie binnen Wochen degradieren, sobald sich Inputverteilungen verschieben oder der Modellanbieter ein stilles Update einspielt. Und wenn sie laufen, verändern sich Modell, Retrieval-Korpus und Geschäftskontext weiter — ohne dass jemand eine Zeile Code anfasst.
Die Lücke zwischen Pilot und Produktion ist real und gut belegt. McKinseys „State of AI"-Report von 2025 zeigt, dass zwar 88 Prozent der Organisationen KI in mindestens einer Geschäftsfunktion regelmäßig einsetzen, aber erst rund 23 Prozent ein agentisches System skalieren — und nur etwa 30 Prozent die Management-Praktiken befolgen, die Wert überhaupt erst entstehen lassen. Die Lücke ist kein Technologieproblem. Die Modelle funktionieren. Die Frameworks funktionieren. Die Lücke ist methodisch: Organisationen wenden deterministische Engineering-Praktiken auf probabilistische Systeme an und wundern sich über unvorhersehbare Ergebnisse.
Der Agent Development Lifecycle ist die sich abzeichnende Antwort. Glean stellte im Mai 2026 ein Enterprise-ADLC-Framework mit sieben Stufen vor — von der Opportunity-Identifikation bis zum kontinuierlichen Monitoring. IBM beschreibt ein komplementäres Modell aus fünf Phasen: Plan, Code & Build, Test & Release, Deploy und Operate, wobei die mittleren Phasen als iterative Schleife laufen. Die Modelle unterscheiden sich in der Struktur, konvergieren aber in einer Erkenntnis: Agents brauchen eine eigene Entwicklungsmethodik, weil die im SDLC verankerten Annahmen — deterministische Outputs, binäre Testergebnisse, stabiles Verhalten nach dem Deployment — schlicht nicht zutreffen. Der folgende Durchgang orientiert sich an Gleans sieben Stufen, weil sie den vollständigen Kreislauf am klarsten abbilden.
Stufe 1: Opportunity — jeden Agent an einen Business-KPI binden
Die erste Stufe heißt nicht „Wähle einen Use Case". Sie heißt: Identifiziere ein Geschäftsergebnis, das ein Agent messbar verbessern kann. Die Unterscheidung ist entscheidend, denn der häufigste Fehlermodus in der Enterprise-Agent-Entwicklung ist der Bau von Agents, die technische Fähigkeiten demonstrieren, ohne an einen KPI gebunden zu sein, den die Organisation tatsächlich verfolgt.
Ein Beschaffungs-Agent, der die Erstellung von Bestellungen automatisiert, ist eine Technologiedemonstration. Ein Beschaffungs-Agent, der die Purchase-to-Pay-Zykluszeit von vierzehn auf drei Tage verkürzt und monatlich an genau diesem Ziel gemessen wird, ist eine Geschäftsinitiative. Die Technologie ist identisch. Die Rahmung entscheidet, ob der Agent die erste Budgetüberprüfung überlebt.
Die Opportunity-Stufe verlangt vier Festlegungen: den konkreten Business-KPI, den der Agent verbessern soll, dessen aktuelle Baseline, die angestrebte Verbesserung und den wirtschaftlichen Wert der Zielerreichung. Ohne diese ist der Agent ein Experiment — und Experimente sterben, wie die Pilot-zu-Produktion-Erfahrung konsistent zeigt, beim Übergang von der Demo zum Deployment. Dass die Nachfrage real ist, belegt Anthropics „2026 State of AI Agents"-Report, der gemeinsam mit Material unter mehr als 500 Technologieführungskräften erhoben wurde: 57 Prozent der Organisationen setzen Agents bereits für mehrstufige Workflows ein, 16 Prozent für funktionsübergreifende Prozesse, und 80 Prozent berichten von messbaren wirtschaftlichen Erträgen. Ohne KPI-Alignment vom ersten Tag an operieren die meisten dieser Agents jedoch als Einzellösungen, die sich nie zu organisatorischem Wert verdichten. Die Opportunity-Stufe ist der Punkt, an dem Governance beginnt — nicht mit Sicherheitskontrollen, sondern mit der Frage, ob dieser Agent überhaupt existieren sollte.
Stufe 2: Design — Scope, Guardrails und Eskalationspfade
Agent-Design unterscheidet sich grundlegend von Software-Design, weil es definieren muss, was der Agent nicht tun soll, nicht nur, was er tun soll. Eine Software-Funktion verarbeitet einen Input oder eben nicht — Typsystem und Compiler erzwingen das. Ein Agent versucht bereitwillig, jeden Input zu verarbeiten, gleich ob dieser in seinen vorgesehenen Scope fällt, solange keine expliziten Grenzen ihn stoppen.
Die Design-Stufe produziert drei Artefakte ohne Äquivalent in der klassischen Softwareentwicklung. Die Scope-Definition legt exakt fest, welche Aufgaben der Agent ausführen darf, auf welche Daten er zugreift und welche Entscheidungen er autonom trifft. Das Delegation-Framework greift hier direkt: Jeder Agent braucht dieselbe Klarheit über Scope, Autorität, Grenzen und Verantwortlichkeit, die Sie einem menschlichen Mitarbeitenden in derselben Funktion geben würden.
Die Guardrail-Spezifikation definiert harte Beschränkungen, die der Agent unabhängig von seiner Schlussfolgerung nicht verletzen darf. Ein kundenseitiger Agent macht keine Preiszusagen außerhalb des genehmigten Rahmens. Ein Compliance-Agent genehmigt seine eigenen Risikobewertungen nicht. Das sind keine weichen Richtlinien, sondern Einschränkungen, die im Code erzwungen, vor dem Deployment getestet und in Produktion überwacht werden.
Das Eskalationsdesign legt fest, was passiert, wenn der Agent auf Situationen außerhalb seiner operativen Grenzen trifft. Ein gut gestalteter Agent erkennt, dass er den Rand seiner Kompetenz erreicht hat, und übergibt die Situation an den zuständigen Menschen oder Agent — mit vollständigem Kontext, nicht mit einem nackten Fehlercode. Welche dieser Pfade überhaupt sinnvoll sind, hängt von der gewählten Multi-Agent-Architektur ab: Ob Ihr Agent in einer Hub-and-Spoke-, Peer-to-Peer- oder hierarchischen Orchestrierung agiert, bestimmt den Scope, für den er gestaltet werden kann. Der ADLC ersetzt diese Architekturentscheidung nicht — er liefert die Methodik, sie systematisch zu treffen.
Stufe 3: Performance — Akzeptanzkriterien für probabilistische Outputs
Hier bricht der SDLC am offensichtlichsten. In klassischer Software besteht ein Test oder er scheitert; das System liefert den korrekten Wert oder nicht. Über die Akzeptanz des Outputs gibt es keine Mehrdeutigkeit.
Agents produzieren Outputs, die aus einer Wahrscheinlichkeitsverteilung gesampelt sind. Zwei Durchläufe desselben Agents mit demselben Input können semantisch gleichwertige, aber textuell verschiedene Antworten liefern. Ein Klassifikations-Agent ordnet Grenzfälle unterschiedlichen Kategorien zu. Ein Reasoning-Agent folgt verschiedenen Argumentationsketten zum selben — oder eben zu einem anderen — Schluss.
Performance-Kriterien müssen diese Variabilität abbilden. Das Evaluierungs-Framework behandelt die Mechanik im Detail; der ADLC rahmt sie anders: Evaluation ist kein Tor, das der Agent einmal passiert, sondern eine kontinuierliche Messung, die den operativen Korridor definiert, in dem der Agent laufen darf. Praktisch heißt das, Akzeptanzkriterien über mehrere Dimensionen zu definieren — Aufgabengenauigkeit gegen ein Golden-Test-Set, Konsistenz über mehrere Durchläufe, Latenz innerhalb der Prozess-Constraints, Inferenzkosten pro Aufgabe innerhalb des Wirtschaftlichkeitsmodells sowie Sicherheit, also eingehaltene Guardrails und korrekt ausgelöste Eskalation. Das sind keine Pass/Fail-Schwellen, sondern Betriebsbereiche. Ein Agent, der seine definierte Genauigkeit, seine Latenz-Zielwerte und seine Kostenobergrenze hält, operiert innerhalb seines Korridors. Driftet eine Dimension heraus, meldet das Monitoring (Stufe 7) den Eingriffsbedarf.
Stufe 4: Kontext und Input — Data Governance als erstrangiges Anliegen
Der größte Einzelfaktor für die Outputqualität eines Agents ist weder Modell noch Prompt noch Framework — es sind die Daten, auf die er Zugriff hat. Ein Agent mit akkuraten, aktuellen, gut strukturierten Daten und einem mittelmäßigen Prompt schlägt einen Agent mit brillantem Prompt und veralteten, unvollständigen Daten.
Die Kontextstufe legt fest, auf welche Quellen der Agent zugreift, wie diese Daten abgerufen werden, wie Aktualität gewährleistet ist und wie der Zugang gesteuert wird. Für RAG-basierte Agents heißt das: Korpus, Chunking-Strategie, Embedding-Modell, Retrieval- und Re-Ranking-Ansatz, Aktualisierungsfrequenz. Für Agents mit Tool Use heißt es: welche APIs der Agent aufrufen darf und was geschieht, wenn eine API nicht verfügbar ist.
Data Governance ist im ADLC kein Anhängsel, sondern eine Kernstufe. Ein Agent, der auf Kundendaten zugreift, unterliegt der DSGVO, unabhängig von seiner Aufgabe. Ein Agent, der Finanzdaten abruft, muss Zugriffskontrollen auf Zeilen- und Spaltenebene respektieren, nicht nur auf API-Ebene. Die Build-Entscheidung zwischen Low-Code und Pro-Code wirkt direkt auf diese Stufe: Plattformverwaltete Agents erben die Data-Governance-Kontrollen der Plattform, individuell entwickelte Agents erfordern zweckgebundene Governance-Schichten.
Die Kontextstufe adressiert auch Context Poisoning — einen Fehlermodus, den nur Agents kennen. Enthält der Retrieval-Korpus veraltete oder falsche Information, gibt der Agent sie selbstbewusst wieder. Anders als eine Datenbankabfrage verwebt er das Abgerufene in natürlichsprachliche Antworten, die die Herkunft jeder Aussage verschleiern. Eine falsche Antwort bis zum verursachenden Dokument-Chunk zurückzuverfolgen, erfordert explizites Provenance-Tracking — das Protokollieren, welche Dokumente abgerufen und wie sie einbezogen wurden.
Stufe 5: Develop — Evaluierungs-Frameworks statt Unit Tests
In der Entwicklungsstufe ist die Kluft zwischen SDLC und ADLC am größten. Klassische Software setzt auf Unit Tests mit deterministischem Soll: Bei Input X muss Output Y entstehen. Agent-Entwicklung setzt stattdessen auf Evaluierungs-Frameworks. Ein Unit Test prüft auf einen spezifischen Output und liefert in Millisekunden ein binäres Ergebnis. Ein Evaluierungsdurchlauf bewertet, ob ein Output über mehrere Qualitätsdimensionen in einen akzeptablen Bereich fällt — das kann Minuten dauern, API-Credits verbrauchen und einen mehrdimensionalen Score liefern.
Der praktische Evaluierungsstack hat drei Schichten. Die erste sind deterministische Tests für deterministische Komponenten: Parst die Tool-Calling-Schnittstelle Funktionssignaturen korrekt, liefert die Retrieval-Pipeline relevante Dokumente für bekannte Abfragen, blockiert das Guardrail-System bekannte schädliche Inputs? Diese gehören in die CI/CD-Pipeline. Die zweite Schicht ist LLM-as-Judge-Evaluation für generative Outputs: Ein separates Modell bewertet, ob die Antworten quellentreu, faktisch konsistent und im Scope sind. Das Muster ist unvollkommen — das Bewertungsmodell trägt eigene Biases —, liefert aber automatisierte Qualitätsbewertung im großen Maßstab. Die dritte Schicht ist menschliche Evaluation auf Stichprobenbasis: Ein Anteil der Outputs wird von Domänenexperten geprüft, die Dimensionen bewerten, die Automatisierung nicht erfasst — Tonalität, geschäftliche Plausibilität einer Empfehlung. Diese Schicht ist teuer und langsam, aber sie verankert die automatisierten Schichten und fängt Fehlermodi ab, die das Bewertungsmodell übersieht.
Dieser Dreischichtansatz knüpft direkt an die Model-Lifecycle-Management-Disziplin an. Das in der Entwicklung etablierte Evaluierungs-Framework wird zum Monitoring-Framework in Produktion. Das kuratierte Golden-Test-Set wird zum Regressions-Set, an dem Modell-Updates, Prompt-Änderungen und Retrieval-Modifikationen validiert werden. Auch IBM verankert diese Logik: In seinem ADLC-Modell laufen Test & Release als strukturierte Evals gegen vordefinierte Benchmarks, ergänzt um Policy-Checks und Red-Teaming, bevor ein Agent in einen governten Katalog zertifiziert wird.
Stufe 6: Launch — gestufter Rollout mit Human-in-the-Loop
Der Launch eines Agents ist kein Code-Deployment. Code-Deployment ist binär — die neue Version ersetzt die alte, besteht sie die Health Checks, ist sie live. Agent-Deployment ist graduell, weil die einzig verlässliche Testumgebung für ein probabilistisches System der Produktionstraffic ist.
Das Muster des gestuften Rollouts — bei Glean wie bei IBM als progressive Stufen beschrieben, die das Risiko managen — beginnt im Shadow Mode: Der Agent verarbeitet reale Inputs, seine Outputs werden jedoch von Menschen geprüft, bevor gehandelt wird. Überschreitet die Akzeptanzrate eine definierte Schwelle, wechselt der Agent in den Supervised Mode, in dem er autonom handelt, ein Mensch aber eine Stichprobe nachträglich prüft. Demonstriert er dort über einen definierten Zeitraum stabile Qualität, folgt der Autonomous Mode mit Monitoring.
Jeder Stufenübergang ist eine Governance-Entscheidung, keine technische. Der Wechsel vom Supervised zum Autonomous Mode sollte Business Owner, Compliance-Funktion und technisches Team einbeziehen, denn es geht um Risikotoleranz, nicht um Accuracy-Metriken allein. Ein Agent mit hoher Genauigkeit in einem risikoarmen Workflow ist eine einfache Freigabe. Dieselbe Genauigkeit in einem risikoreichen Compliance-Workflow reicht womöglich nicht — unabhängig von den Metriken. Die Launch-Stufe ist zugleich der Punkt, an dem Copilot-Studio-Agents und Pro-Code-Agents operativ divergieren: Plattformverwaltete Agents bringen Versionierung, Rollback und Traffic Splitting mit, die Pro-Code-Teams selbst bauen oder integrieren müssen. Der ADLC gilt für beide; der Implementierungsaufwand dieser Stufe ist auf verwalteten Plattformen deutlich geringer.
Stufe 7: Monitoring und Verbesserung — die Stufe, die nie endet
Die siebte Stufe ist der Punkt, an dem die meisten Organisationen scheitern — und an dem der ADLC seinen Wert beweist. Klassische Software kann nach Deployment und Stabilisierung monatelang ohne aktives Monitoring jenseits von Infrastruktur-Health-Checks laufen. Agents können das nicht. Sie operieren in Umgebungen, die sich kontinuierlich verändern: Inputverteilungen verschieben sich, Upstream-Modelle aktualisieren sich, Retrieval-Korpora entwickeln sich weiter, und das Nutzerverhalten passt sich an die Präsenz des Agents an.
Der Observability-Stack für KI in Produktion behandelt die technische Umsetzung. Der ADLC rahmt Monitoring als vier parallele Ströme: Performance-Monitoring (erfüllen Outputs noch die Akzeptanzkriterien aus Stufe 3), Drift-Erkennung (haben sich Input- oder Outputmuster über Schwellenwerte hinaus verschoben), Kosten-Monitoring (liegt die Inferenzausgabe pro Aufgabe noch im Wirtschaftlichkeitsmodell) und Governance-Monitoring (operiert der Agent noch im definierten Scope und eskaliert er angemessen).
Die „Verbesserung"-Hälfte schließt den Kreislauf. Erkennt das Monitoring eine Degradation, springt der ADLC zur betroffenen früheren Stufe zurück: Performance-Degradation führt zurück zu Stufe 5, eine geänderte Geschäftsanforderung zu Stufe 2, eine neue Datenquelle zu Stufe 4. Der Lifecycle ist ein Kreislauf, keine Linie — und er läuft kontinuierlich für jeden Agent in Produktion. Auch IBM beschreibt Deploy und Operate ausdrücklich als zwei Teile einer fortlaufenden Feedback-Schleife.
Agent Sprawl: das Problem, das der ADLC löst
Ohne Lifecycle-Methodik stoßen Unternehmen auf Agent Sprawl. Das Innovationsteam baut drei Agents, die IT zwei weitere, eine Fachabteilung beauftragt einen bei einem Dienstleister. Binnen zwölf Monaten existieren zehn bis fünfzehn Agents, verstreut über Teams, Anbieter und Plattformen. Niemand kennt das vollständige Inventar, niemand verantwortet die übergreifenden Themen — Sicherheit, Data Governance, Kostenmanagement, Modell-Updates —, und niemand kann die Frage beantworten, die jede Geschäftsführung irgendwann stellt: Was kostet und was bringt unser Agent-Portfolio insgesamt?
Das ist keine theoretische Sorge. Microsofts „Cyber Pulse"-Report vom Februar 2026 stellt fest, dass über 80 Prozent der Fortune-500-Unternehmen aktive KI-Agents einsetzen — überwiegend mit Low-Code-Werkzeugen gebaut — und dass bereits 29 Prozent der Mitarbeitenden auf nicht autorisierte Agents für Arbeitsaufgaben zurückgreifen, während nur 47 Prozent der Organisationen dedizierte Sicherheitskontrollen für generative KI implementiert haben. Microsofts eigene Empfehlung ist ein zentrales Register als Single Source of Truth über alle Agents hinweg — sanktioniert, von Dritten oder als Schatten-Agent entstanden. Genau diese Disziplin liefert ein gelebter ADLC als Nebenprodukt.
Der ADLC verhindert Sprawl, indem er ab dem ersten Agent eine konsistente Methodik etabliert. Jeder Agent hat einen KPI-Verantwortlichen, definierten Scope, Guardrails, Akzeptanzkriterien und einen Monitoring-Plan. Wird der zehnte Agent vorgeschlagen, bewertet die Organisation ihn nach denselben Kriterien wie den ersten und entscheidet, ob er gebaut, mit einem bestehenden Agent konsolidiert oder deprioritisiert werden soll. Hier verbindet sich der ADLC mit der übergreifenden Betriebsdisziplin. Das AI Operating System liefert die Governance-Schicht über alle KI-Initiativen hinweg; der ADLC liefert die Entwicklungsmethodik darin. Das Operating System beantwortet „Wie steuern wir KI auf Unternehmensebene?", der ADLC beantwortet „Wie bauen und betreiben wir jeden einzelnen Agent verantwortungsvoll?".
Die Unternehmen, die erfolgreich skalieren — in McKinseys Daten die rund 23 Prozent —, verwenden keine besseren Modelle und keine besseren Frameworks als jene, die im Experimentierstadium feststecken. Sie haben eine Methodik. Sie behandeln Agents als verwaltete Assets, nicht als Experimente. Der ADLC ist die Methodik, die das ermöglicht.
Ein Fit Call bildet Ihr aktuelles Agent-Portfolio auf die ADLC-Stufen ab — und identifiziert, welchen Agents die Business-KPI-Anbindung fehlt, welche ohne definierte Guardrails operieren und wo Lifecycle-Lücken das Sprawl- und Governance-Risiko erzeugen, das die Skalierung ausbremst.
Referenzen: Glean, „Introducing the Agent Development Lifecycle (ADLC)," Mai 2026 (https://www.glean.com/blog/agent-dev-lifecycle-2026); IBM, „What Is the Agent Development Lifecycle?" (https://www.ibm.com/think/topics/agent-development-lifecycle-adlc); McKinsey & Company, „The State of AI: How Organizations Are Rewiring to Capture Value," 2025 (https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value); Anthropic, „The 2026 State of AI Agents Report" (https://claude.com/blog/how-enterprises-are-building-ai-agents-in-2026); Microsoft, „Cyber Pulse: An AI Security Report," Februar 2026 (https://www.microsoft.com/en-us/security/security-insider/emerging-trends/cyber-pulse-ai-security-report).