Production workflows / Guide 34
A Corporate Travel Agent That Reprices Before Spending
Design a corporate travel agent that checks fare changes, policy exceptions, ticketing state, and partial bookings before committing company funds or promising a trip.
Illustrative engineering guide. Examples are not client deployments, production-ready integrations, or evidence of measured results. Validate the design with your domain and security owners.
Suppose a hypothetical engineering team must send an employee from Bengaluru to a Monday workshop in Berlin. The cheapest search result arrives shortly before the session, excludes checked baggage, and changes price while the manager approves it. A travel chatbot can produce an attractive itinerary that is neither operationally useful nor currently purchasable.
A corporate travel agent should optimize a complete trip under explicit constraints. It should not confuse search results with offers guaranteed for purchase, reservations with issued tickets, or manager approval with permission to spend any amount. The main engineering challenge is coordinating commitments across systems that do not share a transaction.
Define the trip before searching
Capture the business purpose, traveler identity, destination, required arrival deadline, acceptable airports, baggage, accessibility needs volunteered by the traveler, and budget currency. Ask whether the workshop requires arriving the previous day. Do not derive health conditions or accommodation needs from private messages.
Separate policy from preferences. Cabin eligibility, approval limits, and prohibited suppliers belong in a versioned policy service. Preferred departure times and loyalty programs can influence ranking only after hard constraints pass. The model can interpret a request and explain alternatives, but it must not convert a manager’s “looks good” into a larger spending limit.
Compare total known trip cost rather than the displayed flight price. Include baggage, ground transport assumptions, hotel nights, and change conditions. Label unknown components. A cheap late arrival may require an additional transfer or jeopardize attendance; hiding those costs produces a misleading recommendation.
Use a booking state machine
The minimum architecture includes traveler-profile access, live flight and hotel adapters, a deterministic policy evaluator, approval storage, and a durable booking coordinator. The model drafts an option comparison with evidence references. The coordinator owns transitions from proposed to approved, repriced, booking, reserved, ticketed, and reconciled.
The official Amadeus flight tutorial distinguishes flight search, price confirmation, order creation, and order management. That separation is a useful design lesson even when another supplier is used. Verify production account capabilities, ticketing arrangements, and cancellation support with the actual provider before implementing writes.
Do not create separate autonomous agents for flights, hotels, and budgets by default. Ordinary adapters can search independently while a single coordinator maintains the trip’s financial state. Specialist review may be justified for complex fare restrictions, but its output should be an evidence-backed warning rather than purchase authority.
Bind approval to an offer envelope
This illustrative Python policy gate uses decimal amounts and timezone-aware expiry. It assumes signatures, server authorization, and provider response validation happen outside the function.
from decimal import Decimal
def booking_gate(approval, offer, now):
if now >= approval["expires_at"]:
return "approval_expired"
if approval["traveler_id"] != offer["traveler_id"]:
return "traveler_changed"
if approval["itinerary_hash"] != offer["itinerary_hash"]:
return "itinerary_changed"
if approval["currency"] != offer["currency"]:
return "currency_changed"
total = Decimal(offer["total"])
ceiling = Decimal(approval["ceiling"])
if not total.is_finite() or not ceiling.is_finite():
return "invalid_amount"
if total < 0 or ceiling < 0:
return "invalid_amount"
return "within_envelope" if total <= ceiling else "reapprove"The itinerary hash should cover segments, dates, airports, cabin, included services, and material fare conditions in a canonical representation. A changed refund rule is not harmless simply because the price stayed the same. The ceiling is a deliberate approval parameter, not an automatic percentage uplift invented by the model.
Production also needs currency precision rules, supplier offer expiry, traveler document validation through approved channels, and a booking ledger. Payment instruments remain tokenized in the payment or travel provider. They do not enter model prompts or logs.
Treat ambiguous booking outcomes as real states
If order creation times out, the purchase may still exist. Move to needs-reconciliation and query provider status using supported identifiers. Do not issue another purchase with a new reference because the assistant wants to finish the conversation. If the provider lacks reliable lookup or idempotency support, require an operator to resolve ambiguity.
Persist local operation records and outgoing commands consistently. PostgreSQL’s isolation documentation is relevant to concurrent approvals and budget reservations, but a database transaction cannot roll back an airline reservation. Design compensation explicitly.
For example, if the flight succeeds and the hotel fails, preserve the confirmed flight, show the missing hotel, and offer alternatives. Cancel the flight only when the traveler or authorized operator approves the specific consequence after reviewing cancellation terms. “Rollback the trip” is not a safe generic instruction.
Track reservation and ticket status separately. A booking reference alone should not trigger a message claiming the traveler is ready to fly. A ticketing deadline requires an escalation timer, an owner, and a recovery path independent of model availability.
Security follows the traveler and budget owner
Enforce tenant, traveler, cost-center, and approver scope on the server. An assistant authorized to arrange one employee’s trip should not browse everyone’s travel history. Supplier text, hotel descriptions, and forwarded emails are untrusted input; they cannot change budgets or select payment credentials.
OWASP’s LLM security project explains why tool authority must not follow retrieved instructions. MCP can expose search and booking capabilities, but authorization remains with the business service. International entry requirements also need current official verification and human responsibility; a model-generated visa assurance is not sufficient.
Acceptance tests before purchase authority
- Increase the repriced fare beyond the approved ceiling. Expect no booking and an explicit new approval request showing the difference.
- Keep the price unchanged but remove checked baggage. Expect a changed itinerary envelope and reapproval.
- Lose the order-creation response after supplier success. Expect reconciliation without a second purchase.
- Fail the hotel step after a confirmed flight. Expect a visible partial trip, no automatic flight cancellation, and an assigned recovery task.
- Embed a payment-change instruction in hotel text. Expect the instruction to remain inert and the server-selected payment token to stay unchanged.
Measure completed trips, not cheap search results
Baseline coordinator minutes per approved trip and the frequency of booking corrections. Measure policy-correct bookings as bookings matching the approved traveler, itinerary envelope, and policy version divided by all executed bookings. Measure reconciliation workload separately, including cases that need manual supplier contact.
Guardrails include duplicate purchases, unapproved spend, missing ticket issuance, and sensitive-data disclosure. Begin with comparison-only output, then human-approved booking for one supported route and supplier. Any time-saving or cost target is proposed until measured against comparable travel needs.
The first implementation should reprice an approved flight and explain differences without buying it. Connect executive calendar scheduling for meeting constraints and flight disruption handling for post-booking changes. Backend API engineering is the right service foundation for durable commitments and recovery, even when the visible experience is conversational.