---
title: "Agentic Travel Reference Architecture"
description: "AI agent → search → offer → reprice → confirmation → payment → booking → servicing akışını travel-specific authorization, idempotency ve audit sınırlarıyla tasarlayın."
slug: "agentic-travel-reference-architecture"
translationKey: "architecture-agentic-travel-reference"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["agentic-travel","ai-agent","booking","payment","servicing","architecture"]
publishedAt: "2026-09-27"
updatedAt: "2026-09-27"
reviewedAt: "2026-09-27"
technicalVerifiedAt: "2026-09-27"
codeExampleStatus: "illustrative"
sources:
  - title: "OpenAI — Agentic Commerce Protocol"
    url: "https://developers.openai.com/commerce"
  - title: "Universal Commerce Protocol"
    url: "https://ucp.dev/"
  - title: "Agent Payments Protocol"
    url: "https://github.com/google-agentic-commerce/AP2"
  - title: "Agent2Agent Protocol"
    url: "https://a2a-protocol.org/"
  - title: "Machine Payments Protocol"
    url: "https://mpp.dev/"
  - title: "x402"
    url: "https://x402.org/"
---

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

```mermaid
%% title: Agentic travel transaction flow
%% description: AI agent user intent'i search, offer, reprice, user confirmation, payment, booking ve servicing akışına dönüştürür.
flowchart LR
  A[User Intent] --> B[Agent Planner]
  B --> C[Travel Search Tools]
  C --> D[Canonical Offers]
  D --> E[Agent Selection Proposal]
  E --> F[Reprice / Availability]
  F --> G[Authorization / Confirmation Gate]
  G --> H[Payment Capability]
  H --> I[Booking Orchestrator]
  I --> J[Travel Provider]
  J --> K[Booking / Order State]
  K --> L[Servicing Tools]
  K --> M[Audit / Trace / Mandate Evidence]
```

## 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:

```text
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:

```text
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.

```text
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.