Der Agent, den wir uns entschieden haben, nicht zu bauen

Votemap (votemap.eu) ist eine Analyseplattform, die sich Abstimmungsdaten des Europäischen Parlaments widmet. Sie betreibt Mastodon, PeerTube und eine eigene mehrsprachige Anwendung auf unserem Cluster. Das ist ein groß genug angelegtes System, sodass der Vorschlag, es von einem Agenten überwachen zu lassen, eine vernünftige technische Übung war, kein theoretisches Gedankenexperiment. Das ursprüngliche Briefing umriss vier konkrete Aufgaben für diesen vorgeschlagenen Agenten: prüfen, dass die Pods laufen, ein Redeploy auslösen, die Datenaktualität überwachen und Incidents melden.

Das Aufschlüsseln dieses Umfangs hat den Agenten aufgelöst. Jede Aufgabe auf der Liste hatte am Ende eine günstigere Lösung, die bereits lief, und übrig blieben drei Alerts. Wir sind ein Unternehmen, das KI verkauft, und dies ist ein Beitrag über eine Stelle, an der wir sie nicht eingesetzt haben. Das aufzuschreiben lohnt sich, weil die Entscheidung, etwas nicht zu bauen, kein Artefakt hinterlässt und daher dazu neigt, undokumentiert zu bleiben.

Den Umfang aufschlüsseln

Die erste Aufgabe war, die Gesundheit der Pods zu überwachen. Das Briefing ging davon aus, dass ein Agent den Betriebsstatus der Container fortlaufend überwachen müsste. Das war zwar eine plausible Anforderung, aber die Funktion wird bereits von kube-state-metrics gemessen. Ein Agent hätte diesen Rohdaten eine zusätzliche Interpretationsschicht hinzugefügt - unnötiger Overhead.

Die zweite Aufgabe betraf die Datenaktualität. Die Anforderung war, dass der Agent die Aktualität der in die Plattform eingespeisten Daten überwacht. Diese Bedingung lässt sich jedoch mit einer Standard-Alerting-Regel ausdrücken und überwachen. Ein Agent hätte den Alert interpretieren müssen - zusätzliche Komplexität dort, wo eine einfache Schwellenwertprüfung genügte.

Die dritte Aufgabe betraf das Auslösen eines Redeploys. Das Briefing schlug vor, dass der Agent ein Redeployment starten sollte, sobald bestimmte Bedingungen erfüllt sind. Diese Aktion übernimmt bereits eine geplante Pipeline. Der Agent hätte entscheiden müssen, wann die Pipeline laufen soll - eine Entscheidungsebene, die nicht nötig war.

Die letzte Aufgabe war die Incident-Meldung. Das Briefing sah vor, dass der Agent Incidents meldet, wenn sie auftreten. Diese Funktion wird bereits über einen Webhook-Mechanismus geroutet. Der Agent wäre für das Formatieren und Übermitteln der Meldung zuständig gewesen - eine Abstraktionsschicht über einem bestehenden, verlässlichen Kommunikationskanal.

Als diese vier Aufgaben aufgeschlüsselt wurden, blieb dem vorgeschlagenen Agenten nichts mehr. Übrig blieben drei eigenständige, gut handhabbare Alerts.

Warum eine Regel einem Agenten überlegen ist

Eine Regel ist ein deterministisches Stück Logik, das ausgeführt wird, wenn eine bestimmte Bedingung erfüllt ist. Sie ist kein System, das Absicht interpretiert, und versucht nicht herauszufinden, was Sie gemeint haben. Regeln sind darauf ausgelegt, mit klaren Eingaben zu arbeiten und vorhersehbare Ergebnisse zu liefern.

Regeln sind günstiger zu implementieren als Agenten, weil sie nur definierte Logik erfordern statt komplexes, allgemeines Schlussfolgern. Sie halluzinieren nicht, ihr Ergebnis lässt sich also immer auf die Eingabedaten zurückführen. Sie lassen sich durch einen Prompt nicht umstimmen, was ein vorhersehbares Verhalten unabhängig vom Gesprächskontext sicherstellt. Und ihre Fehler sind sichtbar - sie liefern klare, leicht zu diagnostizierende Fehlerpunkte.

Das ist kein Argument gegen den Einsatz von Agenten in komplexen Systemen. Es ist vielmehr ein Argument darüber, wo die Grenze zwischen notwendiger Automatisierung und übertechnisierter Komplexität verläuft.

Der Fehler lag einen Schritt früher

Der ursprüngliche Umfang für den Agenten wurde aus einem anderswo verfassten Briefing übernommen. Er klang plausibel und enthielt den gesamten nötigen Fachjargon, um vollständig zu wirken. Diese anfängliche Plausibilität ist oft der irreführendste Aspekt technischer Planung.

Ein aus dem Briefing eines anderen übernommener Umfang ist eine Prämisse, keine Tatsache. Die technische Herausforderung bestand nicht darin, zu lösen, wie man den Agenten einschränkt, sondern zu bestimmen, ob der Agent überhaupt existieren sollte. Sich auf Implementierungsdetails zu konzentrieren, bevor die Kernprämisse geprüft ist, ist eine verbreitete Falle.

Die Prämisse zu prüfen kostete nur einen Durchgang durch die Anforderungsliste, Punkt für Punkt. Dieser einfache Prüfschritt erwies sich als der günstigste Schritt der gesamten Übung und beseitigte erfolgreich das gesamte Projekt.

Wann sich ein Agent tatsächlich lohnt

Ein Agent lohnt sich dort, wo die Arbeit im Sammeln und Verschriftlichen besteht, verteilt über Systeme, die keinen gemeinsamen Technologie-Stack teilen, und wo das nützliche Ergebnis eine Zusammenfassung ist, die eine Person liest und danach handelt. Beobachten ist nicht diese Art von Arbeit: Eine Metrik, die einen Schwellenwert überschreitet, ist und bleibt Aufgabe einer Regel. Der Unterschied liegt zwischen dem Erkennen einer Bedingung, was eine Regel besser kann, und dem Zusammensetzen eines Bildes aus Dingen, die an fünf verschiedenen Orten leben, was eine Regel überhaupt nicht kann.

Ein Agent ist nicht erforderlich, wenn sich eine einzelne Bedingung als einfacher Schwellenwert ausdrücken lässt. Monitoring beobachtet die Maschinen, der Agent schreibt auf, was er gesammelt hat, und eine Person entscheidet, was damit zu tun ist. Mehr zu dieser Unterscheidung lesen Sie in wie ein kleines Team viele Systeme betreibt.

Fragen und Antworten

Brauche ich einen KI-Agenten für das Monitoring?
Nicht zwangsläufig. Zunächst sollten Sie fragen, ob sich die Monitoring-Aufgabe als einfacher Schwellenwert oder geplante Prüfung definieren lässt. Wenn die Anforderung schlicht lautet, zu prüfen, ob X größer als Y ist, ist eine Regel das richtige Werkzeug.

Wann ist ein Alert besser als ein Agent?
Ein Alert ist besser, wenn die erforderliche Maßnahme binär und unmittelbar ist, etwa wenn ein Dienst unter eine definierte Leistungsmetrik fällt. Ein Agent wird benötigt, wenn das Ergebnis eine Zusammenfassung unterschiedlicher Ereignisse sein soll, die menschliches Urteilsvermögen zur Triage erfordert.

Wie entscheidet man, ob man überhaupt einen Agenten bauen sollte?
Schlüsseln Sie den Umfang auf, bevor Sie irgendetwas entwerfen, und fragen Sie bei jedem Punkt, was ihn bereits abdeckt. Wenn jede Zeile bereits eine günstigere, laufende Lösung hat, bleibt kein Agent mehr zu bauen. Was diesen Durchgang übersteht, ist der tatsächliche Umfang - und der ist meist deutlich kleiner als das Briefing.

Bevor Sie irgendeinen Agenten bauen, lautet die wichtigste Frage: Welche Teile dieses Umfangs lassen sich nicht als Regel schreiben?