GPT-4 scheiterte in 99,4 % der Fälle — also nahmen wir ihm die Entscheidungen weg

Es war fast Mitternacht, und ich sah zu, wie unser Agent zum dritten Mal in Folge einen Flug in die falsche Stadt buchte.

Nicht jedes Mal eine andere falsche Stadt — die gleiche falsche Stadt. Delhi statt Dehradun. Der Nutzer hatte klar "Dehradun" eingegeben. Das LLM hatte es in seiner Chain-of-Thought-Argumentation korrekt geparst. Und dann, als es den API-Aufruf generierte, setzte es den Flughafencode für Delhi ein. Selbstbewusst. Stillschweigend. Dreimal.

Mein Mitgründer war in der Besprechung dabei. Er sagte: "Es kennt die richtige Antwort. Sieh dir den Reasoning-Trace an. Da steht wörtlich Dehradun. Und dann macht es etwas anderes."

Das war die Nacht, in der ich aufhörte zu glauben, dass bessere Prompts uns retten würden.

Wir hatten einen KI-Agenten für Reisebuchungen entwickelt — die Sorte, die mit Global Distribution Systems wie Amadeus und Sabre kommuniziert, jenen uralten Backends aus der Mainframe-Ära, die jede Flugbuchung auf dem Planeten abwickeln. Und wir taten das, was 2023 alle anderen auch taten: GPT-4 in eine dünne Orchestrierungsschicht hüllen, ihm Tools geben und beten.

Das Beten funktionierte nicht.

Die Zahl, die alles veränderte

Ein paar Wochen nach diesem Dehradun-Vorfall stieß ich auf den TravelPlanner-Benchmark — eine strenge akademische Evaluation, die LLMs bei der mehrtägigen Reiseplanung mit realen Rahmenbedingungen testet: Budgets, Transport, Verpflegung, Unterkunft. Die Art von Aufgabe, die ein kompetenter Reiseberater in zwanzig Minuten erledigt.

GPT-4s Gesamterfolgsrate: 0,6 %.

Nicht 60 %. Nicht 6 %. Null Komma sechs Prozent.

Ich las es dreimal. Dann sah ich mir die Methodik an, um sicherzugehen, dass ihnen kein Fehler unterlaufen war. War er nicht. Wenn man das fortschrittlichste Sprachmodell der Welt bittet, eine Reise zu planen, die ein Budget einhält, Flüge mit Hotels und Restaurants verknüpft und die grundlegende zeitliche Logik nicht verletzt — dann scheitert es in 99,4 % der Fälle.

Als GPT-4 gebeten wurde, Reisen mit realen Rahmenbedingungen zu planen, war es in 0,6 % der Fälle erfolgreich. Ein neuro-symbolischer Agent, der dasselbe Problem löste, erreichte 97 %.

Das System, das 97 % erreichte, verwendete kein intelligenteres Modell. Es verwendete eine grundlegend andere Architektur — eine, in der das LLM die Anfrage des Nutzers in strukturierte Daten übersetzte und dann ein deterministischer Solver die eigentliche Planung übernahm. Das LLM war der Übersetzer. Der Code war das Gehirn.

Dieser Benchmark bestätigte nicht nur unsere Frustration. Er lieferte uns eine Blaupause.

Warum scheitert Ihr KI-Agent immer wieder?

Hier ist das, worüber niemand im "KI-Agenten"-Goldrausch reden will: LLMs schlussfolgern nicht. Sie sagen voraus.

Wenn GPT-4 "entscheidet", eine Such-API aufzurufen, führt es keine Logik aus. Es sagt das statistisch wahrscheinlichste nächste Token auf Basis von Mustern in seinen Trainingsdaten voraus. In einem Gespräch ist diese Vorhersage meist gut genug. In einem zehnstufigen API-Workflow, in dem jeder Schritt vom exakten Output des vorherigen abhängt? Eine Katastrophe.

Ich begann, dies das Chain of Probability-Problem zu nennen. Angenommen, Ihr LLM macht jeden Schritt in 90 % der Fälle richtig — eine großzügige Schätzung für komplexe Tool-Nutzung. Hier ist die Rechnung:

• 1 Schritt: 90 % Erfolg
• 5 Schritte: ~59 % Erfolg
• 10 Schritte: ~34 % Erfolg

Ein Flugbuchungs-Workflow — suchen, filtern, auswählen, bepreisen, Passagierdaten erfassen, PNR erstellen, validieren, bezahlen, ticketieren — überschreitet routinemäßig zehn Schritte. Bei 34 % theoretischem Erfolg bauen Sie keine Software. Sie bauen einen Spielautomaten.

Und 34 % ist die Obergrenze. Die reale Leistung ist schlechter, wegen zweier Phänomene, auf die wir im Produktivbetrieb immer wieder stießen.

Die Halluzinationskaskade

Das erste ist das, was ich die Halluzinationskaskade nenne. In einer verketteten Architektur wird der Output von Schritt 2 zum Input von Schritt 3. Wenn das LLM früh einen subtilen Fehler macht — eine Flugankunftszeit als 14:00 Uhr statt 2:00 Uhr fehlinterpretiert — wird dieser Fehler nicht abgefangen. Er pflanzt sich fort. Der Agent bucht auf Basis der halluzinierten Zeit einen Hotel-Check-in für den falschen Tag. Die GDS-API kennt nicht die Absicht des Agenten, nur seinen Input, weshalb sie die Anfrage erfolgreich verarbeitet. Der Agent sieht eine 200-OK-Antwort und bestärkt seinen eigenen Fehler.

Am Ende steht ein "erfolgreicher" Ausführungs-Trace, der ein katastrophales reales Ergebnis produziert. Der Agent denkt, er hätte es perfekt gemacht. Der Kunde erscheint am Flughafen und stellt fest, dass dem nicht so ist.

Das zweite Phänomen ist Context Drift. Während der Agent einen mehrstufigen Plan abarbeitet, füllt sich das Kontextfenster mit Zwischendaten — Suchergebnissen, API-Antworten, Nutzernachrichten. Der Attention-Mechanismus des Modells verteilt sich immer dünner über all diese Tokens. Bei Schritt 10 hat es die Budgetvorgabe, die es in Schritt 2 korrekt erkannt hatte, praktisch "vergessen". Die Attention-Scores, gesteuert durch die Softmax-Funktion, verwässern über zu viele irrelevante Tokens.

Ich erlebte das live während einer Demo für einen potenziellen Partner. Der Agent fand in Schritt 3 ein Hotel innerhalb des Budgets. Bei Schritt 8, bei der Auswahl eines Restaurants, hatte er den Überblick über das verbleibende Budget völlig verloren. Er empfahl ein Lokal, das die Ausgabengrenze des Nutzers um 40 % gesprengt hätte. Der Partner wandte sich mir zu und sagte: "Es vergisst also einfach ...?"

Ja. Es vergisst einfach.

Was passiert, wenn KI auf einen Mainframe trifft?

Um wirklich zu verstehen, warum wir einen anderen Ansatz brauchten, muss man verstehen, wie es ist, mit Global Distribution Systems zu arbeiten.

Amadeus, Sabre, Travelport — sie sind das Rückgrat des globalen Flugverkehrs. Sie wurden in der Mainframe-Ära konzipiert und verhalten sich auch so. Eine Flugbuchung ist kein einzelner API-Aufruf. Sie ist eine endliche Zustandsmaschine mit einer präzisen Abfolge von Operationen, die nicht umgeordnet, übersprungen oder angenähert werden kann.

Man authentifiziert sich und erhält ein Session-Token. Dieses Token muss in jedem nachfolgenden Header mitgegeben werden — wenn das LLM es "vergisst" oder ein neues halluziniert, geht der gesamte Transaktionskontext verloren. Dann sucht man nach Flügen, und das GDS liefert riesige verschachtelte JSON-Payloads zurück — oft 50 KB+ — mit Fare-Basis-Codes, Gepäckmodellen, Segmentreferenzen. Das LLM muss eine bestimmte offerId aus dieser Payload extrahieren, um fortzufahren. Aber LLMs sind verlustbehaftete Kompressoren. Sie fassen zusammen. Sie kürzen. Sie "normalisieren" hilfsbereit Datenformate, die das GDS byte-genau exakt benötigt.

Eines Nachts verbrachten wir vier Stunden mit dem Debuggen eines Buchungsfehlers. Das LLM hatte einen Fare-Basis-Code "korrigiert" — einen Kleinbuchstaben in einen Großbuchstaben geändert, weil das für ein auf englischem Text trainiertes Modell "richtiger" aussah. Das GDS wies ihn mit einem kryptischen Fehler zurück: ERR 1209 - SEQUENCE ERROR. Keine Erklärung. Kein Hinweis. Nur eine Wand.

LLMs sind verlustbehaftete Kompressoren. Wenn sie Daten zwischen API-Aufrufen übertragen, "autokorrigieren" und "normalisieren" sie auf eine Weise, die die kryptografische Integrität zerstört, die Unternehmenssysteme erfordern.

Und wenn das GDS einen Fehler wie UC (Unable to Confirm) zurückgibt, hat das LLM keine Ahnung, was zu tun ist. Es ist darauf trainiert, hilfreich zu sein, also interpretiert es den Fehler als Panne und wiederholt exakt dieselbe Anfrage. Wieder. Und wieder. Wir sahen zu, wie Agenten Tausende von Tokens verbrannten und API-Ratenlimits erreichten, festgefahren in dem, was wir "Loop of Death" zu nennen begannen — immer wieder gegen eine Wand rennend, die sie nicht verstehen konnten.

Die Nacht, in der wir die Architektur umkrempelten

Der Wendepunkt kam während eines Streits.

Wir waren drei Monate im Projekt. Mein Engineering-Lead wollte weiter die Prompts verbessern — längere System-Nachrichten, mehr Beispiele, Chain-of-Thought-Anweisungen. "Wir sind so nah dran", sagte er immer wieder. "Wenn wir den Prompt für den PNR-Erstellungsschritt nur besser strukturieren ..."

Ich rief unsere Logs auf. In der Vorwoche hatten wir 47 fehlgeschlagene Buchungsversuche in unserer Testumgebung. Elf waren der Loop of Death. Neun waren halluzinierte Flughafencodes. Sechs waren das LLM, das versuchte, eine PNR zu committen, bevor es das obligatorische Feld "Received From" hinzugefügt hatte — ein Sequenzfehler, den kein noch so gutes Prompting zu beheben schien, weil das Modell kein inhärentes Konzept zeitlicher Reihenfolge hatte, das über das hinausging, was es aus Trainingsdaten aufgenommen hatte.

"Wir sind nicht nah dran", sagte ich. "Wir sind an der Obergrenze. Die Architektur ist das Problem."

In jener Woche schrieben wir alles neu. Wir baten das LLM nicht mehr zu orchestrieren. Wir ließen es nicht mehr entscheiden, welcher Schritt als Nächstes kam. Wir fütterten es nicht mehr mit rohen GDS-Antworten und hofften, dass es die richtigen Felder extrahieren würde.

Stattdessen bauten wir einen Graphen.

Für die vollständige technische Aufschlüsselung dessen, was wir gebaut haben und warum, habe ich eine ausführliche Forschungsarbeit geschrieben, die tief in die Architektur eintaucht.

Wie funktioniert neuro-symbolische KI eigentlich?

Die Kernidee ist täuschend einfach: Kontrollfluss ist keine Sprachaufgabe.

Zu entscheiden, was in einem starren Geschäftsprozess als Nächstes zu tun ist, sollte keine Frage der Token-Vorhersage sein. Es sollte eine Frage bedingter Logik sein. Die Entscheidung, "nach Zahlung zu fragen", sollte nur auslösen, wenn "Flug ist ausgewählt" UND "Preis ist bestätigt". Das ist eine boolesche Bedingung, keine probabilistische Empfehlung.

Wir teilten unser System in zwei Schichten auf:

Das LLM wurde zur Schnittstellenschicht — dem Übersetzer. Es parst die natürliche Sprache des Nutzers ("Ich möchte einen Morgenflug nach Dehradun, nicht zu teuer") in strukturierte Daten: {origin: "DEL", destination: "DED", date: "2024-03-15", time_preference: "morning", budget: "economy"}. Genau darin sind LLMs wirklich gut: das unordentliche menschliche Anliegen zu verstehen.

Der Graph wurde zur Ausführungsschicht — dem Manager. Er empfängt diese strukturierten Daten und führt die Geschäftslogik mit deterministischem Code aus. Fest codierte Knoten. Typisierte Zustandsschemata. Bedingte Kanten, die Variablen prüfen, keine Stimmungen.

Wir nutzten LangGraph, um das zu bauen, weil es die Primitive liefert, die man braucht: ein gemeinsames Zustandsschema (gestützt auf eine Datenbank, nicht auf einen Chat-Verlauf), Knoten, die einfach Python-Funktionen sind, und bedingte Kanten, die auf Basis tatsächlicher Variablenwerte routen.

Das LLM sollte der Arbeiter sein — Daten extrahieren, Text zusammenfassen, JSON formatieren —, während der Manager fest codierte Software sein sollte. Diese Umkehrung der Kontrolle ist das prägende Merkmal robuster agentischer Systeme.

In unserer Architektur ist es dem LLM buchstäblich unmöglich, Schritte zu überspringen. Es ist physisch unmöglich, dass das System eine Buchung versucht, bevor die Variable selected_offer_id im State befüllt wird. Nicht weil wir dem LLM in einem Prompt gesagt haben "tu das nicht", sondern weil die Graph-Kante nicht auslöst. Es ist, als würde man versuchen, durch eine Wand zu fahren — der Code lässt es schlicht nicht zu.

Wie sieht das tatsächliche System aus?

Lassen Sie mich durchgehen, was passiert, wenn jemand sagt: "Buche mir einen Flug von Mumbai nach London nächsten Dienstag."

Zuerst zerlegt ein Collector-Knoten — angetrieben von einem LLM — diesen Satz in strukturierte Felder. Er nutzt geführte Generierung (JSON Mode), um ein bestimmtes Schema auszugeben. Ein Python-Validator prüft, ob die Flughafencodes echt sind. "London" ist mehrdeutig — Heathrow oder Gatwick? — also routet der Graph zu einem Disambiguierungsknoten. Das LLM rät nicht. Es fragt nach.

Sobald wir validierte Suchkriterien haben, ruft ein Retriever-Knoten die Amadeus-API auf. Das ist reiner Code. Kein LLM beteiligt. Die Antwort kommt zurück, wird im State zwischengespeichert, und erst dann konvertiert ein Summarizer-Knoten — ein LLM — die fünf besten Ergebnisse in eine menschenlesbare Nachricht. Aber er ist streng eingeschränkt: Er darf nur Daten anzeigen, die im zwischengespeicherten JSON vorhanden sind. Er kann keine Extras erfinden oder Preise ändern.

Der Nutzer wählt eine Option. Ein Selector-Knoten löst "das zweite" zum spezifischen offer_id-Hash auf. Ein Gatekeeper-Knoten prüft Geschäftsregeln — liegt das innerhalb der Unternehmensrichtlinie? Ist der Carrier auf der schwarzen Liste? Wenn es einen Verstoß gibt, suspendiert der Graph. Er persistiert seinen State in die Datenbank, sendet eine Genehmigungsanfrage an einen Manager und wartet. Stunden später, wenn der Manager auf "Genehmigen" klickt, lädt der Graph den exakten State neu und setzt am Buchungsknoten fort.

Schließlich führt ein Transactor-Knoten die PNR-Erstellungssequenz aus — Segmente, Passagierdaten, Bepreisung, Commit — in genau der Reihenfolge, die das GDS verlangt. Wenn das GDS eine Preisänderungswarnung zurückgibt (im Reisebereich häufig), hält der Knoten an und bittet den Nutzer um Bestätigung. Er bucht nicht automatisch zum höheren Tarif.

Jeder Knotenübergang wird protokolliert. Jede Entscheidung ist nachvollziehbar. Ein Prüfer kann das Ausführungsprotokoll lesen und genau verstehen, warum das System einen bestimmten Flug gebucht hat — nicht durch Interpretation eines Wusts von Tokens, sondern durch Lesen eines strukturierten Datensatzes: Node:Gatekeeper | Input: Price=1200 | Rule: Policy_Limit=1000 | Output: REJECT_NEED_APPROVAL.

Ich habe über die vollständige Architektur, einschließlich der interaktiven Diagramme, in der interaktiven Version des Whitepapers geschrieben.

Ist das nicht einfach ... ganz normales Software-Engineering?

Das fragen mich Leute ständig. "Sie sagen also, wir sollten Code schreiben, statt KI zu nutzen? Revolutionär."

Nein. Ich sage, dass die KI-Branche so berauscht war von der Magie der Sprachmodelle, dass sie die letzten sechzig Jahre Informatik vergessen hat. Zustandsmaschinen, typisierte Schemata, bedingte Verzweigung, transaktionale Integrität — das sind keine überholten Konzepte. Sie sind der Grund, warum Ihre Bank nicht versehentlich Geld auf das falsche Konto überweist.

Der neuro-symbolische Ansatz ist nicht KI-feindlich. Er ist architekturfreundlich. Wir setzen LLMs aggressiv ein — für Intent-Parsing, für Disambiguierung, für Zusammenfassung, für die Bewältigung des wirklich schwierigen Problems zu verstehen, was ein Mensch meint, wenn er etwas Mehrdeutiges eingibt. Aber wir lassen das LLM nicht ans Lenkrad, wenn das Auto auf der Autobahn ist.

Man kann einen Chatbot bauen, der davon redet, Arbeit zu erledigen, oder man kann einen Agenten konzipieren, der die Arbeit tatsächlich erledigt. Der Unterschied ist der Graph.

Es gibt auch ein Kostenargument, das mich überraschte. Reine LLM-Agenten sind teuer — nicht weil Inferenz pro Aufruf kostspielig ist, sondern wegen der Fehlerschleifen. Wenn ein Agent feststeckt und einen GDS-Fehler durch Halluzinieren neuer Parameter immer wieder wiederholt, verbrennt er Tausende von Tokens, bevor er in einen Timeout läuft. Eine einzige festgefahrene Sitzung kann $5–$10 an API-Credits kosten. Unsere fest codierten Fehlerbehandler fangen diese Fehler bei null Token-Kosten ab. Und weil wir dem LLM nur die 5 relevanten Felder aus einer 50 KB großen GDS-Antwort senden statt der ganzen Sache, reduzieren wir die Kontextfensternutzung um rund 90 %.

Aber werden Modelle nicht irgendwann gut genug sein?

Vielleicht. Ich weiß wirklich nicht, ob GPT-6 oder GPT-7 zuverlässig genug sein werden, um zehnstufige API-Workflows ohne Guardrails zu orchestrieren. Aber zwei Dinge weiß ich.

Erstens, selbst wenn Modelle sich dramatisch verbessern, ist das Chain of Probability-Problem mathematischer Natur, nicht technologischer. Wenn Ihr Modell pro Schritt zu 99 % zuverlässig ist — eine außergewöhnliche Leistung —, scheitert ein zehnstufiger Workflow immer noch in 10 % der Fälle. Für Unternehmenstransaktionen ist das immer noch inakzeptabel. Der Graph eliminiert dies vollständig, weil das Routing nicht probabilistisch ist.

Zweitens ist das Warten darauf, dass Modelle besser werden, ein Luxus, den die meisten Unternehmen nicht haben. Sie brauchen Agenten, die jetzt funktionieren, die jetzt prüfbar sind, die die Transparenzanforderungen des EU AI Act jetzt erfüllen. Der neuro-symbolische Ansatz setzt nicht auf die Zukunft. Er baut auf bewährten Ingenieursprinzipien auf und nutzt dabei die besten heute verfügbaren KI-Fähigkeiten.

Die Architektur ist das Produkt

Ich saß in genug Räumen mit Investoren und Unternehmenskäufern, um zu wissen, dass die KI-Branche allmählich aufwacht. Die Frage verschiebt sich von "Wer hat das intelligenteste Modell?" zu "Wer hat das robusteste System?" Die Demos, die in einem Konferenzvortrag beeindrucken — jene, in denen ein Agent in einer kontrollierten Umgebung tadellos einen Flug bucht — sind billig. Teuer, und worauf es ankommt, ist, etwas zu bauen, das bei der zehntausendsten Anfrage so zuverlässig funktioniert wie bei der ersten.

Wir treten in eine Ära ein, in der die Differenzierung nicht das Modell sein wird. Es wird der Graph sein. Das Zustandsschema. Die Fehlerbehandler. Die bedingten Kanten. Das langweilige, rigorose, deterministische Software-Engineering, das sich um die probabilistische Magie legt und verhindert, dass sie das Haus niederbrennt.

Die Magie lag nie im Prompt. Sie lag immer in der Architektur.