Як Omio будує conversational travel через ChatGPT і Codex

Travel discovery природно підходить conversational interface: користувач мислить не airport codes і filter forms, а обмеженнями — звідки, куди, коли, з дітьми чи багажем, швидше чи дешевше, без нічних пересадок, поїзд замість літака. Проблема починається там, де LLM намагається бути одночасно planner і system of record. Рейси, ціни, availability та fare rules змінюються швидше, ніж будь-яка пам'ять моделі.

Omio поєднує conversational layer із live transport network. Правильний production pattern: модель інтерпретує intent і constraints, але фактичні transport options приходять з authoritative search/inventory APIs. Кожна рекомендація прив'язана до freshness timestamp і provider option ID; якщо live data недоступні, система переходить у degraded planning mode й не вигадує bookable result.

Trigger — user travel request у ChatGPT/Omio surface або follow-up у вже відкритій itinerary session. Input — origin/destination, dates, traveler count, preferences, budget, accessibility/baggage constraints та, лише якщо дозволено, account context. AI stage нормалізує natural-language intent, уточнює missing constraints, формує structured search request, порівнює authoritative options і пояснює trade-offs.

Integrations: transport search/inventory, fare/terms, route metadata, account/trip context, support/disruption systems і booking/payment handoff. Output — grounded shortlist або itinerary з option IDs, current price/freshness, key terms і наступним кроком. Booking intent — окремий artifact; final transaction вимагає traveler identity, reprice/reavailability, terms confirmation і payment authorization.

• Trigger → conversational search, itinerary refinement або approved trip event.
• Input → route/date/traveler constraints + live inventory eligibility.
• AI → intent normalization, clarification, comparison, explanation.
• Integrations → live transport inventory, fares/terms, booking/support systems.
• Output → evidence-grounded options або explicit no-live-data state.

1) Parse query into structured travel constraints. 2) Validate dates, passenger count і unsupported combinations. 3) Query live provider-backed inventory. 4) Normalize heterogeneous train/bus/flight/ferry results into comparable fields. 5) Rerank by explicit user preferences; do not invent hidden priorities. 6) Present options with freshness, price, duration, transfers and material restrictions. 7) On user choice create a booking intent with exact option ID and quoted terms. 8) Reprice/recheck availability. 9) Ask explicit confirmation for materially changed price/terms. 10) Handoff to authoritative booking/payment flow and verify final booking status.

The critical design rule: conversation state can remember that the user prefers trains, but it cannot remember that a €73 fare is still available. Preferences are durable context; inventory is volatile state. Mixing them produces the familiar travel-agent hallucination: perfect itinerary to a seat that disappeared twenty minutes ago.

A3 fits the public-facing search/planning layer: agent autonomously performs multi-step clarification, live retrieval, comparison and itinerary refinement. It can prepare a booking handoff but does not inherit payment or contract authority. Explicit user confirmation is required for traveler data, fare conditions, price changes and purchase. High-risk special cases — unaccompanied minors, accessibility needs not supported by data, visa/document uncertainty, disputed cancellation/refund — escalate to authoritative provider/support guidance.

Inside engineering, Codex may reach higher task autonomy in a sandbox/branch, but merge and production authority remain human. OpenAI's Omio story explicitly says people retain responsibility and accountability even as AI becomes deeply embedded. That boundary should remain visible in system design rather than disappear behind a cheerful chat bubble.

Three data classes need different TTL: route topology may be relatively stable, schedules change more often, price/seat availability can change immediately. Every evidence object should include source/provider, fetchedAt, option/version identifier and material terms. Cache can improve latency, but booking gate always revalidates live price and availability; stale cache cannot authorize purchase.

Provider schemas differ: baggage, refundability, seat reservation, transfer guarantee, check-in and passenger categories may not map 1:1. Normalization layer must preserve unknown/unsupported fields instead of pretending semantic equivalence. If two offers cannot be safely compared, UI/agent states the gap. A lower price with missing refund terms is not automatically a better option.

Failure modes: provider timeout, partial search results, stale fare, duplicate booking submit, payment authorized but confirmation delayed, schedule change after quote, inconsistent passenger name, sold-out inventory, currency conversion drift, tool result prompt injection and connector outage. Search failure can degrade gracefully; payment/booking uncertainty requires stop-and-reconcile.

Booking attempt receives idempotency key tied to user, itinerary intent and provider request. If response times out after submit, the system queries authoritative booking/payment state before any retry. It distinguishes `NOT_STARTED`, `PENDING`, `CONFIRMED`, `FAILED`, `CANCELLED` and `UNKNOWN_REQUIRES_RECONCILIATION`. Blind retry after ambiguous payment response is not resilience; it is a surprisingly efficient way to buy two tickets.

The model never receives raw card credentials. Payment runs through a tokenized/approved payment surface outside free-form reasoning. Tool access is least-privilege: search can read inventory; booking tool requires exact option and traveler context; cancellation/refund are separate scopes with separate confirmation. User-uploaded text, provider descriptions and web content are untrusted data and cannot override system/tool policy.

PII minimization matters because itinerary history reveals location patterns. Context should include only fields required for the current task; retention/deletion and connector egress are explicit. Observability stores option IDs, latency, state transitions and policy outcomes where possible instead of full raw conversations/passenger data. High-severity privacy or duplicate-charge incident triggers capability kill switch and reconciliation runbook.

OpenAI reports Omio engineers use Codex from research/planning through coding, testing, review, monitoring and support, with custom integrations into internal systems. This can shorten development loops, but reported ~20% prior effort is not a permission to remove tests or code review. Agent-generated change must have pinned task context, isolated branch/workspace, deterministic tests, security checks, owner and rollback path.

For customer-facing travel systems, acceptance tests should cover price/fare integrity, provider adapters, currency, localization, accessibility, timeout/retry and booking reconciliation. A model upgrade that improves code generation but changes tool semantics still requires regression. Cost is measured per accepted verified change, not tokens or generated lines.

At Omio scale the expensive path is live retrieval across thousands of providers, normalization, support exceptions and transactional reliability. Full cost: model inference, search/provider API traffic, cache/index, orchestration, observability, payment/booking infrastructure, human support, fraud, QA/evals, retries and engineering maintenance. Conversational UI can reduce search friction while increasing query fan-out, so p95 provider cost and latency belong in the routing policy.

KPI: successful live-search rate, grounded-option rate, stale-price rate, reprice delta, booking-handoff completion, duplicate/unknown transaction states, support escalation, cost per verified itinerary/booking, p95 latency, provider error mix and user correction rate. Engineering side: accepted change rate, escaped defects, review time and cost per verified production change. Company-reported development effort is a reference point, not your baseline.

Eval corpus needs simple/direct, multi-city, multimodal, ambiguous date, family, baggage, accessibility, cheapest-vs-fastest, no-inventory, stale price, provider outage, conflicting fare terms, currency, schedule change, prompt injection and booking-timeout slices. Grader checks constraint extraction, retrieval coverage, ranking rationale, material-term completeness, abstention, exact tool arguments and final authoritative state.

Rollout: offline replay → search-only shadow → conversational live search → shortlist/itinerary with citations → booking intent → confirmed handoff → bounded transactional tools only after reconciliation drills. For 80/20 implementation, start with one corridor and two transport modes, not all 3 000 providers. Prove freshness, option normalization and postcondition handling first; then expand network breadth.