Ein halluzinirender Fahrer am Steuer braucht bessere Bremsen, nicht mehr Gas

Deterministische Software hat eine Eigenschaft, die so selbstverständlich ist, dass niemand darüber spricht: Derselbe Input liefert immer dasselbe Ergebnis. Ein API-Aufruf, ein Stacktrace, ein reproduzierbarer Bug. Agentic Workflows brechen diesen Grundvertrag. Und die meisten Teams merken es erst in Produktion.

Key Takeaways (TL;DR)

• LLMs als Funktion behandeln: Reduziere das Sprachmodell gedanklich auf eine fehleranfällige Text-in-Text-out-Funktion. Deine Architektur-Ressourcen gehören in die Leitplanken, nicht in das Modell.
• Validierung an den Grenzen erzwingen: Jede Ein- und Ausgabe des Modells braucht strikte Typen-Validierung. Was das Modell intern tut, ist nicht dein Problem. Was es ausgibt, schon.
• Fehlerbudgets für Halluzinationen einplanen: Probabilistische Systeme halluzinieren. Nicht manchmal, sondern systembedingt. Entwirf Fallback-Pfade, bevor du den Happy Path baust.
• Logging als Architektur-Entscheidung begreifen: Ohne semantisches Logging wirst du die Entscheidungswege eines Agenten nicht nachvollziehen können. Cognitive Debt entsteht nicht nur durch Code, sondern auch durch opake Laufzeitentscheidungen.

Der Kontrollfluss gehört nicht mehr dir

In klassischer Software entscheidet der Entwickler, was wann passiert. Jeder Pfad ist vordefiniert, jede Verzweigung explizit. Ein if-Statement ist deterministisch. Ein try-catch fängt definierte Fehlerzustände ab. Das System tut exakt das, was im Code steht, nicht mehr und nicht weniger.

Agentic Workflows funktionieren fundamental anders. Das Modell entscheidet zur Laufzeit, welche API es aufruft, wie es die zurückgegebenen Daten interpretiert, ob es den Prozess wiederholt und wann es ein Ergebnis als abgeschlossen betrachtet. Der Output ist keine Gewissheit. Er ist eine Wahrscheinlichkeitsverteilung.

Das klingt nach einem Paradigmenwechsel, und genau dieses Framing ist das Problem. Die Hype-Erzählung suggeriert, dass traditionelles Programmieren durch iteratives Prompting ersetzt wird und die Komplexität dabei irgendwie verschwindet. Das Gegenteil trifft zu.

Probabilistisch heißt nicht intelligent, sondern unberechenbar

Der Unterschied zwischen einem deterministischen Bug und einem probabilistischen Fehler ist fundamental. Der deterministische Bug ist reproduzierbar. Du gibst denselben Input, bekommst denselben kaputten Output, findest den Fehler, fixst ihn. Erledigt.

Ein probabilistisches System verhält sich bei identischem Input unterschiedlich. Der Agent wählt am Montag API A, am Dienstag API B, am Mittwoch entscheidet er, dass er gar keine API braucht, und halluziniert eine Antwort. Der Fehler tritt in 3 von 100 Fällen auf, unter Bedingungen, die du im Vorfeld nicht spezifizieren kannst.

Debugging in diesem Kontext erfordert nicht bessere Tools. Es erfordert ein anderes Denkmodell. Statt nach dem einen kaputten Pfad zu suchen, musst du den gesamten Entscheidungsraum des Agenten überwachen. Und genau dafür fehlt den meisten Teams die Architektur.

Die eigentliche Arbeit liegt nicht im Modell

Ein paar Skripte zusammenzukleben, die einen Agenten in einer isolierten Demo-Umgebung laufen lassen, ist trivial. Das sind die Demos auf Konferenzen, die LinkedIn-Posts mit dem Tenor „Ich habe eine komplette App in 20 Minuten gebaut”. Stimmt sogar, für eine Definition von „App”, die keine Fehlerbehandlung, keine Authentifizierung, kein Logging und keine Compliance kennt.

Die eigentliche Engineering-Arbeit in Agentic Workflows verteilt sich auf vier Bereiche, die alle nichts mit dem Modell selbst zu tun haben:

1. Typen-Validierung an den Grenzen. Das Modell gibt Text aus. Dieser Text muss gegen ein striktes Schema validiert werden, bevor er irgendeinen nachgelagerten Prozess triggert. Jede unvalidierte Modell-Ausgabe ist eine potenzielle Injection.

2. State Machines für den Agenten-Lebenszyklus. Welche Berechtigungen hat der Agent in welchem Zustand? Welche Aktionen sind nach welchem Schritt erlaubt? Ohne explizite Zustandsmodellierung entscheidet das Modell implizit über seinen eigenen Handlungsspielraum.

3. Fallback-Mechanismen gegen Endlos-Loops. Ein Agent, der sich selbst korrigiert, kann sich auch selbst in eine Schleife korrigieren. Ohne harte Abbruchbedingungen, Timeout-Budgets und Token-Limits pro Durchlauf wird aus Selbstkorrektur ein unkontrollierter Ressourcenverbrauch.

4. Semantisches Logging. In deterministischer Software reicht ein Stacktrace. In probabilistischen Systemen musst du nachvollziehen können, warum der Agent sich für Pfad A statt Pfad B entschieden hat. Das erfordert strukturiertes Logging der Entscheidungsgründe, nicht nur der Ergebnisse.

Frameworks mit Magie lösen das falsche Problem

Die aktuelle Generation von Agent-Frameworks wirbt mit Einfachheit. Wenige Zeilen Code, das Framework kümmert sich um den Rest. Das ist genau das Versprechen, das in der Praxis die teuersten Systeme produziert.

Der Grund ist strukturell. Diese Frameworks abstrahieren die Kontrolle über das Modellverhalten hinter High-Level-APIs. Solange der Happy Path funktioniert, sieht das elegant aus. Sobald ein Edge Case in Produktion auftritt, stehst du vor einer Blackbox. Du kannst den Fehler nicht reproduzieren, weil das Verhalten probabilistisch ist. Du kannst den internen Zustand nicht inspizieren, weil das Framework ihn kapselt. Du kannst den Fallback nicht anpassen, weil die Abstraktionsschicht ihn nicht exponiert.

Das ist kein theoretisches Risiko. Es ist das exakte Muster, das bei jedem Abstraktions-Hype in der Softwaregeschichte auftritt: ORMs, die SQL kapseln, bis die erste komplexe Query Performance-Probleme verursacht. Serverless-Funktionen, die Infrastruktur abstrahieren, bis Cold Starts das Nutzererlebnis zerstören. Die Abstraktion funktioniert, bis sie es nicht tut. Und dann fehlt das Verständnis der darunterliegenden Schicht.

3 Schritte für eine wartbare Agentic-Architektur

1. Behandle das LLM als fehleranfällige Textfunktion. Keine Magie, keine Intelligenz, kein „Verstehen”. Input rein, Text raus. Dein gesamtes Architektur-Budget fließt in die deterministische Schicht um das Modell herum: Validierung, Zustandsmodellierung, Berechtigungen, Abbruchbedingungen.

2. Baue den Fallback-Pfad vor dem Happy Path. Definiere zuerst, was passiert, wenn der Agent halluziniert, in einen Loop gerät oder ein unerwartetes Format zurückgibt. Erst wenn die Fehlerpfade stehen, implementierst du den Normalbetrieb. In deterministischer Software ist das übertrieben. In probabilistischen Systemen ist es die einzige Überlebensversicherung.

3. Investiere in Observability wie in ein Produktions-Feature. Strukturierte Logs der Agenten-Entscheidungen, Token-Verbrauch pro Durchlauf, Diff zwischen erwartetem und tatsächlichem Output. Wenn du nicht erklären kannst, warum dein Agent gestern um 14:37 Uhr eine bestimmte Entscheidung getroffen hat, betreibst du kein Engineering. Du betreibst Glücksspiel mit SLA.

Die Werkzeuge werden mächtiger. Die Modelle werden billiger. Und die Strafe für schlechtes, undiszipliniertes Engineering wird in probabilistischen Systemen nicht linear, sondern exponentiell höher ausfallen.