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.
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.
5DecisionBranches at the confidence threshold
High confidence
Goes to the travel team to release.
Low confidence
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 required8 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 boundaryAgent 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 tripIllustrative example
Trip
Suggested line
Entry route
Source of record
Confidence
Attribution
Short-haul city break
Two nights in the old town, with a museum route on the second morning
Air, single entry
Issuing authority page
91%
Assistant, not an agent
As receivedTaken from published content and the issuing authority's own page — nothing on this side is written by the assistant.
Sources usedIssuing authority pageOperator's own contentPublished guide entry
Why this wordingIt suggests and cites; it does not tell the traveller they may enter.
ActionReleaseEditSend to destination desk
What the score decidesBelow the configured threshold the plan picks up a destination-desk read before.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every planFrom published sources
03Planning
Plan from the sources
Draw on published destination content, the operator's own material and the body that issues each requirement.
01Approved path
Suggest it, verify it elsewhere
Routine days, routes and options arrive already drafted and already carrying their sources.
02Human review
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.
04Build 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.
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 aggregateIllustrative 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 threshold2 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 stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Travel-team edit rate rises in a plan slice.
02Diagnose
No rule is touched before the sources behind those plans are read, and the retrieval trail with them, until the cause narrows to one.
03Improve
Version-stamp the change and attach the plans that exposed it.
04Verify
The affected cases run again, and a fail stops the release.
05Learn
It becomes a standing test, and the sourcing rules change with it.
Learn → DetectThe 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.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Planning workflow discovery and boundary definition.
02Destination and content source assessment.
03Sourcing, citation and issuing-authority rule mapping.
04Trip-request ingestion and normalisation.
05Planning logic and source binding.
06Confidence scoring and assertion routing.
07Travel-team release workflow.
08Content and booking-tool integration.
09Entry-requirement regression cases.
10Guardrails and sourcing controls.
11Plan-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal 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 tierPilotOne market, one teamProductionProduction content systemsAdvancedMultiple 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 priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from buildBuild 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 bringWe build with it
01Your destination content and its sources→Trip-request ingestion and source mappingWeek 1
02Plans you have already sent out→Planning baseline, style extraction and source bindingWeek 2
03Your sourcing rules and who releases a plan→Sourcing, citation and issuing-authority rule mappingWeek 1
04Access to relevant APIs, feeds or exports→Content, booking-tool and agency assessment, then integration setupWeek 2
05Plans you would not want travelled on→Entry cases and the evaluation suiteWeek 4
06What a plan may never assert on its own→Confidence scoring, assertion routing, guardrails and release controlsWeek 3
07Named travel-team reviewers to release plans→Release workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, 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.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Planning workflow discovery, sourcing mapping and the automation boundaryW2Content integration and the planning baselineW3Planning workflow, confidence logic and release controlsW4Entry-requirement cases, sourcing guardrails and failure-mode testingW5Booking-tool integration, pilot trips and targeted correctionsW6One planning cycle run under the travel team, then handover
Reading the bandA bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
At the end of W6The last checks clear on live plans and monitoring moves to Agent Care.
DurationSix-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.
