Der Software Development Lifecycle wurde über vier Jahrzehnte hinweg verfeinert. Anforderungen, Design, Implementierung, Test, Deployment, Wartung — der SDLC funktioniert, weil die Systeme, die er steuert, deterministisch sind. Bei gleichem Input liefern sie den gleichen Output. Wenn sie scheitern, werfen sie Exceptions. Wenn sie Tests bestehen, funktionieren sie. Wenn sie ausgeliefert werden, bleiben sie ausgeliefert, bis jemand den Code ändert.
KI-Agents sind nichts davon. Bei gleichem Input kann ein Agent unterschiedliche Outputs liefern — abhängig von der Model-Temperatur, dem Inhalt des Kontextfensters und der stochastischen Natur des Token-Samplings. Wenn sie scheitern, werfen sie keine Exceptions — sie produzieren selbstbewusste, sauber formatierte, falsche Antworten. Wenn sie bei der Evaluation zum Deployment-Zeitpunkt bestehen, können sie innerhalb von Wochen degradieren, sobald sich Inputverteilungen verschieben und Modellanbieter stille Updates einspielen. Und wenn sie ausgeliefert werden, verändern sich das zugrunde liegende Modell, der Retrieval-Korpus und der geschäftliche Kontext weiter — ohne dass jemand den Code des Agents anfasst.
Enterprise-Teams haben das bemerkt. McKinseys „State of AI"-Report 2025 ergab, dass nur 23 Prozent der Unternehmen KI-Agents erfolgreich skalieren, während 39 Prozent im Experimentierstadium feststecken. Die Lücke ist kein Technologieproblem. Die Modelle funktionieren. Die Frameworks funktionieren. Die Lücke ist methodischer Natur: Organisationen wenden deterministische Engineering-Praktiken auf probabilistische Systeme an und wundern sich, warum die Ergebnisse unvorhersehbar sind.
Der Agent Development Lifecycle — ADLC — ist die sich abzeichnende Antwort. Glean veröffentlichte sein Enterprise-ADLC-Framework im Mai 2026 und definierte sieben Stufen von der Opportunity-Identifikation bis zum kontinuierlichen Monitoring. IBM veröffentlichte ein komplementäres Framework, das um vier Phasen organisiert ist — Plan, Code and Build, Test and Release und Deploy —, wobei die beiden mittleren Phasen in einer iterativen Schleife laufen. EPAM, Arthur AI und Salesforce haben jeweils Varianten beigesteuert. Die Frameworks unterscheiden sich in der Struktur, konvergieren aber in einer gemeinsamen Erkenntnis: Agents brauchen ihre eigene Entwicklungsmethodik, weil die Annahmen, die im SDLC verankert sind — deterministische Outputs, binäre Testergebnisse, stabiles Verhalten nach dem Deployment — nicht zutreffen.
Stufe 1: Opportunity — jeden Agent an einen Business-KPI binden
Die erste ADLC-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 wichtig, denn der häufigste Fehlermodus in der Enterprise-Agent-Entwicklung ist der Bau von Agents, die technische Fähigkeiten demonstrieren, ohne an einen KPI angebunden 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 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 erfordert vier Ergebnisse: den spezifischen Business-KPI, den der Agent verbessern wird, die aktuelle Baseline für diesen KPI, die angestrebte Verbesserung und den wirtschaftlichen Wert der Zielerreichung. Ohne diese ist der Agent ein Experiment — und Experimente sterben, wie die Pilot-to-Production-Forschung konsistent dokumentiert, beim Übergang von der Demo zum Deployment. Anthropics „2026 State of AI Agents"-Umfrage unter mehr als 500 Technologieführungskräften zeigt, dass 57 Prozent der Organisationen bereits mehrstufige Agent-Workflows einsetzen, während 16 Prozent zu funktionsübergreifenden Agents übergegangen sind, die mehrere Teams umspannen. Doch ohne KPI-Alignment vom ersten Tag an operieren die meisten dieser Agents als Einzellösungen, die sich nie zu organisatorischem Wert verdichten. Microsofts „Cyber Pulse"-Report 2026 stellte fest, dass über 80 Prozent der Fortune-500-Unternehmen aktive KI-Agents einsetzen, wobei 29 Prozent der Mitarbeitenden bereits nicht autorisierte Agents für Arbeitsaufgaben nutzen. Die Opportunity-Stufe ist der Punkt, an dem Governance beginnt — nicht mit Sicherheitskontrollen, sondern mit der grundlegenden Frage, ob dieser Agent überhaupt existieren sollte.
Stufe 2: Design — Scope, Guardrails und Eskalationspfade
Agent-Design unterscheidet sich grundlegend von Software-Design, weil das Design berücksichtigen muss, was der Agent nicht tun soll, nicht nur, was er tun soll. Eine Software-Funktion verarbeitet einen Input entweder oder nicht — das Typsystem und der Compiler erzwingen dies. Ein Agent wird bereitwillig versuchen, jeden Input zu verarbeiten, unabhängig davon, ob er in seinen vorgesehenen Scope fällt, sofern keine expliziten Grenzen ihn daran hindern.
Die Design-Stufe produziert drei Artefakte, die kein Äquivalent in der traditionellen Softwareentwicklung haben. Die Scope-Definition spezifiziert exakt, welche Aufgaben der Agent ausführen darf, auf welche Daten er zugreifen darf und welche Entscheidungen er autonom treffen kann. Das Delegation-Framework greift hier direkt — jeder Agent braucht die gleiche Klarheit über Scope, Autorität, Grenzen und Verantwortlichkeit, die Sie einem menschlichen Mitarbeitenden geben würden, der dieselbe Funktion ausübt.
Die Guardrail-Spezifikation definiert harte Beschränkungen, die der Agent nicht verletzen darf, unabhängig von seiner Schlussfolgerung. Ein kundenseitiger Agent darf keine Preiszusagen außerhalb des genehmigten Rahmens machen. Ein Compliance-Agent darf seine eigenen Risikobewertungen nicht genehmigen. Das sind keine weichen Richtlinien — es sind Einschränkungen, die im Code erzwungen, vor dem Deployment getestet und in Produktion überwacht werden.
Das Eskalationsdesign definiert, was passiert, wenn der Agent auf Situationen trifft, die außerhalb seiner operativen Grenzen liegen. Automatisierung stoppt, wenn sie auf etwas Unerwartetes stößt. Ein gut gestalteter Agent erkennt, dass er den Rand seiner Kompetenz erreicht hat, und leitet die Situation an den zuständigen Menschen oder Agent weiter — mit vollständigem Kontext, nicht nur einem Fehlercode.
Die Multi-Agent-Architekturentscheidungen greifen direkt in die Design-Stufe ein. Ob Ihr Agent innerhalb einer Hub-and-Spoke-, Peer-to-Peer- oder hierarchischen Orchestrierung agiert, bestimmt den Scope dessen, wofür er gestaltet werden kann. Der ADLC ersetzt keine Architekturentscheidungen — er liefert die Methodik, um sie systematisch zu treffen.
Stufe 3: Performance — Akzeptanzkriterien für probabilistische Outputs
Hier bricht der SDLC am offensichtlichsten. In der traditionellen Software besteht ein Test entweder oder er scheitert. Das System gibt entweder den korrekten Wert zurück oder nicht. Es gibt keine Mehrdeutigkeit darüber, ob der Output akzeptabel ist.
Agents produzieren Outputs, die aus einer Wahrscheinlichkeitsverteilung gesampelt werden. Zwei Durchläufe desselben Agents mit demselben Input können semantisch gleichwertige, aber textuell unterschiedliche Outputs liefern. Ein Klassifikations-Agent könnte Grenzfälle verschiedenen Kategorien zuordnen. Ein Reasoning-Agent könnte unterschiedlichen Argumentationsketten folgen, um zum gleichen Schluss zu gelangen — oder zu einem anderen.
Performance-Kriterien müssen diese Variabilität berücksichtigen. Das Evaluierungs-Framework behandelt die Mechanik im Detail, aber der ADLC rahmt sie anders: Evaluation ist kein Testtor, das der Agent einmal passiert. Sie ist eine kontinuierliche Messung, die den operativen Korridor definiert, innerhalb dessen der Agent autorisiert ist zu laufen.
Der praktische Ansatz besteht darin, Akzeptanzkriterien über fünf Dimensionen zu definieren: Aufgabengenauigkeit (Precision und Recall gegen ein Golden-Test-Set), Konsistenz (semantisch gleichwertige Outputs über mehrere Durchläufe), Latenz (Antwortzeit innerhalb der Geschäftsprozess-Constraints), Kosten (Inferenzkosten pro abgeschlossener Aufgabe innerhalb des Wirtschaftlichkeitsmodells) und Sicherheit (Guardrails eingehalten, Eskalation angemessen ausgelöst). Das sind keine Pass/Fail-Schwellenwerte — es sind Betriebsbereiche. Ein Agent, der 92 Prozent Genauigkeit, unter zwei Sekunden p95-Latenz und unter 0,15 EUR pro Aufgabe aufrechterhält, operiert innerhalb seines Korridors. Wenn eine Dimension aus dem Bereich driftet, meldet das Monitoring-System (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 nicht das Modell, der Prompt oder das Framework. Es sind die Daten, auf die der Agent Zugriff hat. Ein Agent mit Zugang zu akkuraten, aktuellen, gut strukturierten Daten und einem mittelmäßigen Prompt wird einen Agent mit einem brillanten Prompt und veralteten, unvollständigen oder schlecht strukturierten Daten übertreffen.
Die Kontextstufe definiert, auf welche Datenquellen der Agent zugreift, wie diese Daten abgerufen werden, wie die Aktualität gewährleistet wird und wie der Zugang gesteuert wird. Für RAG-basierte Agents bedeutet das die Spezifikation des Korpus, der Chunking-Strategie, des Embedding-Modells, des Retrieval- und Re-Ranking-Ansatzes und der Aktualisierungsfrequenz. Für Agents mit Tool Use bedeutet es die Definition, welche APIs der Agent aufrufen darf und was passiert, wenn eine API nicht verfügbar ist.
Data Governance ist im ADLC kein nachträglicher Gedanke — sie ist eine Kernstufe. Ein Agent, der auf Kundendaten zugreift, unterliegt der DSGVO, unabhängig davon, welche Aufgabe er ausführt. 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-Plattformen wirkt sich direkt auf diese Stufe aus — plattformverwaltete Agents übernehmen die Data-Governance-Kontrollen der Plattform, während individuell entwickelte Agents zweckgebundene Governance-Schichten erfordern.
Die Kontextstufe adressiert auch Context Poisoning — einen Fehlermodus, der nur bei Agents auftritt. Wenn der Retrieval-Korpus eines Agents veraltete oder falsche Informationen enthält, wird der Agent diese selbstbewusst wiedergeben. Anders als bei einer Datenbankabfrage verwebt ein Agent abgerufene Informationen in natürlichsprachliche Antworten, die die Herkunft jeder Aussage verschleiern. Die Rückverfolgung einer falschen Antwort bis zum Dokument-Chunk, der sie verursacht hat, erfordert explizites Provenance-Tracking — das Protokollieren, welche Dokumente abgerufen wurden und wie der Agent sie einbezogen hat.
Stufe 5: Develop — Evaluierungs-Frameworks statt Unit Tests
Die Entwicklungsstufe ist der Punkt, an dem die Kluft zwischen SDLC und ADLC am größten ist. Traditionelle Software setzt auf Unit Tests mit deterministischen erwarteten Ergebnissen: Bei Input X muss das System Output Y liefern. Agent-Entwicklung erfordert stattdessen Evaluierungs-Frameworks. Ein Unit Test prüft auf einen spezifischen Output. Ein Evaluierungs-Framework bewertet, ob ein Output innerhalb eines akzeptablen Bereichs über mehrere Qualitätsdimensionen fällt. Ein Unit Test läuft in Millisekunden und liefert ein binäres Ergebnis. Ein Evaluierungsdurchlauf kann Minuten dauern, API-Credits verbrauchen und einen mehrdimensionalen Qualitätsscore 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 bekannt 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 Outputs des Agents quellentreu, faktisch konsistent und innerhalb des Scopes liegen. Dieses Muster, standardisiert unter anderem von Galileo AI und Arize, ist unvollkommen — das Bewertungsmodell hat eigene Biases —, aber es liefert automatisierte Qualitätsbewertung im großen Maßstab.
Die dritte Schicht ist menschliche Evaluation auf Stichprobenbasis. Fünf bis zehn Prozent der Outputs werden von Domänenexperten überprüft, die Dimensionen bewerten, die automatisierte Evaluation nicht erfassen kann: Ist der Tonfall angemessen? Ergibt die Empfehlung geschäftlich Sinn? Menschliche Evaluation 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 während der Entwicklung etablierte Evaluierungs-Framework wird zum Monitoring-Framework in Produktion. Das während der Entwicklung kuratierte Golden-Test-Set wird zum Regressions-Testset, das zur Validierung von Modell-Updates, Prompt-Änderungen und Retrieval-Pipeline-Modifikationen herangezogen wird.
Stufe 6: Launch — gestufter Rollout mit Human-in-the-Loop
Das Launchen eines Agents ist kein Code-Deployment. Code-Deployment ist binär — die neue Version ersetzt die alte, und wenn sie Health Checks besteht, ist sie live. Agent-Deployment ist graduell, weil die einzig zuverlässige Testumgebung für ein probabilistisches System der Produktionstraffic ist.
Das Muster des gestuften Rollouts spiegelt wider, was Glean, IBM und EPAM alle empfehlen: Beginnen Sie mit dem Shadow Mode, in dem der Agent reale Inputs verarbeitet, seine Outputs jedoch von Menschen geprüft werden, bevor darauf gehandelt wird. Wenn die Akzeptanzrate den definierten Schwellenwert überschreitet (typischerweise 90 bis 95 Prozent), wechseln Sie in den Supervised Mode, in dem der Agent autonom handelt, aber ein Mensch eine Stichprobe der Outputs nachträglich überprüft. Wenn der Supervised Mode über einen definierten Zeitraum stabile Qualität demonstriert, wechseln Sie in den Autonomous Mode mit Monitoring.
Jeder Stufenübergang ist eine Governance-Entscheidung, keine technische. Die Entscheidung, vom Supervised zum Autonomous Mode zu wechseln, sollte den Business Owner, die Compliance-Funktion und das technische Team einbeziehen — denn die Entscheidung betrifft Risikotoleranz, nicht Accuracy-Metriken allein. Ein Agent mit 95 Prozent Genauigkeit, der autonom in einem risikoarmen Workflow operiert, ist eine einfache Freigabe. Die gleiche Genauigkeit in einem risikoreichen Compliance-Workflow reicht möglicherweise nicht aus, unabhängig von den Metriken.
Die Launch-Stufe ist auch der Punkt, an dem Copilot-Studio-Agents und Pro-Code-Agents operativ divergieren. Plattformverwaltete Agents profitieren von integrierter Deployment-Infrastruktur — Versionierung, Rollback, Traffic Splitting —, die Pro-Code-Agents selbst bauen oder integrieren müssen. Der ADLC gilt für beide, aber der Implementierungsaufwand für die Launch-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 es ist der Punkt, an dem der ADLC seinen Wert beweist. Traditionelle Software kann nach dem Deployment und der 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 Inputverteilungen oder Outputmuster über Schwellenwerte hinaus verschoben), Kosten-Monitoring (liegen die Inferenzausgaben pro Aufgabe noch innerhalb des Wirtschaftlichkeitsmodells) und Governance-Monitoring (operiert der Agent noch innerhalb seines definierten Scopes und eskaliert er angemessen).
Die „Verbesserung"-Hälfte von Stufe 7 schließt den Kreislauf. Wenn das Monitoring eine Degradation erkennt, springt der ADLC zurück zur entsprechenden früheren Stufe. Performance-Degradation löst eine Rückkehr zu Stufe 5 für Evaluation und Behebung aus. Eine Änderung der Geschäftsanforderungen löst eine Rückkehr zu Stufe 2 für die Neudefinition des Scopes aus. Eine neue Datenquelle löst eine Rückkehr zu Stufe 4 aus. Der Lifecycle ist ein Kreislauf, keine Linie — und der Kreislauf läuft kontinuierlich für jeden Agent in Produktion.
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 baut zwei weitere. Eine Fachabteilung beauftragt einen bei einem Dienstleister. Innerhalb von zwölf Monaten hat die Organisation 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. Niemand kann die Frage beantworten, die jede Geschäftsführung irgendwann stellt: Was sind die Gesamtkosten und der Gesamtwert unseres Agent-Portfolios?
Der ADLC verhindert Sprawl, indem er eine konsistente Methodik ab dem ersten Agent etabliert. Jeder Agent hat einen Business-KPI-Verantwortlichen, definierten Scope, Guardrails, Akzeptanzkriterien und einen Monitoring-Plan. Wenn der zehnte Agent vorgeschlagen wird, kann die Organisation ihn nach denselben Kriterien bewerten wie den ersten — und entscheiden, 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 und das Rahmenwerk für kontinuierliche Verbesserung über alle KI-Initiativen hinweg. Der ADLC liefert die Entwicklungsmethodik innerhalb davon — die spezifischen Praktiken für Bau, Deployment und Management einzelner Agents. Das Operating System beantwortet „Wie steuern wir KI auf Unternehmensebene?" Der ADLC beantwortet „Wie bauen und betreiben wir jeden Agent verantwortungsvoll?"
Die Unternehmen, die erfolgreich skalieren — die 23 Prozent in McKinseys Daten — verwenden keine besseren Modelle oder besseren Frameworks als die 39 Prozent, 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, „Enterprise ADLC Framework," Mai 2026; IBM, „Agent Development Lifecycle: Plan, Code & Build, Test & Release, Deploy," 2026; EPAM, „ADLC: A Structured Approach to Building AI Agents," 2026; McKinsey & Company, „The State of AI: How Organizations Are Rewiring to Capture Value," 2025 (23 % skalieren, 39 % Experimentierphase); Anthropic, „The 2026 State of AI Agents Report," 2026 (57 % mehrstufige Workflows, 16 % funktionsübergreifende Agents); Microsoft, „Cyber Pulse: An AI Security Report," Februar 2026 (80 % Fortune-500-Adoption); Arthur AI, „Agent Development Lifecycle Best Practices," 2026; Salesforce, „Building Enterprise AI Agents: Lifecycle Methodology," 2026; Galileo AI, „The MLOps Guide to Transform Model Failures Into Production Success," 2026.