Agentic Travel Reference Architecture

Agentic travel mimarisinde AI agent'in yaptığı şey yalnız search çağırmak değildir. Sistem kullanıcı intent'ini güvenli şekilde search, offer, reprice, confirmation, payment, booking ve servicing lifecycle'ına bağlamalıdır.

Reference architecture

Agentic travel transaction flow

Mermaid source (.mmd)

1. Intent ile transaction'ı ayırın

Kullanıcının "gelecek hafta İstanbul'dan Roma'ya en uygun uçuşu bul" demesi search intent'tir. "Bunu satın al" demesi bile her zaman otomatik payment authorization anlamına gelmez.

Ayrı modeller:

• SearchIntent
• SelectionIntent
• PurchaseIntent
• PaymentAuthorization
• BookingIntent
• ServicingIntent

Agent bu state'leri birbirine bağlar, tek prompt string içinde eritmez.

2. Agent planning boundary

Agent planner:

• search tool seçebilir,
• provider capability keşfedebilir,
• offer karşılaştırabilir,
• reprice başlatabilir,
• kullanıcı confirmation isteyebilir.

Ancak booking/payment side-effect'leri policy gate arkasında olmalıdır.

3. Tool layer

Travel tool'ları capability bazlı expose edin:

search_hotels
search_flights
reprice_offer
create_booking
retrieve_booking
cancel_booking
quote_refund
refund_booking

Tool contract canonical domain model kullanmalı; provider DTO doğrudan agent'a açılmamalıdır.

4. Offer selection explainability

Agent neden bir offer'ı seçtiğini structured olarak saklamalı:

• user constraints,
• price,
• cancellation/refundability,
• baggage/ancillary,
• timing,
• provider confidence,
• freshness.

Bu kayıt ranking modeli değildir; audit evidence'tır.

5. Reprice zorunlu boundary

Agent search sonucundan doğrudan booking yapmamalıdır. Selected offer:

1. reprice edilir,
2. availability doğrulanır,
3. policy değişikliği varsa kullanıcıya tekrar gösterilir.

6. Confirmation / mandate gate

Side-effect öncesi sistem şu sorulara cevap vermelidir:

• kullanıcı neyi onayladı?
• hangi amount/currency?
• hangi supplier/product?
• hangi cancellation conditions?
• authorization tek işlem mi yoksa limitli delegation mı?
• expiration var mı?

Bu evidence immutable olarak saklanmalıdır.

7. Payment ve booking ayrı state machine

Agentic flow klasik travel booking kurallarını değiştirmez:

PaymentState != BookingState

Payment authorized olabilir ama booking UNKNOWN kalabilir. Agent bu divergence'ı "başarılı satın alma" diye özetlememelidir.

8. Idempotency

Agent loop veya tool retry aynı side-effect'i iki kez üretebilir. Her transaction operation için deterministic idempotency key gereklidir.

purchaseIntentId + operation + version

9. Human-in-the-loop checkpoints

Risk bazlı checkpoint örnekleri:

• fiyat değişti,
• non-refundable ürün,
• cancellation penalty yüksek,
• delegated limit aşılıyor,
• passenger/document data gerekiyor,
• booking UNKNOWN sonrası alternatif satın alma düşünülüyor.

10. Servicing agent'i

Post-booking agent:

• retrieve,
• change quote,
• cancel quote,
• refund status,
• schedule change handling yapabilir.

Mutation yine authorization ve idempotency sınırlarını kullanmalıdır.

Agent protocol boundaries

• MCP: tool/resource discovery ve invocation katmanı.
• A2A: farklı agent'lar arası coordination.
• ACP/UCP: commerce interaction/checkout capability katmanı.
• AP2: agent payment authorization/evidence yaklaşımı.
• MPP/x402: machine-native payment rails/use cases.

Bu protokoller aynı problemi çözmez; travel architecture içinde farklı katmanlara otururlar.

Failure modes

• stale offer'ı agent'in book etmesi,
• prompt retry ile duplicate booking,
• user confirmation evidence kaybı,
• delegated payment limit aşımı,
• provider tool'un fazla PII expose etmesi,
• agent "UNKNOWN" booking'i FAILED sanıp alternatif booking açması,
• servicing sırasında stale booking state kullanılması.

Observability

• agent tool-call trace,
• intent → confirmation conversion,
• reprice-change rate,
• confirmation/mandate rejection,
• booking UNKNOWN,
• duplicate-prevention hits,
• delegated-payment use,
• human-intervention rate,
• servicing success.

Production checklist

• explicit intent model,
• canonical tool contracts,
• reprice gate,
• authorization/mandate evidence,
• human-in-loop policy,
• idempotency,
• payment/booking state separation,
• PII boundary,
• end-to-end correlation,
• servicing/reconciliation tools.