Jinko

Initiate booking for a trip. Quotes the trip and returns a Stripe Checkout URL for payment. Mutually exclusive with `status` — provide exactly one action per call.

Idempotency key to prevent duplicate processing

Check the status of an existing booking. If payment is authorized, triggers fulfillment automatically. Mutually exclusive with `create` — provide exactly one action per call.

A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, john@example.com, and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]"

REQUIRED. Array of origin IATA codes (3-letter uppercase), representing either airports or cities where the trip starts. The LLM MUST detect and include all relevant nearby airports or city codes based on the user’s location. Examples: ["JFK", "LGA", "EWR"] for New York City; ["SFO", "OAK", "SJC"] for the San Francisco Bay Area; ["ORD", "MDW"] for Chicago; or a single city code like ["NYC"].

REQUIRED. Type of trip: "oneway" for single-leg flights, or "roundtrip" for return flights.

Preferred cabin class. Options: "economy", "premium_economy", "business", or "first". Filters results accordingly.

ISO 4217 currency code for displaying prices (e.g. "EUR", "USD", "GBP"). Infer from the user's country or locale. If the user mentions a specific currency, use that.

List of departure date ranges for flexible travel discovery. Use when the user mentions periods like “next month” or “spring.” Supports multiple non-contiguous ranges (OR logic). Example: [{start: "2025-12-10", end: "2025-12-15"}, {start: "2025-12-20", end: "2025-12-25"}].

List of specific departure dates in ISO 8601 format (YYYY-MM-DD). Use for searching multiple specific dates with OR logic. Example: ["2025-12-15", "2025-12-16", "2025-12-17"] for flexible date searches. Useful when user wants to check specific dates like weekends.

OPTIONAL. Array of destination IATA codes (3-letter uppercase), representing either airports or cities. When a city code is provided, the LLM MUST expand it to include all associated airports. Examples: ["LHR", "LGW", "STN", "LTN", "LCY"] for London airports; ["CDG", "ORY"] for Paris; ["TYO"] for all Tokyo airports. You may mix airport and city codes: ["JFK", "LAX", "LON", "PAR"]. When omitted or empty, the system searches globally to discover the best flight deals (destination discovery mode).

When true, only returns nonstop (direct) flights. Useful for avoiding layovers or minimizing total travel time.

User's BCP 47 locale inferred from the conversation (e.g. "fr-FR", "en-US", "ja-JP"). Used for formatting dates, numbers, and selecting currency. Infer from the user's language and location context.

Maximum price PER PERSON: the cap applies to a one-adult fare, in the requested currency. For a whole-party budget, divide it by the number of ADULTS only and treat the result as a loose pre-filter: children and lap infants usually cost less than an adult, so dividing by every traveller would exclude affordable trips. Send a per-person budget as-is. The exact whole-trip budget check is flight_search with max_price.

List of return date ranges for flexible round-trip searches. Supports multiple return windows. Example: [{start: "2025-12-22", end: "2025-12-25"}, {start: "2025-12-29", end: "2026-01-02"}].

List of specific return dates for round-trip searches (YYYY-MM-DD). Must be after the corresponding departure dates. Supports multiple options (OR logic). Example: ["2025-12-22", "2025-12-23", "2025-12-24"].

Sorting preference for search results. Options: "lowest" (cheapest first, default) or "recommendation" (best overall balance of price, duration, and stops).

Exact number of days to stay at the destination. Used with a departure date to automatically compute the return date. Example: 7 = one-week trip; 3 = weekend getaway.

Range of acceptable trip durations for flexible planning (e.g., “5 to 10 days”). Cannot be combined with stay_days or explicit return_date. Example: {min: 5, max: 10}.

A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, john@example.com, and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]"

The original natural-language user query that triggered this tool call. Used for context.

REQUIRED: Single origin airport IATA code or IATA City Code. Example for IATA airport code : "LGW" for Gatwick in London, "SFO" for San Francisco. Example for IATA city code : "LHR" for London, "BJS" for Beijing.

REQUIRED: Single origin airport IATA code or IATA City Code. Example for IATA airport code : "JFK" for John F.Kennedy in New York, "LAX" for Los Angeles. Example for IATA city code : "NYC" for New York, "PAR" for Paris.

REQUIRED: Trip type: "oneway" for one-way flights or "roundtrip" for round-trip flights.

Cabin class preference. Options: "economy" (standard economy), "premium_economy" (enhanced economy with more space/amenities), "business" (business class), "first" (first class). When specified, only shows flights in the requested cabin class.

ISO 4217 currency code for prices (USD, EUR, GBP, JPY, CAD, AUD, etc.). Default: USD. Use currency matching the user's location or preference.

List of departure date ranges for flexible travel exploration. Use when user says "next month", "spring", or wants to discover deals across multiple date periods with OR logic. Example: [{start: "2025-12-10", end: "2025-12-15"}, {start: "2025-12-20", end: "2025-12-25"}] for non-contiguous periods.

List of specific departure dates in ISO 8601 format (YYYY-MM-DD). Use for searching multiple specific dates with OR logic. Example: ["2025-12-15", "2025-12-16", "2025-12-17"] for flexible date searches. Useful when user wants to check specific dates like weekends.

Only show direct/nonstop flights. When true, only flights with no stops are returned. Use for fastest travel or when layovers are not desired.

Locale code for results formatting (e.g., "en-US", "es-ES", "fr-FR", "de-DE", "ja-JP"). Default: en-US. Affects date/time formatting and localized content.

Maximum total price per person in specified currency. Helps find flights within budget. Example: 500 means flights up to $500/€500/£500 per person depending on currency.

List of return date ranges for flexible round-trip exploration. Use when user wants flexibility on return timing across multiple periods with OR logic. Example: [{start: "2025-12-22", end: "2025-12-25"}, {start: "2025-12-29", end: "2026-01-02"}]

List of specific return dates for round-trip flights (YYYY-MM-DD). Use for searching multiple return date options with OR logic. Must be after departure dates. Example: ["2025-12-22", "2025-12-23", "2025-12-24"]

Sort results by this criteria. Default: lowest (best deals first). Options: lowest (cheapest flights), recommendation (best overall value considering price, duration, and stops).

Exact number of days to stay at destination. Used with departure_date to calculate return date automatically. Example: 7 for a week-long trip, 3 for a weekend getaway.

Flexible stay duration range. Use when user wants flexibility in trip length (e.g., "5 to 10 days"). Cannot be combined with exact stay_days or return_date. Example: {min: 5, max: 10}

The original natural-language user query that triggered this tool call. Used for context.

REQUIRED: Single origin airport IATA code or IATA City Code. Example for IATA airport code : "LGW" for Gatwick in London, "SFO" for San Francisco. Example for IATA city code : "LHR" for London, "BJS" for Beijing.

REQUIRED: Single origin airport IATA code or IATA City Code. Example for IATA airport code : "JFK" for John F.Kennedy in New York, "LAX" for Los Angeles. Example for IATA city code : "NYC" for New York, "PAR" for Paris.

REQUIRED: Trip type: "oneway" for one-way flights or "roundtrip" for round-trip flights.

Filter the OUTBOUND leg by local arrival time-of-day. Example: { "latest": "20:00" } to arrive by 8pm. Use when the user says "arrive before dinner", "land by noon", etc.

Cabin class preference. Options: "economy" (standard economy), "premium_economy" (enhanced economy with more space/amenities), "business" (business class), "first" (first class). When specified, only shows flights in the requested cabin class.

ISO 4217 currency code for displaying prices (e.g. "EUR", "USD", "GBP"). Infer from the user's country or locale. If the user mentions a specific currency, use that.

List of departure date ranges for flexible travel exploration. Use when user says "next month", "spring", or wants to discover deals across multiple date periods with OR logic. Example: [{start: "2025-12-10", end: "2025-12-15"}, {start: "2025-12-20", end: "2025-12-25"}] for non-contiguous periods.

List of specific departure dates in ISO 8601 format (YYYY-MM-DD). Use for searching multiple specific dates with OR logic. Example: ["2025-12-15", "2025-12-16", "2025-12-17"] for flexible date searches. Useful when user wants to check specific dates like weekends.

Filter the OUTBOUND leg by local departure time-of-day. Example: { "earliest": "08:00", "latest": "12:00" } for a late-morning departure. Use when the user says "morning flight", "leave after 6pm", etc.

Only show direct/nonstop flights. When true, only flights with no stops are returned. Use for fastest travel or when layovers are not desired.

User's BCP 47 locale inferred from the conversation (e.g. "fr-FR", "en-US", "ja-JP"). Used for formatting dates, numbers, and selecting currency. Infer from the user's language and location context.

Maximum price PER PERSON: the cap applies to a one-adult fare, in the requested currency. For a whole-party budget, divide it by the number of ADULTS only and treat the result as a loose pre-filter: children and lap infants usually cost less than an adult, so dividing by every traveller would exclude affordable trips. Send a per-person budget as-is. The exact whole-trip budget check is flight_search with max_price.

Round-trip only. Filter the RETURN leg by local arrival time-of-day.

List of return date ranges for flexible round-trip exploration. Use when user wants flexibility on return timing across multiple periods with OR logic. Example: [{start: "2025-12-22", end: "2025-12-25"}, {start: "2025-12-29", end: "2026-01-02"}]

List of specific return dates for round-trip flights (YYYY-MM-DD). Use for searching multiple return date options with OR logic. Must be after departure dates. Example: ["2025-12-22", "2025-12-23", "2025-12-24"]

Round-trip only. Filter the RETURN leg by local departure time-of-day.

Sort results by this criteria. Default: lowest (best deals first). Options: lowest (cheapest flights), recommendation (best overall value considering price, duration, and stops).

Exact number of days to stay at destination. Used with departure_date to calculate return date automatically. Example: 7 for a week-long trip, 3 for a weekend getaway.

Flexible stay duration range. Use when user wants flexibility in trip length (e.g., "5 to 10 days"). Cannot be combined with exact stay_days or return_date. Example: {min: 5, max: 10}

A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, john@example.com, and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]"

The original natural-language user query that triggered this tool call. Used for context.

ISO 4217 currency code for displaying prices (e.g. "EUR", "USD", "GBP", "JPY"). ALWAYS set this — omitting it falls back to USD which is rarely what users actually want. Infer from the strongest signal available: (1) the user's explicit ask ("show me prices in pounds"), (2) the conversation language/locale (French → EUR, Japanese → JPY, German → EUR, Spanish/Catalan/Italian/Portuguese → EUR, English UK → GBP, English US → USD), (3) the origin city's country (CDG/ORY → EUR, LHR/LGW → GBP, NRT/HND → JPY, JFK/LAX → USD, etc.). When in doubt between two plausible currencies, prefer the one matching the user's likely home country.

User's BCP 47 locale inferred from the conversation (e.g. "fr-FR", "en-US", "ja-JP"). Used for formatting dates, numbers, and selecting currency.

Get confirmed live fares for a specific flight offer. Returns fare brands with trip_item_token for booking. ALWAYS forward any filters that were on the upstream flight_calendar / find_destination call (direct_only, cabin_class, max_price, include_carriers, exclude_carriers) — the BFF uses them to keep the reshop candidate aligned with what the user originally picked.

Live search for a single precise route + date(s) with optional filters (direct_only, cabin_class, max_price, include_carriers, exclude_carriers). Use only when the user has committed to ONE specific route and a precise departure date (and optionally a return date for roundtrip — omit return_date for one-way). No ranges, no multi-city, no date arrays. For loose/flexible queries use flight_calendar.

Traveler counts. Defaults to 1 adult.

Existing trip_id to associate this search with. Forward whenever the user is mid-trip-build (you have seen a trip_id in a recent trip(...) tool result and the user has NOT pivoted to a different trip context, e.g. a new origin city or unrelated request). Drop on pivot. Echoed back in the result so the cart widget can append the next selection to the same trip.

A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, john@example.com, and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]"

Check-in date (YYYY-MM-DD). Accepted for future cache-key alignment; currently unused by the platform.

Check-out date (YYYY-MM-DD). Accepted for future cache-key alignment; currently unused by the platform.

Legacy native hotel_id from hotel_search. Use hotel_ref when available because native IDs can overlap across providers.

Provider-qualified hotel_ref from hotel_search (preferred, e.g. "hotelbeds:12345").

A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, john@example.com, and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]"

Check-in date (YYYY-MM-DD).

Check-out date (YYYY-MM-DD).

Destination — provide exactly one shape. Two distinct modes: MODE A (rate lookup — you know which hotel): • { hotel_ids } to re-shop a known set. • { hotel_name, country_code?, city_name? } when the user named a specific property. Server resolves via fuzzy lookup; returns 422 HOTEL_NAME_LOW_CONFIDENCE if no candidate scores ≥ 0.7. MODE B (hotel search — you're exploring): • { query } for unambiguous cities/POIs only ("Paris", "Times Square"). Provider AI search returns 0 for islands/regions/countries/archipelagos. • { city_name + country_code } for ambiguous city names or when the user named a primary city ("Mahón, ES" for Menorca). • { latitude + longitude + radius_km } for islands, regions, neighborhoods — anywhere { query } returns 0. • { place_id } when you already have an upstream Place ID. In Mode A, filters (min_rating / star / facility / chain / hotel_type / max_results) are ignored — the user already named the property. Best practice: don't combine filters with hotel_ids or hotel_name.

Shorthand: total adults across all rooms. Use ONLY when there is no ambiguity (1 or 2 adults = single room). For 3+ adults, or odd splits, ask the user how they want to split rooms and pass occupancies[] instead — e.g. 4 adults → [{adults:2},{adults:2}] (double + double) vs a single 4-sleeper is a meaningfully different search. If the user does not clarify, the server defaults to 2-adults-per-room (remainder in the last room), so every 4-adult request becomes two double rooms. Do NOT combine with occupancies[] — use one or the other.

Shorthand: ages of all children across all rooms. If children are present, prefer occupancies[] so the caller controls which room each child goes in (ages affect pricing and some providers reject invalid age/room combinations).

ISO 4217 currency code (e.g. "EUR", "USD", "GBP", "JPY"). ALWAYS set this — omitting it falls back to USD which is rarely what users actually want. Infer from the strongest signal available: (1) the user's explicit ask ("show me prices in pounds"), (2) the conversation language/locale (French → EUR, Japanese → JPY, German → EUR, Spanish/Catalan/Italian/Portuguese → EUR, English UK → GBP, English US → USD), (3) the destination country (Italy/France/Germany → EUR, UK → GBP, Japan → JPY, US → USD). When in doubt between two plausible currencies, prefer the one matching the user's likely home country.

Optional filter overrides applied on top of the tenant default filter set.

Guest nationality (ISO 3166-1 alpha-2, uppercase, e.g. "FR"). Affects rate availability + tax handling at search time. Separate from traveler nationality used for booking documents.

One entry per room (structured). PREFERRED whenever the party is larger than 2 adults or has children — it removes ambiguity about how guests are split across rooms. Example: [{ "adults": 2 }, { "adults": 1, "children_ages": [5] }]. Do NOT combine with the shorthand fields (adults/children/rooms) — use one or the other.

Shorthand: number of rooms (BFF auto-distributes adults + children). Use when the user named a room count but not the per-room split.

Existing trip_id to associate this search with. Unified (cart-widget) tool only — the DevPlatform variant accepts the field for schema consistency but ignores it (no widget surface). Forward whenever the user is mid-trip-build (you have seen a trip_id in a recent trip(...) tool result and the user has NOT pivoted to a different trip context, e.g. a new origin OR destination city or unrelated request). Drop on pivot. Echoed back in the result so the cart widget can append the next selection to the same trip.

A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, john@example.com, and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]"

Add a flight or hotel to the trip. Use trip_item_token from flight_search (offer__* format) or offer_id from hotel_search (htl_* format).

Idempotency key to prevent duplicate processing

Deprecated: offer_id is now encoded into trip_item_token by flight_search. Only needed for legacy tokens without encoded offer_id.

Payment flow type: "checkout" for Stripe Checkout (default), "intent" for Payment Intent.

Remove an item from the trip by its ID.

Schedule a fresh quote on the current cart state. Triggers async re-pricing on the BFF — the response returns immediately with the new quoted_cart_id; poll trip(get) until status === "held" (quote complete). After completion, per-item available_ancillaries are populated, total_sell_at reflects the carrier-confirmed price, and select_ancillaries is unlocked. Call this AFTER any traveler/composition change so subsequent steps see fresh prices and options. book(create) will silently re-quote if the cart drifted from the last quote.

Select ancillaries (bags, seats, meals) for a quoted trip item. Uses full-replacement semantics — send all desired selections.

ID of an existing trip. If not provided, a new trip will be created.

Set travelers on the trip. Replaces all existing travelers (idempotent operation).

A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, john@example.com, and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]"