Ein live geschalteter KI-Agent kann wochenlang fehlerhaft laufen, ohne eine einzige Fehlerbenachrichtigung auszulösen. Die drei Arten, wie Agenten degradieren (Prompt-Drift, Integrations-Drift und Sonderfall-Anhäufung) erzeugen alle Ausgaben, die wie normale Ausgaben aussehen, bis jemand prüft, ob diese Ausgaben noch korrekt sind. Die meisten Unternehmen modellieren die Agentenwartung nach Software-Hosting, wo etwas entweder läuft oder abstürzt. Agenten sind anders. Agenten driften.
Ein KI-Agent, der läuft, arbeitet nicht notwendigerweise korrekt. Diese Unterscheidung ist wichtig, und ohne eine definierte Wartungsroutine bleibt sie unsichtbar. Die meisten Unternehmen behandeln einen live Agenten so wie gehostete Software: aufsetzen, auf Abstürze achten, eingreifen, wenn etwas kaputt geht. Agenten brechen nicht so zusammen. Agenten degradieren durch drei Mechanismen, die keine Fehlerbenachrichtigung erzeugen. Wenn die Degradierung sichtbar wird, sind bereits wochenlang fehlerhafte Ausgaben herausgegangen.
Was bei einem live Agenten kaputt geht (und warum keines davon einen Fehler auslöst)
Drei Fehlermodi betreffen live KI-Agenten. Keiner von ihnen stoppt den Agenten. Alle drei erzeugen Ausgaben, die wie normale Ausgaben aussehen, bis jemand prüft, ob diese Ausgaben noch korrekt sind.
Prompt-Drift tritt auf, wenn sich das Unternehmen ändert, aber die Anweisungen des Agenten nicht. Ein Vertriebsteam beginnt, andere Sprache für Pipeline-Phasen zu verwenden. Eine Produktlinie wird umbenannt. Eine neue Kundenkategorie entsteht, über die der Agent nie informiert wurde. Der Agent läuft weiterhin gegen den ursprünglichen Prompt. Die Ausgaben spiegeln eine Version des Unternehmens wider, die nicht mehr existiert. Kein Fehler wird ausgelöst. Die Ausgaben sehen plausibel aus.
Keiner der drei Fehlermodi — Prompt-Drift, Integrations-Drift, Sonderfall-Anhäufung — löst Fehlerbenachrichtigungen aus. Alle drei erzeugen Ausgaben, die wie normale Ausgaben aussehen, bis jemand prüft, ob diese Ausgaben noch korrekt sind.
Integrations-Drift tritt auf, wenn ein verbundenes Tool seine API aktualisiert oder seine Datenstruktur ändert. Das Verbinden von KI-Agenten mit realen Systemen schafft eine Abhängigkeit von jedem Tool in der Kette. Wenn eines dieser Tools aktualisiert wird, kann die Verbindung des Agenten still degradieren. Schreibaufrufe gelingen — die API akzeptiert die Anfrage — aber das Feld-Mapping entspricht nicht mehr dem aktualisierten Schema. Datensätze scheinen erstellt zu werden. Die Daten werden in veraltete Felder geschrieben, die niemand prüft.
Sonderfall-Anhäufung tritt auf, wenn neue Eingaben ankommen, für die der Agent nicht gebaut wurde. Der Agent verarbeitet diese Eingaben so gut er kann. Meist fehlerhaft. Ohne regelmäßige Log-Reviews häufen sich diese Fehler unbemerkt an.
Die folgende Tabelle ordnet jeden Fehlermodus seinem Erkennungssignal und der Wartungsmaßnahme zu, die ihn behebt.
| Fehlermodus | Wie er aussieht | Wann er typischerweise auftritt | Erkennungsmethode | Lösung |
|---|---|---|---|---|
| Prompt-Drift | Ausgaben spiegeln veralteten Prozess oder Terminologie wider | Monate 2–6, nach Prozessänderungen | Prompt-Vergleich mit aktueller Workflow-Sprache | Betroffene Prompt-Abschnitte neu schreiben; gegen aktuelle Eingaben testen |
| Integrations-Drift | Daten landen in falschen Feldern oder scheinen korrekt, enthalten aber veraltete Werte | Nach Tool-API-Updates (meist Monate 4–12) | Stichprobenweise 10 Datensätze pro verbundenem Tool prüfen | Feld-Mapping aktualisieren; mit Test-Schreib auf neues Schema bestätigen |
| Sonderfall-Anhäufung | Steigende Ausnahmerate; bestimmte Eingabetypen werden konsistent falsch behandelt | Monate 2–4, zunehmend mit Volumen | Log-Sampling — nach wiederholten Mustern in markierten Ausgaben suchen | Behandlung für erkannte Sonderfälle hinzufügen; Brief aktualisieren |
Wann Wartung ihren Höhepunkt erreicht: nicht beim Launch, sondern im dritten Monat
Die ersten Wochen nach dem Launch sehen sauber aus. Der Agent läuft mit Eingaben, für die er gebaut wurde, gegen Integrationen, die beim Build aktuell waren, mit einem Prompt, der das Unternehmen zum Zeitpunkt der Erstellung beschrieb. Nichts löst einen Review aus. Nichts sieht falsch aus.
Bis Monat drei sind die ersten Anzeichen von Drift erkennbar — für jeden, der hinschaut. Ein Anbieter hat ein API-Update eingespielt. Das Unternehmen hat einen neuen Kundentyp aufgenommen, für den der Agent nicht ausgelegt wurde. Das Team verwendet in seinen Notion-Seiten leicht andere Sprache als während des Builds. Keine dieser Änderungen wird angekündigt. Keine löst eine Benachrichtigung aus.
Die Wartungsarbeiten erreichen für die meisten Einzelworkflow-Implementierungen ihren Höhepunkt zwischen Monat drei und sechs. Prompt-Drift hatte Zeit sich aufzubauen. Integrations-Drift hat sich über mehrere Datensätze verbreitet. Sonderfälle haben sich zu einem Volumen angehäuft, das groß genug ist, um Muster zu erkennen.
Was ein monatlicher Agent-Review abdeckt
Einen monatlichen Review durchzuführen erfordert keine tiefgreifenden technischen Kenntnisse des Agenten. Es erfordert einen definierten Satz von Prüfungen, die nach einem festen Zeitplan von einer benannten Person durchgeführt werden.
Log-Sampling
Rufen Sie die letzten 50–100 Ausgaben ab und lesen Sie 15–20 davon gegen den aktuellen Standard des Unternehmens für diesen Workflow. Markieren Sie jede Ausgabe, die ein Mensch korrigiert oder abgelehnt hätte.
Prompt-Vergleich
Lesen Sie die aktuellen Anweisungen des Agenten gegen die Art und Weise, wie das Team den Workflow heute beschreibt. Identifizieren Sie Sprache, die gedriftet ist — umbenannte Pipeline-Phasen, neue Kundenkategorien, aktualisierte Terminologie — und aktualisieren Sie den Prompt entsprechend.
Integrationsgesundheit
Prüfen Sie stichprobenartig fünf bis zehn Datensätze, die der Agent in den letzten zwei Wochen in jedem verbundenen Tool geschrieben hat. Bestätigen Sie, dass Daten in den erwarteten Feldern gelandet sind und keine Felder konsistent leer oder falsch formatiert sind.
Ausnahmen-Review
Überprüfen Sie jede Eingabe, die der Agent im vergangenen Monat als außerhalb seines Designs markiert hat. Entscheiden Sie für jede: Erweiterung der Verarbeitung, Aktualisierung des Ausnahmeprozesses oder unverändert lassen mit einer Notiz.
Für einen Einzelworkflow-Agenten, der einen klar definierten, stabilen Prozess abwickelt, dauert dieser Review zwei bis drei Stunden pro Monat.
Wie Sie den Wartungsaufwand bemessen
Das richtige Modell für die Agentenwartung ist nicht Software-Hosting. Software läuft entweder oder stürzt ab. Ein Agent kann monatelang fehlerhaft laufen — und Ausgaben produzieren, die eine oberflächliche Prüfung bestehen, aber in der Qualität abnehmen.
Das passendere Modell ist das Führen eines fähigen Mitarbeiters, der nach einem Brief arbeitet, der vor sechs Monaten geschrieben wurde. Die Arbeit erfordert keine tägliche Aufmerksamkeit. Der Brief muss aktualisiert werden, wenn sich das Unternehmen ändert. Die Ausgaben müssen nach einem Zeitplan überprüft werden. Die Ausnahmen brauchen einen Entscheidungsträger.
Für einen Einzelworkflow-Agenten auf einem stabilen Prozess: zwei bis drei Stunden pro Monat. Für Agenten mit mehr Integrationen, höherem Eingangsvolumen oder einem sich häufig ändernden Workflow: proportional skalieren. Die Einschränkung ist nicht die Zeit — es ist die Verantwortung. Zwei Stunden undefinierter Verantwortung produzieren dasselbe Ergebnis wie null Stunden, was genau der Grund ist, warum die meisten Agenten-Projekte nach dem Go-live ins Stocken geraten.
Benennen Sie den Verantwortlichen vor dem Launch. Legen Sie den Review-Zeitplan vor dem Launch fest. Diese zwei Entscheidungen verhindern, dass die Wartungslücke unsichtbar wird.
| Agentenart | Monatlicher Wartungsaufwand | Was den Unterschied ausmacht |
|---|---|---|
| Einzelworkflow, stabiler Prozess, 1–2 Integrationen | 2–3 Std. | Geringe Änderungsrate; minimales Sonderfall-Volumen |
| Einzelworkflow, häufig wechselnder Prozess | 3–5 Std. | Prompt-Updates nach jeder Prozessänderung nötig |
| Multi-Workflow, 3–4 Integrationen | 4–8 Std. | Mehr Integrationsfläche; mehr Review-Umfang |
| Hochvolumen-Workflow (500+ Eingaben/Woche) | 3–6 Std. | Mehr Sonderfälle zu überprüfen; größere Log-Stichprobe erforderlich |
Der Unterschied zwischen einem gut gewarteten und einem vernachlässigten Agenten ist im ersten Monat nicht sichtbar. Ab Monat drei ist der Qualitätsunterschied zwischen einem überprüften und einem nicht überprüften Agenten, der denselben Workflow ausführt, in der Korrekturrate messbar, die das Team auf die Ausgaben anwendet.
Welche Signale zeigen an, dass Wartung überfällig ist
Drei beobachtbare Muster zeigen an, dass Wartung überfällig ist, unabhängig davon, wann der letzte Review geplant war.
Das Team hat Workarounds entwickelt. Wenn Teammitglieder informelle Gewohnheiten rund um die Ausgaben des Agenten aufgebaut haben — „immer prüfen, ob die Deal-Phase korrekt ist, bevor man schickt", „die Zusammenfassung für europäische Kunden ignorieren" — ist der Agent über den Punkt gedriftet, an dem seine Ausgaben vertraut werden. Die Workarounds sind der Beweis für unentdeckten Drift.
Die Eskalationsbehandlung wurde umgangen. Wenn das Team beginnt, Ausnahmen selbst zu behandeln, die der Agent weiterleiten sollte — weil der Eskalationspfad gebrochen ist oder das Ausnahme-Volumen zu hoch geworden ist — funktioniert der Ausnahmemechanismus nicht mehr wie vorgesehen. Dies ist Integrations-Drift oder Sonderfall-Anhäufung, die operativ sichtbar wird.
Der Brief wurde nie aktualisiert. Wenn der Agent sechs Monate lang ohne ein einziges Prompt-Update gelaufen ist und das Unternehmen in diesem Zeitraum Prozessänderungen hatte, ist der Brief gedriftet. Nicht jede Prozessänderung erfordert ein Prompt-Update — aber sechs Monate ohne Updates bedeuten fast immer, dass sich Drift unbemerkt angehäuft hat.
Häufig gestellte Fragen
Was ist Prompt-Drift bei einem KI-Agenten?
Prompt-Drift tritt auf, wenn sich das Unternehmen ändert, aber die Anweisungen des Agenten nicht aktualisiert werden. Neue Namenskonventionen, neue Kundentypen oder umbenannte Produkte führen dazu, dass der Agent Ausgaben produziert, die eine veraltete Version des Workflows widerspiegeln. Prompt-Drift löst keinen Fehler aus — die Ausgaben sehen weiterhin plausibel aus, bis sie gegen aktuelle Standards überprüft werden.
Was ist Integrations-Drift bei einem KI-Agenten?
Integrations-Drift tritt auf, wenn ein verbundenes Tool seine API aktualisiert oder seine Datenstruktur ändert, nachdem der Agent live gegangen ist. Die Schreibaufrufe des Agenten gelingen — die API akzeptiert die Anfrage — aber das Feld-Mapping entspricht nicht mehr dem aktuellen Schema. Daten landen in veralteten Feldern oder werden lautlos verworfen, ohne dass eine Fehlerbenachrichtigung erzeugt wird.
Wie oft sollte man einen live KI-Agenten überprüfen?
Monatlich funktioniert für die meisten Einzelworkflow-Implementierungen auf einem stabilen Prozess. Der Review umfasst Log-Sampling, Prompt-Vergleich mit der aktuellen Unternehmenssprache, Integrationsprüfungen an verbundenen Tools und einen Ausnahmen-Review für Eingaben, die der Agent nicht verarbeiten konnte. Jeder Review dauert zwei bis drei Stunden.
Wer sollte die Wartung eines KI-Agenten verantworten?
Eine benannte Person — nicht „das Team" — deren Verantwortlichkeiten explizit monatliche Log-Reviews, Prompt-Aktualisierungen bei Unternehmensänderungen und Integrationsprüfungen nach Tool-Updates umfassen. Der Fehler ist nicht zu viel Wartungsarbeit. Der Fehler ist undefinierte Wartungsverantwortung, die niemand übernimmt.
Wie sieht ein Null-Wartungs-Ansatz aus, und warum scheitert er? Ein Null-Wartungs-Ansatz bedeutet, dass der Agent deployt wird, auf Abstürze überwacht wird und nie aktiv überprüft wird. Der Agent läuft weiter. Im Laufe von Monaten häuft sich Prompt-Drift an, während sich das Unternehmen ohne entsprechende Prompt-Updates verändert. Ein oder zwei verbundene Tools aktualisieren ihre APIs, und die Feld-Mappings brechen lautlos. Sonderfälle, die nie behandelt wurden, treten regelmäßig auf. Die Ausgaben degradieren in der Qualität — aber die Degradierung ist ohne Review unsichtbar, da der Agent nie eine Fehlerbenachrichtigung auslöst. Bis Monat sechs verbringt das Team zwei bis drei Stunden pro Woche damit, die Ausgaben des Agenten zu korrigieren — was mehr Zeit ist, als eine monatliche Wartungsroutine gekostet hätte.
Wie verhindert man Wartungslücken in einem Multi-Agenten-System? Jeder Agent in einem Multi-Agenten-System benötigt seinen eigenen Verantwortlichen und Review-Zeitplan — kein geteiltes Verantwortungsmodell, bei dem „das Team" für alle Agenten gemeinsam zuständig ist. Ein geteiltes Modell produziert dieselbe Lücke wie keine Verantwortung: Wenn etwas schiefläuft, war niemand konkret dafür zuständig, es zu erkennen. Hinweise zur Strukturierung der Multi-Agenten-Verantwortung von Anfang an finden Sie unter KI-Agenten skalieren.
Was beinhaltet ein wartungsbedingtes Prompt-Update? Ein durch eine Prozessänderung ausgelöstes Prompt-Update umfasst drei Schritte: Identifizieren, welche Abschnitte des aktuellen Prompts von der Änderung betroffen sind, diese Abschnitte neu schreiben, um den aktualisierten Prozess widerzuspiegeln, und den aktualisierten Prompt gegen fünf bis zehn aktuelle Eingaben aus der Praxis testen, bevor er wieder deployt wird. Die meisten Prompt-Updates dauern 30–60 Minuten für einen Einzelworkflow-Agenten. Die Kosten eines Prompt-Updates sind erheblich geringer als die Kosten von sechs Wochen schlechter Ausgaben, die von einem nie aktualisierten Prompt produziert wurden.