Case study
An intelligent travel workspace that keeps trip context and assists the traveler throughout the journey.
Travelers manage trips across fragmented systems — booking confirmations, itineraries, documents, calendars, packing lists, budgets, maps and travel applications. I identified an opportunity to build an intelligent travel workspace that maintains trip context and assists the traveler throughout the journey.
Product strategy → user experience → requirements → AI architecture → engineering prioritization → launch → GTM → analytics → iteration.
Moving beyond a standalone chatbot toward an architecture that understands context and supports multi-step workflows.
Traveler: “It looks like rain tomorrow. Reorganize my day.”
Identify destination, date, user intent and the requested change.
Pull tomorrow's itinerary, bookings, activity details and relevant traveler preferences.
Obtain relevant external information such as weather and activity data through appropriate services.
Determine which activities are weather-sensitive and identify alternatives.
Create a revised itinerary considering timing, location and existing commitments.
Present consequential itinerary changes before modifying confirmed plans.
Update approved itinerary elements, tasks or reminders through deterministic application functions.
Persist the updated trip so subsequent AI interactions use the latest information.
Not the question
“How do I add AI to a travel app?”
The real question
“Which decisions should AI make, which actions should deterministic software execute, and when should the traveler remain in control?”
I designed the experience around levels of risk.
Recommend nearby restaurants.
AI recommends autonomously.
Reorganize tomorrow's itinerary.
Generate proposed changes → request confirmation → apply changes.
Cancel a hotel or purchase a new booking.
Never execute from inferred intent → require explicit authorization.
Product principle: the higher the consequence and the lower the reversibility, the stronger the human approval requirement.
A trip planned in Claude, ChatGPT or Meta Muse lands in Gledva as a real itinerary, in one step.
People increasingly plan trips inside general-purpose assistants. Instead of competing with that chat, Gledva becomes the place the plan goes next: one tool, described so the assistant knows to call it when the user wants to save, keep or open a trip.
The server exposes a single action — save a trip and return a link. It is annotated as non-destructive, and the description tells the assistant that nothing is booked or paid. The traveller still signs in and reviews the trip in Gledva before anything becomes theirs.
A minimal, dependency-free MCP server (JSON-RPC over Streamable HTTP, three protocol versions) serves Claude and ChatGPT. A REST twin with an OpenAPI 3.1 spec serves assistants whose custom connectors only take REST, such as Meta Muse. Both feed the same save logic.
The connector doesn't build trips itself. It turns the assistant's loose input into the same shape TripHub exports use, stores a short-lived draft, and hands off to Gledva's existing import screen — so sign-in, trip creation and bookings stay in one tested path.
Travellers create personal connector keys under Profile → AI Assistants. Only a SHA-256 hash is stored, so a database leak exposes no usable key, and each assistant gets its own connector URL path, so saves are attributed to the right assistant.
api.gledva.app forwards only the MCP and connector routes to the backend, so an assistant's permission prompt names Gledva rather than an infrastructure domain — and nothing else is reachable through it.
Trade-off and lesson: the agent doesn't have to be ours. Exposing Gledva as a narrow, safe tool to the assistants people already use turns their chat into Gledva's acquisition channel — while every consequential step still happens inside Gledva, with the traveller's approval.
Shipped capabilities and designed architecture, labelled honestly.
LLMs interpret natural-language requests and reason across ambiguous travel requirements.
Traveler-specific information is retrieved from structured trip data and documents instead of relying on model knowledge.
External and deterministic capabilities are exposed as controlled tools for the AI workflow.
Structured information for destinations, dates, activities, bookings, documents, tasks, expenses, packing and reminders.
High-consequence actions require stronger controls and explicit user approval.
When reliable information cannot be retrieved, the product fails safely instead of allowing the model to fabricate an answer.
I evaluate AI experiences across the complete workflow rather than only the generated text.
| Dimension | Product question |
|---|---|
| Task success | Did the AI accomplish the user's objective? |
| Groundedness | Is the response supported by trusted information? |
| Tool accuracy | Did the agent select and call the correct tool? |
| Safety | Did it stay within permitted actions? |
| Latency | Was the experience responsive enough? |
| Cost | What did successful task completion cost? |
| User satisfaction | Did the customer find the result valuable? |
Optimization objective: Quality × Reliability × Latency × Cost
The goal isn't to use the largest or most expensive model. The goal is to select the architecture that meets the required product experience.
In practice that means Gledva runs on hosted models through an AI gateway, mostly fast Flash-class models, with heavier models reserved for the few tasks that need them. The GPU benchmark is the reference for when that should change: self-hosting an 8B model gets a voice reply started 3–5× sooner and costs about $0.08 per 1M tokens against about $2 for gpt-4.1-mini — once traffic is steady enough to keep a GPU busy.
Building an AI product isn't simply adding a chatbot. The deeper product challenge is determining where probabilistic reasoning creates value, where deterministic software should remain in control, how the system should access trusted information, and how much autonomy customers should give AI.