Agentic-AI-Reisebuchung für TMCs und OTAs

Der entscheidende Schritt für einen Buchungsagenten ist kein smarteres Modell. Es ist, das LLM aus dem Kontrollfluss zu nehmen.

Wir haben einen autonomen Reisebuchungsagenten gebaut, dessen Kontrollfluss deterministisches Python ist. Das Modell parst nur die Reiseanfrage und formuliert die Antwort. Jeder Buchungsschritt registriert eine Kompensationsaktion, sodass der Agent, wenn ein Hotelpreis nach der Ticketausstellung abläuft, das Ticket innerhalb des 24-Stunden-Fensters voidet und dem Reisenden ehrliche Alternativen übergibt, statt ihn stranden zu lassen.

100%

Konsistenter Endzustand, konstruktionsbedingt

Synthetischer Batch mit festem Seed und 200 Szenarien, vs. 65% für die LLM-in-control-Baseline

0 / 0

Gestrandete Reisende, erfundene Buchungen angezeigt

Derselbe Batch, vs. 40 und 30 für die Baseline

$3.25

Durchschn. GDS-Suchkosten pro Buchung

vs. $7.57 Baseline; GDS berechnet pro Suche, Lufthansa hat die Gebühren am 1. Januar 2026 erhöht

Alle Szenarien sind synthetisch über ein simuliertes GDS und CRS; Flughafencodes und Hotelnamen sind real geformte Fixtures, kein Live-Inventar und keine echten Buchungen.

Wenn man ein LLM eine Transaktion steuern läßt, gehen zwei Dinge schief

Keines davon ist ein Versagen der Modell-IQ. Beides ist bereits eine Fehlerklasse von 2026.

Es läßt Reisende stranden

Der Agent ticketet einen Flug, der Hotelschritt schlägt fehl, und ohne Kompensationslogik sagt er trotzdem „Alles erledigt.“ Jemand bleibt mit einem Flug und ohne Zimmer zurück. Ein perfektes Modell läßt einen Reisenden trotzdem stranden, wenn nichts das Ticket voidet.

Es zeigt Inventar an, das nicht existiert

Es erfindet ein plausibles Hotel und bucht es. Die Unterkunft war nie im CRS. Nichts hat geprüft, bevor es den Reisenden erreichte, weil in einer Reasoning-Schleife das Modell sowohl Vorschlagender als auch Richter ist.

Der Grund, warum ein besseres Modell das nicht behebt, liegt darin, dass die Ausfälle Infrastruktur- und Nutzungsereignisse sind, unabhängig von der Modellqualität. Ein Tarif läuft zwischen zwei API-Aufrufen ab. Ein Hold wird abgelehnt, nachdem ein Ticket ausgestellt wurde. Ein Suchsturm verbrennt Marge. Stochastisches Reasoning verstärkt das: zehn Schritte bei 90 Prozent Zuverlässigkeit ergeben rund 34 Prozent Ende-zu-Ende, und GPT-4 mit ReAct schließt echte mehrtägige Reisepläne zu 0.6 Prozent ab (TravelPlanner, OSU NLP, arXiv 2402.01622). Man kommt mit Prompting nicht aus kumuliertem stochastischem Versagen heraus.

Und der Deployer besitzt jede Aussage, die der Agent macht. In Moffatt v. Air Canada (BC Civil Resolution Tribunal, 14. Februar 2024) wurde die Airline zur Zahlung von $812.02 verurteilt, nachdem ihr Chatbot eine Trauerfalltarif-Richtlinie erfunden hatte, und das Argument, die KI sei eine eigenständige Entität, wurde zurückgewiesen.

So funktioniert es: Agenten beraten, Code entscheidet

Der Kontrollfluss ist eine handgebaute Python-Zustandsmaschine mit rund zehn Knoten. Das LLM ist auf zwei Blatt-Aufgaben beschränkt. Alles dazwischen ist deterministisch.

input → extract (LLM leaf) → search → policy gate → verify gate → hold → ticket → hotel-book → commit

Extract, die einzige strukturierte Aufgabe des LLM

Das Modell parst natürlichsprachliche Absicht in ein Pydantic-typisiertes TripRequest (origin, destination, date, passengers, cabin, hotel). Dieses typisierte Objekt ist das einzige strukturierte Artefakt, das das LLM erzeugt. Es ist über Pydantic AI anbieterseitig austauschbar und läuft vollständig offline mit einem deterministischen Stub, wenn kein Schlüssel vorhanden ist.

Policy in Code kompiliert

Die Unternehmens-Policy lebt als reine Python-Prädikate: nur Economy, eine Tarifobergrenze von $600 pro Segment, bevorzugte Carrier (United, American, Delta), eine Hotelobergrenze von $350 pro Nacht. Optionen außerhalb der Policy sind physisch nicht präsentierbar, weil sie gefiltert werden, bevor sie gezeigt werden können, nicht danach markiert. Unbekannte Tarifklassen fail-safe: sie gelten als über der Policy, nicht stillschweigend als Economy. Ohne einen Policy-konformen Flug eskaliert der Agent an eine menschliche Queue, statt zu bluffen.

Das Verifikationstor

Jedes Hotel wird gegen das CRS bestätigt anhand von property_id. Eine Unterkunft, die das Modell erfindet, ist schlicht nicht im CRS, wird daher abgelehnt und nie angezeigt, und die Buchung erreicht den Endzustand abstained. Das Tor lehnt unbestätigtes Inventar ab; es bittet das Modell nicht, die eigene Ausgabe zu bewerten.

Die Saga, der Teil, den die meisten Demos überspringen

Jeder Vorwärtsschritt registriert zum Ausführungszeitpunkt seine Umkehraktion. Ticketausstellung etwa registriert „Ticket voiden, 24-Stunden-Fenster.“ Bei einem Fehler in Schritt N laufen die Kompensationen von N-1 bis 1 in umgekehrter Reihenfolge, und erst dann berichtet der Agent. Das trennt eine Demo von einem Produkt, weil genau das verhindert, dass ein Teilausfall zu einem gestrandeten Kunden wird.

Der GDS-Kostenmesser und der Prüfpfad

Ein Live-Zähler erfasst GDS-Suchkosten von $3.25 pro Segment, weil Suchen berechnet werden, nicht nur Buchungen. Ein L2B-Cache und aufgeschobene Suche halten das flach, wo ein spekulativer Agent erneut sucht und Marge verbrennt. Jede Buchung schreibt ein nur anhängendes JSON-Ereignisprotokoll, exportierbar als audit-<pnr>.json, mit Modell und Version, der typisierten Reiseanfrage, jedem Knoten-Verdikt, jeder Saga-Kompensation, dem EU AI Act Article 50-Offenlegungsflag und dem Endzustand.

Was die Demo zeigt

Vier Buttons, Seite an Seite mit einer echten LLM-in-control-Baseline auf demselben Szenario. Jeder Screenshot unten stammt aus der laufenden App.

Eine normale Buchung, Knoten für Knoten

Die Demo bei einer normalen Buchung ORD nach SFO. Rechts führt die deterministische Pipeline-Spur jeden Knoten der Reihe nach aus, von der Intent-Extraktion über Policy-Gate, CRS-Verifikation, Holds, Ticketausstellung und Hotel-Commit, und endet in einem confirmed PNR, wobei der GDS-Suchkostenmesser $3.25 anzeigt. Links antwortet das Panel mit der Bezeichnung No Tools and No Verification einfach, dass alles gebucht sei.

„ORD nach SFO nächsten Dienstag, eine Nacht downtown, Unternehmens-Policy.“ Die Zustandsmaschine führt jeden Knoten aus, bestätigt das Hyatt Regency SF gegen das CRS anhand von property_id, und der Suchmesser bleibt bei $3.25 auf einer gecachten Suche. Endzustand: confirmed, mit einem PNR.

Das Verifikationstor lehnt ein Hotel ab, das nicht existiert

Der CRS-Verifikationsschritt als fehlgeschlagen markiert. Das Detailpanel liest, dass Tabacon Springs Eco-Lodge nicht im CRS ist und abgelehnt, nicht angezeigt wurde. Die Unterkunftskarte ist mit REFUSED gestempelt, mit dem Hinweis, dass das Verifikationstor sie abgelehnt hat und sie dem Reisenden nicht angezeigt wurde.

Die Anfrage nannte eine erfundene Unterkunft, „Tabacon Springs Eco-Lodge“, einen Namen, der zwei echte Resorts vermischt und absichtlich keine property_id hat. Das Tor findet keine CRS-Übereinstimmung und weigert sich, sie anzuzeigen. Der Agent enthält sich ehrlich, „Ich konnte diese Unterkunft nicht bestätigen,“ statt eine zu erfinden.

Das Saga-Rollback, versus das LLM in der Kontrolle

Die Pipeline-Spur, nachdem ein Hotelpreis nach der Ticketausstellung abgelaufen ist. Drei Saga-Kompensationsschritte laufen rückwärts, und ein Banner liest, dass der Hold vor dem Commit abgelaufen ist und das Saga-Rollback in umgekehrter Reihenfolge kompensiert. Die Ergebniskarte liest ROLLED BACK, TRAVELER SAFE, mit dem Hinweis, dass das Flugticket kostenlos voidet wurde und alternative Hotels angeboten werden.

Der Hotelpreis läuft ab, nachdem der Flug bereits geticktet ist. Auf unserer Seite feuert die Saga: das Ticket innerhalb des 24-Stunden-Fensters voiden, die Holds freigeben und ehrlich antworten, dass das Ticket kostenlos voidet wurde, mit beigefügten Alternativen. Endzustand: rolled back, Reisender sicher. Die Baseline läßt im selben Szenario das Ticket ausgestellt, bietet keine Kompensation und gibt ein falsches „Alles erledigt.“ aus — genau der Air-Canada-Präzedenzfall, der darauf wartet zu passieren.

Ein exportierbarer Prüfpfad

Das untere Ende der Konsole mit dem Link Export Audit Trail (JSON), neben dem rolled-back-Ergebnis, das erklärt, dass der gehaltene Tarif vor dem Commit ablief, das Ticket kostenlos voidet wurde und zwei alternative Hotels angeboten werden, bei GDS-Suchkosten von $3.25.

Ein Klick exportiert audit-<pnr>.json: Modell und Version, die typisierte Reiseanfrage, jeden Knoten und sein deterministisches Verdikt, jede Saga-Kompensation, das EU AI Act Article 50-Offenlegungsflag (Transparenzpflichten gelten ab dem 2. August 2026) und den Endzustand.

Der 200-Szenarien-Benchmark

Die Benchmark-Anzeigetafel über 200 synthetische Buchungen bei festem Seed mit identisch injizierten Fehlern. Vier Kacheln vergleichen den deterministischen Agenten mit einer reinen LLM-Baseline: 100 Prozent versus 65 Prozent konsistenter Endzustand, 0 versus 40 gestrandete Reisende, 0 versus 30 erfundene Buchungen und $3.25 versus $7.57 durchschnittliche GDS-Kosten. Eine Ergebnistabelle listet die Outcomes pro Szenario, darunter confirmed, rolled back, abstained, escalated, integrity breach und stranded.

Dieselben 200 synthetischen Buchungen, ein fester Seed (42) und dieselben injizierten Infrastrukturfehler laufen durch beide Architekturen. Die Szenariomischung ist 50 Prozent happy, 20 Prozent hotel-fail-after-ticket, 15 Prozent hallucinated-entity und 15 Prozent search-storm. Unsere Garantien gelten konstruktionsbedingt; die Ausfälle der Baseline entstehen aus denselben Daten.

Deterministischer Kontrollfluss versus ein LLM in der Schleife

Die Baseline ist ein echter ReAct-Stil-LLM-in-control-Agent auf denselben Szenarien, ein ehrlicher Anker statt eines Strohmanns. Die Zahlen unten stammen aus dem synthetischen Batch mit festem Seed und 200 Szenarien (benchmark.py, seed 42, n=200).

Kennzahl Deterministischer Agent (unser) Baseline (LLM-in-control)
Konsistenter Endzustand 100.0% 65.0%
Gestrandete Reisende 0 40
Erfundene Buchungen angezeigt 0 30
Durchschn. GDS-Suchkosten pro Buchung $3.25 $7.57

Die 100 Prozent, 0 und 0 gelten konstruktionsbedingt über diesen synthetischen Batch mit festem Seed, nicht als Open-World-Produktionsgarantie. Der Claim ist eng und haltbar: eine Teilbuchung wird niemals als confirmed gezeigt, und ein Reisender wird niemals gestrandet. Die Lücke $3.25 versus $7.57 ist eine Margenzahl, die bei jeder Modellqualität gilt.

Was diese Demo nicht tut

  • Sie verbindet sich nicht mit einem Live-GDS, CRS oder NDC. GDS und CRS, IATA- und ARC-Ticketausstellung sowie PCI-Zahlung sind gestubbt und simuliert. Der Fixture-Adapter ist die V1-Integration; es gibt kein Live-Konto bei Amadeus, Sabre oder Duffel.
  • Sie stellt keine echten Tickets aus und bewegt kein echtes Geld, und Veriprajna ist nicht IATA- oder ARC-akkreditiert. Tickets und Zahlung sind Stubs.
  • Die Szenarien, PNRs, Hotels und Reisenden sind synthetisch. „Tabacon Springs Eco-Lodge“ ist eine bewusst erfundene Unterkunft, eine Demonstration des Ausfallmodus. Real benannte Hotels wie Hyatt Regency SF sind Fixture-Inventar, keine echten Buchungen.
  • Sie behauptet nicht, mehr, günstiger oder smarter zu buchen als ein GDS oder OTA, und sie behauptet nicht null Halluzination vom Modell. Das LLM entwirft weiterhin die Absicht; die Garantie ist, dass das Tor unbestätigtes Inventar ablehnt und die Saga Teilausfälle aufräumt.
  • Die Engine ist eine handgebaute Python-Zustandsmaschine, nicht LangGraph. LangGraph ist als aufgeschobener Produktionstausch benannt. LLM-Blattaufrufe nutzen Pydantic AI.

Fragen, die Käufer stellen

Kann ich einem KI-Agenten vertrauen, Reisen zu buchen, ohne meine Reisenden stranden zu lassen?

Die Garantie kommt nicht daher, dem Modell zu vertrauen. In dieser Demo ist der Kontrollfluss deterministisches Python, und jeder Vorwärtsschritt registriert in dem Moment, in dem er läuft, eine Kompensationsaktion. Wenn ein Schritt fehlschlägt, nachdem ein Ticket ausgestellt wurde, führt die Engine diese Kompensationen in umgekehrter Reihenfolge aus (eine Saga), voidet das Ticket innerhalb des 24-Stunden-Fensters und berichtet ehrlich. Ein Reisender bleibt nie mit einem Flug und ohne Zimmer zurück, weil nichts davon abhängt, dass das Modell beschließt aufzuräumen.

Verbindet das mit Amadeus, Sabre oder Duffel?

Nein. GDS, CRS, Ticketausstellung und Zahlung sind in dieser Demo sämtlich gestubbt und simuliert. Der Fixture-Adapter ist die V1-Integration, und dahinter steht kein Live-Konto bei Amadeus, Sabre oder Duffel. Die Demo belegt die Kontrollfluss-Architektur und die Kompensationslogik, keine produktive Buchungspipeline.

Was passiert, wenn das Hotel fehlschlägt, nachdem der Flug bereits geticktet ist?

Genau dafür ist die Saga gebaut. Die Ticketausstellung registriert im Moment der Ausführung ihre eigene Umkehraktion (das Ticket innerhalb des 24-Stunden-Fensters voiden). Wenn der Hotelpreis vor dem Commit abläuft, feuert die Engine die Kompensationen in umgekehrter Reihenfolge, voidet das Ticket kostenlos, gibt die Holds frei und übergibt dem Reisenden ehrliche Alternativen. Der Endzustand ist rolled back, nicht confirmed und nicht stranded.

Was hindert den Agenten daran, ein Hotel zu erfinden, das nicht existiert?

Ein Verifikationstor bestätigt jede Unterkunft gegen das CRS anhand ihrer property_id, bevor sie gezeigt werden kann. Als die Anfrage in unserer Demo eine erfundene Unterkunft nannte, fand das Tor keine CRS-Übereinstimmung und weigerte sich, sie anzuzeigen, und der Agent enthielt sich ehrlich, statt sie zu buchen. Das Tor markiert ein erfundenes Hotel nicht nachträglich; es macht es physisch nicht präsentierbar.

Wie unterscheidet sich das davon, GPT-4 in eine Agentenschleife mit Tools zu setzen?

Ein ReAct-Stil-Agent gibt dem LLM die Kontrolle über die Transaktion, sodass es entscheidet, wann gesucht, gebucht und geticktet wird, und es hat kein Tor und keine Kompensationslogik. Auf demselben synthetischen Batch mit festem Seed und 200 Szenarien hat diese Baseline erfundenes Inventar angezeigt und Tickets ohne Rollback ausgestellt gelassen und ein falsches „Alles erledigt“ ausgegeben. Hier ist das LLM ein typisierter Blattknoten, der nur Absicht parst und die Antwort formuliert; deterministischer Code besitzt den Fluss, und jeder Schritt trägt sein eigenes Undo.

Wer haftet, wenn der Agent einem Reisenden etwas Falsches sagt?

Der Deployer besitzt jede Aussage, die sein Agent macht. In Moffatt v. Air Canada (BC Civil Resolution Tribunal, 14. Februar 2024) wurde die Airline zur Zahlung von $812.02 verurteilt, nachdem ihr Chatbot eine Trauerfalltarif-Richtlinie erfunden hatte, und die Es-war-die-KI-Verteidigung wurde zurückgewiesen. Die Demo exportiert einen JSON-Prüfpfad pro Buchung mit Modell und Version, jedem Knoten-Verdikt, jeder Saga-Kompensation und einem EU AI Act Article 50-Offenlegungsflag, sodass nachvollziehbar ist, was der Agent getan hat.

Technische Forschung

Die Forschung hinter dieser Demo — die Architektur, das Verifikationsdesign und der Enterprise-Blueprint.

Bewerten Sie eine agentische Buchungsschicht, auf die Sie das Unternehmen nicht setzen können?

Die Ausfälle, die Reisende stranden lassen und Hotels erfinden, sind Infrastrukturereignisse, keine Probleme der Modell-IQ.

Wenn Ihr Team abwägt, wo das LLM in einem hochriskanten Buchungsagenten hingehört und wie ein Teilausfall nicht zur Haftung im Stil von Air Canada wird, würden wir gerne Notizen vergleichen. Das Problem ist branchenweit, und die Antworten werden es auch sein.

Agent-Architektur-Review

  • ✓ Abbilden, wo das LLM in Ihrem Kontrollfluss heute sitzt
  • ✓ Die Schritte identifizieren, die eine Kompensationsaktion brauchen
  • ✓ Die Ausfallmodi unter Druck setzen: Tarifablauf, Holds nach dem Ticket, Suchstürme
  • ✓ Die Endzustände definieren, denen ein Operator vertrauen kann

Build eines deterministischen Agenten

  • ✓ Eine Zustandsmaschine, die Suche, Policy und Ticketausstellung besitzt
  • ✓ Ein Verifikationstor und eine Saga-Kompensationsengine
  • ✓ Policy in Code kompiliert, mit fail-safe Defaults
  • ✓ Einen exportierbaren Prüfpfad mit einem Article 50-Offenlegungsflag
Social

Auch veröffentlicht auf