Systems Design Meditation · Edition 1
Der Agent ist nicht das System
Warum KI zu einem Infrastrukturproblem wird
Edward Calderón
Softwarearchitekt
KI beginnt, in der Infrastruktur zu verschwinden.
Nicht, weil sie weniger wichtig ist. Sondern weil sie tiefer in den Stack vordringt.
Über mehrere Jahre hinweg konzentrierte sich die öffentliche Debatte auf das Modell. Welches Modell schlussfolgert besser? Welches Modell hat den größeren Kontext? Welches Modell schreibt den besseren Code? Diese Fragen bleiben nützlich. Aber sie reichen nicht mehr aus.
Ein Modell antwortet. Ein Agent kann handeln. Sobald das System handeln kann, wird Architektur genauso wichtig wie Intelligenz.
Die Analyseeinheit hat sich verändert
Ein Sprachmodell bildet eine Eingabe auf eine probabilistische Ausgabe ab. Ein operativer Agent umgibt dieses Modell mit Speicher, Werkzeugen, Identität, Richtlinien, Warteschlangen, Datenbanken und Feedback. Er kann ein Ticket lesen, Produktionstelemetrie abfragen, eine Konfiguration ändern und einen Kunden benachrichtigen. Jeder Schritt überschreitet eine Vertrauensgrenze. Die Qualität des generierten Satzes ist nur ein kleiner Teil des Ergebnisses.
Deshalb ist das Modell nicht das System. Das Modell ist ein Teilnehmer innerhalb des Systems.
Die nützlichen Fragen kommen nun jedem bekannt vor, der Cloud- oder verteilte Infrastruktur betrieben hat: Worauf kann der Agent zugreifen? Wer hat seine Befugnisse delegiert? Was kann er verändern? Welchen Zustand hält er aufrecht? Wie wird die Aktion beobachtet? Was geschieht, wenn sie falsch ist? Lässt sich die Aktion rückgängig machen? Wer ist verantwortlich?
Werkzeugzugriff verwandelt einen Schlussfolgerungsfehler in einen möglichen Zustandsübergang. Wenn ein Chatbot eine Rückerstattungsrichtlinie erfindet, ist die Ausgabe falsch. Wenn ein Agent die Rückerstattung ausführt, das Hauptbuch aktualisiert und den Vorgang abschließt, hat sich die umgebende Organisation verändert. Das Fehlermodell beschränkt sich nicht mehr auf Text.
Design für begrenzte Aktionen
Zuverlässige Agenten-Infrastruktur braucht mehrere Grenzen. Identität sollte workload-spezifisch sein statt ein geteilter API-Schlüssel. Autorisierung sollte eng gefasst, kurzlebig und explizit hinsichtlich der erlaubten Ressourcen und Aktionen sein. Operationen mit hoher Auswirkung brauchen Freigabemechanismen. Jeder Werkzeugaufruf erfordert strukturierte Audit-Daten: Akteur, Delegator, Eingabe, Richtlinienentscheidung, Ausgabe und resultierender Zustand.
Auch Observability muss über gewöhnliches Request-Tracing hinausgehen. Ein Trace kann zeigen, dass ein Aufruf erfolgreich war, während die Geschäftsaktion fehlerhaft war. Wir müssen Modellentscheidungen mit Werkzeugaufrufen und Werkzeugaufrufe mit dauerhaften Auswirkungen verknüpfen. Die relevante Messgröße ist nicht nur Latenz oder Tokenverbrauch. Es ist die Frage, ob die beabsichtigte Invariante noch gilt.
Rollback ist ebenso konkret. Einige Aktionen lassen sich kompensieren: ein Deployment kann auf einen früheren Stand zurückgesetzt werden. Andere lassen sich nicht wirklich umkehren: eine E-Mail wurde versendet, ein Geheimnis wurde offengelegt, eine Zahlung wurde abgewickelt. Die Architektur sollte Aktionen klassifizieren, bevor ein Agent sie erhält – nicht erst nach einem Vorfall.
Denken Sie an einen Agenten, der bei Infrastrukturänderungen assistiert. Er kann gefahrlos Metriken prüfen und einen Patch vorschlagen. Das Anwenden dieses Patches auf einer Sandbox kann eine Berechtigung mit eingeschränktem Geltungsbereich erfordern. Die Produktion braucht Richtlinienbewertung, eine menschliche Freigabe für riskante Änderungen, progressives Rollout, Health-Checks und eine automatische Stoppbedingung. Der Agent kann durchgehend beteiligt sein, ohne zum unbegrenzten Administrator zu werden.
Dieses Muster ähnelt ausgereiftem DevSecOps, weil das zugrunde liegende Problem vertraut ist: Änderungen durch ein System bewegen, ohne die Kontrolle über das Risiko zu verlieren. Agenten machen die Schnittstelle flexibler, aber Flexibilität beseitigt keine operative Disziplin.
Leistungsfähigkeit ist keine Zuverlässigkeit
Ein sehr leistungsfähiges Modell in schlecht gestalteter Infrastruktur bringt ein fragiles Produkt hervor. Ein etwas weniger leistungsfähiges Modell in exzellenter Architektur kann ein wesentlich zuverlässigeres System erzeugen. Das zweite System kann Unsicherheit begrenzen, Fehler erkennen und sich wiederherstellen.
Deshalb wird auch die Enterprise-Adoption ungleichmäßig verlaufen. Demonstrationen optimieren auf sichtbare Fähigkeiten. Produktionssysteme müssen Identitätslebenszyklen, Datengrenzen, Vorfallreaktion, Kostensteuerung, regulatorische Nachweise und beeinträchtigte Abhängigkeiten bewältigen. Diese Schichten sind keine nebensächliche Verrohrung. Sie bestimmen, ob Intelligenz mit Arbeit betraut werden kann.
Die entstehenden Agenten-Standards sind nützlich, aber kein Protokoll ersetzt Architektur. Ein Agenten-Framework kann die Risikotoleranz einer Organisation nicht festlegen. Ein Modellanbieter kann nicht definieren, welche Zustandsübergänge reversibel sind. Diese Entscheidungen gehören zum System rund um das Modell.
Die praktische Richtung ist daher nicht überall Autonomie. Es ist abgestufte Autonomie: beobachten, empfehlen, innerhalb einer engen Grenze handeln, breitere Befugnisse durch gemessene Zuverlässigkeit erwerben. Das gibt Teams eine Möglichkeit zu lernen, ohne vorzutäuschen, dass probabilistische Komponenten deterministisch sind.
Intelligenz allein schafft keine zuverlässige Infrastruktur.
Architektur schon.