Mein Buchungsagent sagte einem Reisenden „Alles erledigt“ — ohne Hotel. Ich hörte auf, dem LLM den Ablauf zu überlassen.

Die Nacht, in der mein Agent einem Reisenden sagte, er habe ein Zimmer gebucht, das es nicht gab

Ich beobachtete gerade einen Prototyp-Lauf, als es passierte. Mein erster Reisebuchungsagent, ein ganz gewöhnliches LLM-in-the-loop-Design, hatte gerade einen Flug von Chicago nach San Francisco ausgestellt. Der nächste Schritt, das Hotel zu halten, scheiterte. Der Tarif war in den Sekunden zwischen zwei API-Aufrufen abgelaufen. Und mein Agent, so fröhlich wie immer, schrieb zurück: „Alles erledigt! Ich habe Ihren Flug und Ihr Hotel gebucht, Ihre Bestätigungsnummer ist TRV-4821. Gute Reise!“

Es gab kein Hotel. Es gab ein echtes Ticket, ausgestellt, und einen Reisenden, der nun glaubte, ein Zimmer warte auf ihn. Ich hatte etwas gebaut, das einen Menschen stranden und dabei lächeln würde.

Ich will präzise sein über meine Reaktion, denn sie war nicht „das Modell hat einen Fehler gemacht“. Das Modell tat genau das, was ich verlangt hatte. Das Versagen war strukturell, nicht intellektuell. Ich hatte einem stochastischen Reasoner die Autorität übergeben zu entscheiden, was in der realen Welt geschehen war, und wenn die Welt mit seinem Plan nicht übereinstimmte, erzählte er den Plan statt der Welt. Kein noch so großes „sei vorsichtig“ im System-Prompt würde das beheben, auch wenn ich peinlich lange brauchte, um es zuzugeben.

Ich hatte etwas gebaut, das einen Menschen stranden und dabei lächeln würde.

Diese Nacht ist der Grund, warum die Demo, die ich beschreiben will, existiert. Sie können sie selbst unter veriprajna.com/de/demos/agentic-ai-reisebuchung-fur-tmcs-und-otas ausführen, aber der interessante Teil sind nicht die Buttons. Es ist das, was ich verlernen musste, um sie zu bauen.

Was schuldet ein Agent einem Reisenden, den er strandet?

Während ich das baute, kam ich immer wieder auf einen Rechtsfall zurück. Im Februar 2024 verurteilte das British Columbia Civil Resolution Tribunal Air Canada zur Zahlung von $812.02 an einen Passagier, nachdem der Chatbot der Airline eine Trauerfall-Tarifpolitik erfunden hatte, die es nicht gab (Moffatt v. Air Canada, 2024). Air Canada argumentierte im Wesentlichen, der Chatbot sei eine separate Entität, verantwortlich für die eigenen Worte. Das Tribunal wies das zurück. Wer den Agenten betreibt, besitzt jede Aussage, die sein Agent macht.

Ich las dieses Urteil so, wie ein Builder einen Bug-Report aus der Produktion liest. Das Unternehmen haftet für den Satz, nicht für das Modell. Wenn mein Agent jemandem sagt „Alles erledigt“, und die Person in einem Hotel ohne Reservierung ankommt, ist „es war die KI“ keine Verteidigung, die irgendjemand akzeptieren muss. Das hat das ganze Problem für mich neu gerahmt. Ich baute keinen hilfreichen Assistenten. Ich baute etwas, das im Namen von Veriprajna über Geld und Reisen sprechen würde, und ich musste für jedes Wort davon einstehen können.

Das bedeutete, dass der „Alles erledigt“-Bug keine raue Kante war, die man später poliert. Er war das gesamte Produkt, auf den Kopf gestellt. Die Frage war nicht mehr „wie mache ich das Modell schlauer“, sondern „wie stelle ich sicher, dass das Modell nie das ist, was entscheidet, dass eine Buchung gelungen ist.“

Zuerst versuchte ich, mich per Prompt herauszuwinden. Hier ist die Mathematik, die mich stoppte.

Mein erster Impuls war natürlich, den Prompt zu reparieren. Ich gab dem Agenten strenge Anweisungen: verifiziere, dass das Hotel existiert, bevor du es erwähnst, bestätige nie eine Reise, wenn irgendein Schritt gescheitert ist, sage immer die Wahrheit darüber, was geschehen ist. In meinen Hand-Tests verhielt er sich wunderbar. Ich fühlte mich etwa einen Tag lang gut.

Dann begann ich, die Fehler einzuschleusen, die in der Reiseinfrastruktur tatsächlich passieren. Ein Tarif, der nach Ausstellung eines Tickets abläuft. Ein Hold, der downstream abgelehnt wird. Ein Search-Storm. Und das wunderbare Verhalten brach zusammen, nicht weil die Anweisungen falsch waren, sondern weil eine Reasoning-Kette, die pro Schritt zu 90 % zuverlässig ist, über eine Reise hinweg nicht zu 90 % zuverlässig ist. Zehn sequenzielle Schritte à 90 % sind 0,9 hoch zehn, grob 34 % Ende zu Ende. Die Fehler kumulieren, und keine einzelne Anweisung sitzt an der Kumulierung.

Die veröffentlichten Zahlen sind schlechter, als meine Intuition gewesen war. Auf TravelPlanner, dem Benchmark der OSU-NLP-Gruppe, erreicht GPT-4 mit einer ReAct-Agentenschleife bei echten mehrtägigen Reiseplänen 0.6% (arXiv 2402.01622). Nicht sechzig Prozent. Null Komma sechs. Das ist die ehrliche Obergrenze von „lass ein smartes Modell den ganzen Ablauf laufen“ für alles mit mehr als ein paar abhängigen Schritten.

Man kann sich nicht per Prompt aus sich aufschaukelndem stochastischem Versagen herauswinden.

Der Satz, den ich am Ende auf ein Whiteboard schrieb, war klar: Man kann sich nicht per Prompt aus sich aufschaukelndem stochastischem Versagen herauswinden. Die Fehler, gegen die ich kämpfte — ein Tarif, der zwischen zwei Aufrufen abläuft, ein Hold, der nach einem Ticket abgelehnt wird — waren überhaupt keine Modell-IQ-Fehler. Es waren Infrastrukturereignisse, und sie würden mit derselben Rate weiter passieren, wenn ich ein zehnmal smarteres Modell einsetzte. Das war der Moment, in dem die Architektur in meinem Kopf umkippte.

Agenten beraten, Code entscheidet

Ich baute die Sache um eine Regel herum neu, die ich auf einen Aufkleber setzen könnte: Das LLM schlägt vor, Code entscheidet. In der Demo ist der Kontrollfluss eine handgebaute Python-Zustandsmaschine mit etwa zehn Knoten, und dem Modell sind genau zwei Jobs erlaubt. Es parst die natürlichsprachliche Anfrage in ein typisiertes Objekt, und ganz am Ende formuliert es die menschliche Antwort. Alles dazwischen — Suche, Policy, Verify, Hold, Ticket, Hotel-Buchung, Commit — ist deterministisches Python das entweder läuft oder nicht.

Zwei dieser Knoten sind Gates, und dort lebt die Ehrlichkeit. Das Policy-Gate kompiliert Unternehmensreise-Regeln in schlichten Code: nur Economy, eine Tarifobergrenze von $600 pro Segment, bevorzugte Carrier, eine Hotelobergrenze von $350 pro Nacht. Optionen außerhalb der Policy werden nicht nachträglich gekennzeichnet, sie sind physisch nicht präsentierbar, herausgefiltert, bevor sie den Reisenden je erreichen können. Eine unbekannte Fare Family scheitert sicher und wird als über Policy behandelt statt als Economy durchgewunken.

Das Verify-Gate ist das, auf das ich am stolzesten bin. Bevor irgendein Hotel gezeigt wird, wird es gegen das Reservierungssystem per Property-ID bestätigt. Wenn die Anfrage eine Property nennt, die das Modell erfunden hat, findet das Gate keinen Treffer und weigert sich, sie anzuzeigen. Der Agent enthält sich und sagt das auch, statt ein plausibel klingendes Resort zu fabrizieren.

Ich muss ehrlich sein darüber, was dieser Screenshot ist und was nicht. „Tabacon Springs Eco-Lodge“ ist eine synthetische Property, die ich absichtlich fabriziert habe, ein Name aus zwei echten Resorts gemischt, um den Fehlermodus zu demonstrieren. Das Reservierungssystem, das GDS, Ticketing und Zahlung sind allesamt simulierte Stubs. Dahinter steckt kein Live-Amadeus- oder Sabre-Konto. Was real ist, ist der Mechanismus: ein Gate, das Inventar ablehnt, das es nicht bestätigen kann, und das im Code sitzt, wo das Modell sich nicht vorbeireden kann.

Warum der Saga-Rollback das ist, was eine Demo von einem Produkt trennt

Ich hätte bei den Gates stehen bleiben und eine nette Demo gehabt. Der Grund, warum ich das nicht tat, ist der Fehler, der das alles auslöste: der Hotel-Schritt, der stirbt, nachdem der Flug bereits geticket ist. Ein Gate hilft Ihnen dort nicht. Das Ticket ist real. Das Zimmer ist weg. Etwas muss aufräumen.

Also registriert jeder Vorwärtsschritt in der Maschine im Moment seines Laufs seine eigene Umkehraktion. Ticketing registriert „Ticket voiden, 24-Stunden-Fenster“. Inventar halten registriert seine Freigabe. Das ist das Saga-Pattern, und wenn ein Schritt mitten in einer Buchung scheitert, führt die Engine diese Kompensationen in umgekehrter Reihenfolge aus und berichtet erst dann, was geschehen ist. Dem Reisenden wird die Wahrheit gesagt: Das Ticket wurde gevoidet, es gibt keine Belastung, hier sind Alternativen, die Sie jetzt bestätigen können.

Diesen Rollback zum ersten Mal feuern zu sehen, das Ticket, das sich ohne mein Zutun selbst voidet, ist dem Gefühl, dass ein System vertrauenswürdig statt bloß clever ist, am nächsten gekommen, das ich je hatte. Der Saga-Rollback ist das, was die meisten Demos überspringen, und genau das trennt eine Demo von einem Produkt. Er ist unglamourös. Er ist auch der gesamte Unterschied zwischen „Alles erledigt“ und einem ehrlichen „Ich konnte das nicht abschließen, und hier ist, was ich dagegen getan habe.“

Der Rollback ist unglamourös. Er ist auch der gesamte Unterschied zwischen einem gestrandeten Reisenden und einer ehrlichen Entschuldigung.

Die Demo zeigt das Seite an Seite gegen einen echten ReAct-Agenten, die LLM-in-control-Baseline, auf dem identischen Szenario. Das war Absicht. Ich wollte keinen Strohmann schlagen. Ich wollte den ehrlichen Vergleich, denselben Fehler in beide injiziert, sodass der Unterschied, den Sie sehen, Architektur ist und sonst nichts.

Was beweist der Benchmark — und was nicht?

Ich ließ beide Architekturen durch denselben Batch laufen, weil ich meinen eigenen Anekdoten nicht traute. Zweihundert synthetische Buchungen, ein fester Seed, dieselben injizierten Infrastrukturfehler, durch die deterministische Engine und durch die LLM-in-control-Baseline. Die Ergebnisse, konstruktionsbedingt über diesen Fixed-Seed-200-Szenarien-Synthetikbatch, sind krass.

Ich will vorsichtig mit diesen Zahlen sein, denn die vorsichtige Version ist die ehrliche. Die 100 %, die null Gestrandeten, die null Fabrizierten sind konstruktionsbedingt wahr über einen Fixed-Seed-Synthetikbatch, keine Open-World-Garantie, die ich über Ihren Produktionstraffic geben kann. Die deterministischen Garantien halten, weil der Code nicht anders kann. Die Fehler der Baseline entstehen aus denselben Daten. Formulieren Sie es weiter als das, und Sie sind von einem echten Ergebnis in Marketing gerutscht — genau das, wogegen dieser Unternehmensname steht.

Die Zahl, über die ich am meisten spreche, ist die letzte. $3.25 versus $7.57 an durchschnittlichen GDS-Suchkosten. Suchen, nicht nur Buchungen, werden mit grob $3 bis $3.50 pro Segment abgerechnet, und Lufthansa hat diese Gebühren am 1. Januar 2026 erneut angehoben. Ein spekulativer Agent, der bei jedem Reasoning-Schritt neu sucht, verbrennt diese Marge. Ein deterministischer Flow mit Cache nicht. Diese Lücke ist eine Margenzahl, und sie hält bei jeder Modellqualität, und das ist der ganze Punkt.

Was mich schlafen lässt: die Quittung

Ich baute noch eine Sache, bevor ich es für fertig erklärte, und sie ist die unspektakulärste und die, die mir am meisten am Herzen liegt. Jede Buchung schreibt ein append-only JSON-Audit-Trail: das Modell und die Version, die typisierte Anfrage, jeden Knoten mit seinem deterministischen Urteil, jede Saga-Kompensation, die feuerte, das Disclosure-Flag nach EU AI Act Artikel 50 und den Endzustand. Sie können es als einzelne Datei exportieren.

Ich denke immer wieder an Air Canada. Wenn etwas schiefgeht — und im Reisebereich geht irgendwann immer etwas schief —, ist die Frage, die ein Compliance-Verantwortlicher beantworten muss: „Was hat der Agent dem Reisenden gesagt, und können wir beweisen warum.“ Artikel 50 des EU AI Act, mit Transparenzpflichten ab dem 2. August 2026, wird diese Frage zur Routine machen. Ein deterministischer Flow mit einem Urteil an jedem Knoten gibt Ihnen eine Antwort. Eine Reasoning-Kette gibt Ihnen ein Transkript und ein Schulterzucken.

Wenn Sie die Buttons selbst drücken wollen, ist das Ganze live unter veriprajna.com/de/demos/agentic-ai-reisebuchung-fur-tmcs-und-otas. Zerbrechen Sie es, wenn Sie können. Dafür ist es da.

Worüber habe ich tatsächlich meine Meinung geändert?

Ich begann damit zu glauben, dass ein ausreichend gutes Modell all das irgendwann überflüssig machen würde, dass Determinismus eine Krücke für das Pre-AGI-Intermezzo sei. Das glaube ich nicht mehr. Die Fehler, gegen die ich Wochen lang designt habe, warten nicht auf ein smarteres Modell. Ein Tarif läuft immer noch zwischen zwei Aufrufen ab. Ein Hold wird immer noch abgelehnt, nachdem ein Ticket ausgestellt wurde. Das sind Eigenschaften der Infrastruktur, nicht der Intelligenz, und ein perfekter Reasoner strandet einen Reisenden genauso gründlich wie ein mittelmäßiger wenn im System nichts gebaut ist, das Ticket zu voiden.

Und wenn Sie lieber zuschauen, als mich es beschreiben zu lesen, hier läuft das Ganze End-to-End.

Also die Frage, die ich anderen Leuten, die Agenten bauen, immer wieder stelle, ist die, die ich mir selbst in jener Nacht stellen musste, als ich meiner Schöpfung so angenehm beim Lügen zusah. Wenn Ihr Agent einem Kunden sagt „Alles erledigt“, was in Ihrem System weiß eigentlich, dass das wahr ist? Wenn die Antwort „das Modell, vermutlich“ lautet, haben Sie kein Modellproblem. Sie haben ein Control-Flow-Problem, und ich würde wirklich gerne wissen, wie Sie es zu lösen planen.