Travel & Hospitality AI agent · Itineraries
Itinerary-Planning AI Assistant
Plan the trip from published content, bind entry, visa, documentation and health requirements to the authority that issues them, and mark them for the traveller to confirm before they travel.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Never asserted
- Source-cited
- After launch
- Agent Care
What this agent does
Where a requirement lives, and who owns it
In
- 01
Where a trip starts, ingest destination content, published guides and the traveller's own dates.
- 02
When a place or a time is named, resolve it against a source that can be checked, or leave it out.
Reason
- 03
Where the trip needs shape, draft the days, the routes and the options from published content.
- 04
When an entry, visa, health or documentation point arises, cite the authority that issues it.
- 05
Where that authority cannot be reached, the plan says so rather than filling the gap itself.
Decide
- 06
When a suggestion carries a price, mark it as an enquiry, not a hold and not a ticketed booking.
- 07
Where a requirement bears on travel, route the plan to the travel team and to the traveller.
Out
- 08
When a plan is issued, retain the sources, the retrieval trail, the edits and who released it.
- 09
Where a write is allowed, it runs only inside the approval boundaries agreed at implementation.
Product statement
The assistant suggests; the travel team releases, the traveller confirms what governs entry, and the operator answers for what was said.
Example workflow
One trip, request to released plan
- 1Planning request receivedTraveller enquiry, corporate booking tool, agency intake or a stored profile
- 2Sources assembledPublished destination content, operator material and the authority issuing each requirement
- 3Plan draftedDays, routes, options, citations, confidence
- 4Controls appliedExistence checks on places and times, requirement-sourcing rules, assertion flags and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is held or ticketed at any of them — the assistant is planning, and the travel team's lane opens at the confidence gate.
Goes to the travel team to release.
Adds a destination-desk read first.
Travel team releases
The plan is held with its sources, its flagged lines and the confidence.
Release · Edit · Send to destination desk
Released — with the traveller's own checks named
- 6Planning systems updatedOnly where write access and approval policy allow it
- 7Outcome evaluatedEdit distance, flagged-line outcomes, source freshness and corrections made after a plan went out
Edits
Every travel-team edit is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Asserting an entry, visa or documentation rule.
- Booking, ticketing or holding any part of a trip.
- Taking or handling a traveller's money for a trip.
- Speaking as the carrier, the agency or a travel agent.
Automation boundary
Agent acts unaided
- ✓Draft the days, the routes and the options from published content.
- ✓Cite each requirement to the government body that issues it.
- ✓Mark what only the traveller can confirm before they travel.
- ✓Flag what a person must weigh, and hold the plan for them.
Any write happens inside the boundaries agreed at implementation, never ahead of release.
- Clearing a destination as safe for someone to visit.
- Advising on health, vaccination or medical fitness.
- Quoting a fare, a total price or a discount as final.
- Changes to sourcing, citation or release rules.
Example output
One day of a plan, annotated
Everything the assistant suggests is attached to the source it was drawn from.
Itinerary output · single trip
Illustrative example- Trip
- Short-haul city break
- Suggested line
- Two nights in the old town, with a museum route on the second morning
- Entry route
- Air, single entry
- Source of record
- Issuing authority page
- Confidence
- 91%
- Attribution
- Assistant, not an agent
As received
Taken from published content and the issuing authority's own page — nothing on this side is written by the assistant.
Sources used
- Issuing authority page
- Operator's own content
- Published guide entry
Why this wording
It suggests and cites; it does not tell the traveller they may enter.
What the score decides
Below the configured threshold the plan picks up a destination-desk read before.
Action
ReleaseEditSend to destination deskValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every plan
From published sources
Plan from the sources
Draw on published destination content, the operator's own material and the body that issues each requirement.
Suggest it, verify it elsewhere
Routine days, routes and options arrive already drafted and already carrying their sources.
Send review to what a plan asserts
A line touching entry, documentation or health is marked for a person and for the traveller's own confirmation, because that is where being wrong ends at a border.
Build an evidence trail
The suggestion, the source behind it and the traveller's own confirmation stay on the plan.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Destination content
- Amadeus
- Sabre content
- Travelport
- GDS content
Corporate booking tools
- Concur Travel
- Navan
- Egencia
- TravelPerk
Agency systems
- Mid-office platforms
- Agency CRM and profiles
Agent
Itinerary planning
- Reads the sources
- Drafts the plan
- Holds for release
Traveller messaging
- chat
- Mobile itinerary apps
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and the traveller
The layers nest. What each one misses is named in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a plan may stand
- L3
- Puts the release in a travel team's hands
- L4 – L5
- Keep the suggestion and the source behind it
- L6
- Reverts to published content when signals degrade
How Nestack evaluates it
Evaluate the planning workflow — not only the finished day plan.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the plan the traveller reads
- E1Final-output evaluationDid each place, time and requirement in the plan resolve to a source?
- E2Step-level evaluationDid the assistant read the right destination content and the right issuing body?
- E3Tool evaluationDid it read the correct source and write to the correct trip?
- E4Confidence calibrationDo low-confidence plans actually attract more travel-team edits?
- E5Slice evaluationHow does performance change across specific destination groups?
- E6Business outcomeHow many plans needed an edit or a correction after they went out?
Floor — the trip the traveller actually takes
Failure modes
Where each failure originates in the agent
Seven ways a plan goes wrong, by the stage it starts.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- BX-03
Stale requirement source
An entry rule is read from a page the authority has since changed.
Stage gathers
Destination content and issuing-authority pages
02 · Reasoning
2 modes
- BX-04
Entry requirement asserted
A plan states an entry rule as fact instead of citing it.
- BX-06
Fabricated place or time
A location, route or opening time resolves to no source.
Stage proposes
Days, routes, options and their citations
03 · Tool / write
2 modes
- BX-02
Plan released unreviewed
A plan reaches a traveller with no person behind it.
- BX-05
Crossed into selling
The assistant holds, prices or takes money for travel.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- BX-01
Spoken as the carrier
The assistant answers as though it were the airline or the agency.
Stage returns
The plan the travel team releases to a traveller
05 · Change / Version
1 mode
- BX-07
Silent sourcing regression
A model or rule change widens what a plan will assert unsourced.
Stage tracks
Model, prompt, sourcing rules and market config
- Sev-1 · an entry rule asserted
- Sev-2 · a wrong fact reaches a traveller
- Sev-3 · a source degrades, plan routes to review
Affected slices
Overall quality can hide one bad cohort
The travellers under-counted in an aggregate figure are the ones whose plan carried an entry or documentation line The cohorts that carry it are named, not averaged away..
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Entry and documentation lines | 8.0% | 3.4× | Review | |
| Destinations with changing rules | 6.8% | 2.9× | Review | |
| Places and opening times | 4.2% | 1.8× | Watch | |
| Familiar city breaks | 1.4% | 0.6× | Normal |
Bar: travel-team-edit-rate lift vs. familiar-city-break baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
The cycle ends in a test, not a note
A cycle is done when the miss has become a test the next release has to survive. That suite is what the next plan shown to a traveller is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Travel-team edit rate rises in a plan slice.
- 02
Diagnose
No rule is touched before the sources behind those plans are read, and the retrieval trail with them, until the cause narrows to one.
- 03
Improve
Version-stamp the change and attach the plans that exposed it.
- 04
Verify
The affected cases run again, and a fail stops the release.
- 05
Learn
It becomes a standing test, and the sourcing rules change with it.
Learn → Detect
The return edge. Every cycle hands the next one a longer suite to clear.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, planning workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Planning workflow discovery and boundary definition.Week 1
- 02Destination and content source assessment.Week 1, Week 2
- 03Sourcing, citation and issuing-authority rule mapping.Week 1, Week 2
- 04Trip-request ingestion and normalisation.Week 2
- 05Planning logic and source binding.Week 2, Week 3
- 06Confidence scoring and assertion routing.Week 3
- 07Travel-team release workflow.Week 3, Week 4
- 08Content and booking-tool integration.Week 5
- 09Entry-requirement regression cases.Week 4, Week 5
- 10Guardrails and sourcing controls.Week 4
- 11Plan-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
| Capability✓ in scope · — not at this tier | PilotOne market, one team | ProductionProduction content systems | AdvancedMultiple markets / brands |
|---|---|---|---|
| Introduced at Pilot | |||
| Planning from your sources | ✓ | ✓ | ✓ |
| Travel-team release | ✓ | ✓ | ✓ |
| Sourcing-accuracy baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by destination group | — | ✓ | ✓ |
| Approval workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Content-system integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-market sourcing rules | — | — | ✓ |
| Multi-stage travel approvals | — | — | ✓ |
| High planning volume | — | — | ✓ |
| Multi-market content controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
- Separate from build
- Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bring
We build with it
01Your destination content and its sources
→Trip-request ingestion and source mapping
Week 102Plans you have already sent out
→Planning baseline, style extraction and source binding
Week 203Your sourcing rules and who releases a plan
→Sourcing, citation and issuing-authority rule mapping
Week 104Access to relevant APIs, feeds or exports
→Content, booking-tool and agency assessment, then integration setup
Week 205Plans you would not want travelled on
→Entry cases and the evaluation suite
Week 406What a plan may never assert on its own
→Confidence scoring, assertion routing, guardrails and release controls
Week 307Named travel-team reviewers to release plans
→Release workflow, then pilot and production validation
Weeks 5–6
Nothing else is required
Deployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Phases are drawn over the weeks they actually occupy, which is why week 5 doubles up rather than padding.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Planning workflow discovery, sourcing mapping and the automation boundary
W2Content integration and the planning baseline
W3Planning workflow, confidence logic and release controls
W4Entry-requirement cases, sourcing guardrails and failure-mode testing
W5Booking-tool integration, pilot trips and targeted corrections
W6One planning cycle run under the travel team, then handover
- Reading the band
- A bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
- At the end of W6
- The last checks clear on live plans and monitoring moves to Agent Care.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Travel & Hospitality AI agent
Build an itinerary assistant that suggests, and never rules.
No US decision has held a company liable for what its assistant said about a trip, and the case everyone cites is a small-claims ruling from another country. What it costs to be wrong is not measured there: a traveller turned away at a border has no remedy against the assistant that told them the visa was unnecessary, and the exposure runs through apparent authority and consumer-protection law, which is broader. Show us your sources and who releases a plan.
- Typical delivery
- 4–6 weeks
- Deployment
- Your content sources
- Never asserted
- Source-cited
- After launch
- Agent Care available
Nestack Agents · Itinerary planning
AGT-TH-02 · Agent Care available after launch