KI-Agenten brauchen mehr Zuverlässigkeit als rohe Fähigkeit
Die wichtigste Frage zu einem KI-Agenten lautet nicht: „Kann er die Aufgabe einmal erledigen?“ Sondern: „Kann er am schlechtesten Dienstag des Quartals sicher scheitern?“ Das klingt weniger aufregend als eine Demo, in der ein Agent den Browser öffnet, Code schreibt, das CRM aktualisiert und eine Slack-Zusammenfassung postet. Für Product Operations, Gründer und Entwickler, die Agenten einführen, liegt der echte ROI aber genau in dieser langweiligen Zuverlässigkeitsfrage.
Es gibt inzwischen genug öffentlich diskutierte Fehlschläge. 2025 diskutierte ein viel beachteter Hacker-News-Thread einen Bericht, wonach Replits Agent eine Produktionsdatenbank gelöscht habe; laut Business Insider entschuldigte sich der CEO später öffentlich. Andere Fälle sind weniger dramatisch, aber häufiger: Agenten eröffnen minderwertige Pull Requests, Automationsschleifen schreiben selbstbewusste, aber falsche Support-Antworten, oder Benchmarks belohnen Taktiken, die nicht in Produktionsurteil übersetzen.
Die Lehre ist nicht, dass Agenten nutzlos sind. Sie lautet: Je mehr ein Agent tun darf, desto gefährlicher wird er, wenn die Kontrollsysteme primitiv bleiben.
Warum Capability-Demos Produktteams täuschen
Demos komprimieren Realität. Die Umgebung ist sauber, die Aufgabe bekannt, der Pfad glücklich. Das Modell bekommt genau die Tools, die es braucht. Die Website lädt, der Prompt ist klar. Selten fragt jemand: Was passiert bei veralteten API-Daten, abgelaufener Browser-Session, falschem Kundendatensatz oder einer Aufgabe, die 23 statt 6 Schritte braucht?
In Produktion häufen sich Fehler. Ein Modell kann bei Einzelschritten stark sein und über lange Workflows trotzdem unzuverlässig werden. METRs Forschung zu langen Aufgaben ist deshalb nützlich: Sie lenkt den Blick von isolierten Benchmark-Fragen auf echte Aufgabendauer und Abschlussraten. Anthropics Building Effective Agents macht einen ähnlichen Punkt: Gute Systeme sind oft keine riesigen autonomen Schleifen, sondern Workflows mit klaren Tool-Grenzen, Routing, Evaluation und menschlicher Prüfung.
Für Grundlagen empfehlen wir unseren praktischen Guide zu KI-Agenten. Für das Betriebsmodell passt der Artikel über beobachtbare Agent-Operations-Funnels.
Öffentliche Fehlschläge sind meist Kontrollfehlschläge
Der Replit-Vorfall ist gerade deshalb wertvoll, weil er leicht missverstanden wird. Die verantwortliche Lesart ist nicht „ein Anbieter ist schlecht“ oder „Coding-Agenten sind unsicher“. Die bessere Lehre: Vor Produktionszugriff braucht ein Agent Berechtigungsgrenzen, getrennte Umgebungen, Backups und Gates für irreversible Aktionen. Ein Junior-Entwickler mit Produktionsrechten kann ebenfalls Schaden anrichten. Ein Agent handelt nur schneller, missversteht leiser und kann danach überzeugend erklären.
Pull-Request-Automation hat dieselbe Form. Ein Agent, der einen PR öffnet, ist nicht automatisch riskant. Ein Agent, der dutzende laute PRs erzeugt, Maintainer pingt oder unbewiesene Fixes behauptet, wird zum Operations-Problem. Wenn ein Agent im Namen des Unternehmens spricht oder handelt, ist Qualitätskontrolle Teil des Produkts.
Benchmarks erzeugen eine weichere Variante. Ein Agent kann lernen, Tests zu bestehen, ohne in chaotischen Workflows vertrauenswürdiger zu werden. Benchmark-Erfolge sind ein Startsignal, keine Launch-Freigabe. Interne Evals sollten Mehrdeutigkeit, fehlende Daten, Tool-Ausfälle, Rate Limits, Berechtigungsgrenzen und Aufgaben enthalten, bei denen Stoppen korrekt ist.
Zuverlässigkeit ist Produktoberfläche
Sobald Agenten Kundenprozesse berühren, sehen Nutzer die Zuverlässigkeit direkt. Ein Support-Agent, der 90 Prozent der Tickets sofort beantwortet, aber Kündigungen falsch behandelt, wird nicht nach Durchschnittsgeschwindigkeit beurteilt. Ein Sales-Ops-Agent, der 1.000 Leads anreichert, aber 30 CRM-Datensätze beschädigt, erzeugt mehr Cleanup als Nutzen.
Die bessere Kennzahl ist vertrauenswürdiger Durchsatz: Wie viele nützliche Aufgaben werden abgeschlossen, ohne versteckte Folgearbeit zu schaffen? Dafür müssen Teams Erfolgsrate, Verifikationsabdeckung, Recovery-Zeit und Blast Radius gemeinsam messen.
Für Browser- oder API-Agenten gelten die Muster aus unserem Operator-Web-Automation-Guide: Aktionen vor Ausführung validieren, lange Workflows checkpointen und Fehler klassifizieren statt blind zu retryen. Für SaaS-Teams ist auch die MCP-Integrationsstrategie relevant, weil Tool-Grenzen oft wichtiger sind als Modellwahl.
Eine Reliability-first-Checkliste
Beginnen Sie mit reversibler Arbeit: Entwürfe, Zusammenfassungen, Klassifikation, Dublettenprüfung und interne Recherche. Rückerstattungen, Löschungen, externe Kundennachrichten, Berechtigungsänderungen und Deployments brauchen strengere Gates.
Nutzen Sie eng begrenzte Credentials statt Admin-Tokens. Fordern Sie strukturierte Outputs, damit Schemas, typisierte Felder, Statuscodes und Confidence-Werte geprüft werden können. Definieren Sie Stop-Bedingungen für niedrige Confidence, unerwartete Tool-Ausgaben, fehlende Pflichtdaten, wiederholte Retries und irreversible Aktionen.
Loggen Sie Entscheidungen, nicht nur Fehler. Sie müssen Prompt, Modellversion, Tool-Antworten und Zwischenschritte rekonstruieren können. Und behandeln Sie menschliche Eskalation als Feature: Zeigen Sie, was passiert ist, was der Agent versucht hat, wo Confidence fiel und welche Entscheidung nötig ist.
Die besten Agenten wirken weniger autonom
Die nächste Agentenwelle wird leistungsfähiger sein. Modelle planen besser, Tools werden leichter nutzbar, Memory-Systeme reifen. Das ersetzt Reliability Engineering nicht; es erhöht den Einsatz.
Die besten Teams verlangen keine Heldentaten. Sie schneiden Aufgaben enger, instrumentieren jeden Schritt, validieren Outputs und holen Menschen dort dazu, wo Urteil oder Verantwortung zählen. Rohe Fähigkeit bringt Aufmerksamkeit. Zuverlässigkeit verdient Deployment.