Case Study
I envisioned the interaction model before the tools to build it existed. So I built the tools.
- Project
- TravelBot
- AI Travel Planning App
- My role
- Product, Design & Engineering
- Solo · End to end
- Timeline
- 2023 – 2025
- Personal project
- Stack
- Python · Next.js
- OpenAI API · Custom agent framework
01 · Why I Built This
The travel tools that exist are built for mass markets. The trips I want to take are not.
The travel I love — and that my family does — is exploratory. We go to immerse ourselves in local culture, find the unexpected, stay away from commercialized destinations. The kind of trip that requires judgment about what to include, not just the ability to sort a list by rating.
Online travel tools are built around inventory: hotels, activities, restaurants in ranked lists. That's not a design failure — it's a structural constraint. Serving mass markets requires scale, and scale requires standardized categories and filters. The result is a planning experience that consistently flattens the interesting edges off any trip.
The alternative — weeks of Reddit threads, spreadsheets, a hundred open browser tabs — wasn't better. The information existed. The joy had been completely removed from the process of assembling it.
I saw that AI could sidestep both problems: no filters needed when you can describe in natural language exactly what kind of traveler you are. And I wanted to learn what that actually meant to build — not by reading about it, but by shipping something real against the raw APIs, in the early days of the technology.
02 · The Vision
A living guide that gets more personal the longer you talk to it.
The first generation of AI travel demos all had the same shape: describe your trip, receive a wall of text, done. Take it or leave it. That's not how anyone actually plans a trip. It's an iterative process — you start with a feeling, not a destination list, and you refine through conversation, discovery, and incremental decisions over days.
I saw a different interaction model when OpenAI first shipped function calling in their API. That feature was the unlock: AI could call structured functions and update a persistent data model from natural language. Not produce text — update a living object. The guide and the chat side by side, each informing the other.
What you'd now recognize as the chat-plus-artifact pattern wasn't a known UX convention at the time. Claude Artifacts didn't exist yet. I was designing toward it before it had a name.
The design principle
The trip is the app, not the chat.
The AI assistant exists to build something — a rich, structured, visually engaging guide that the traveler owns and keeps improving. The chat is the interface. The guide is the product. Every interaction either answers a question in context or updates the guide itself, and the system decides which is appropriate.
03 · Speed as a Design Requirement
The feeling requires speed. Speed required infrastructure that didn't exist yet.
Travel planning should feel like anticipation. When you describe a trip and a beautiful guide appears — destinations, curated places, photography, maps — there's a small jolt of excitement. That feeling is the product. If it takes minutes, the feeling doesn't happen. You've built a better search engine, not a different experience.
The initial response had to arrive in seconds. A full guide, ready to explore, before your attention has moved on. The same standard applied to follow-up requests: adding a beach town, finding less crowded hikes, building a day-by-day schedule.
The architecture required is specific: a fast first-pass agent identifies destinations and interest categories, then spawns a separate agent per destination category — all running in parallel — to populate highlights immediately. By the time a user has absorbed the top-level guide, the sub-pages are already filled with curated depth. A separate agent simultaneously drafts the day-by-day itinerary from the other agents' outputs. A typical trip engages over a hundred specialized agents. The user sees none of this.
I evaluated LangGraph, AutoGen, and Crew. None satisfied the core constraint: creating agents dynamically — whose number and type aren't known until the first-pass agent returns — while running them in parallel simultaneously. You could get one or the other. I built the framework from scratch.
The constraint that drove everything
Dynamic agent creation and parallel execution — simultaneously. Every framework I found could do one. I needed both at once.
The agents that need to run depend on what the first-pass agent returns — you don't know their number or type in advance. And they all need to run concurrently. That combination is what forced the custom framework. Partial updates to the trip's structured data model — rather than regenerating the full guide on every request — kept the experience stable under the speed constraint.
04 · Design Principles
Five principles — each one an explicit choice against a simpler path.
The product goals shaped every design decision: the trip is front and center, AI is in service of it, and nothing should break the feeling of anticipation.
The trip is the product, not the chat
It would have been simpler to build a travel chatbot. Instead the primary surface is the guide: destinations, places, photography, maps, itinerary. The chat is a persistent but secondary layer — a tool for improving something, not the thing itself. The distinction changes how the product feels: you're building, not just asking.
Iterative, not one-shot
Every AI response either answers a question in context or updates the guide. The assistant decides which is appropriate — there is no mode to switch. Ask about hiking conditions in March and you get a direct answer with sourced web results. Ask to add a beach town and your guide updates: a new destination page appears, places populate, the itinerary adjusts. The orchestration layer handles the distinction transparently, without the user having to explain what kind of response they want.
Visual richness as a product requirement
Photography, maps, and curated blog links aren't decorative. The anticipation of an upcoming trip is half the joy of traveling — the planning should ride that feeling, not drain it. Every destination and place page is built to make you want to be there. Stripping the visual layer would have produced a more technically defensible product. It would have missed the point entirely.
Partial updates, not regeneration
Adding one destination shouldn't rebuild the whole guide. The structured data model is designed for surgical modification — only affected nodes change. This keeps the experience stable and responses fast under iteration, which matters for a product built around refinement. The guide accumulates depth without starting over.
Genius simplicity on the surface
The complexity of a hundred concurrent agents, a custom orchestration framework, and real-time structured data updates is entirely invisible. The UI has three tabs — Explore, Plan, Book — and a persistent chat bar at the bottom. No matter how complex the trip the user is building, the interface never gets more complicated than that.
05 · The Product
From a single thought to a day-by-day itinerary.
The full user journey runs from a natural language description through a rich, multi-destination guide to a fully planned itinerary — with the AI assistant available at every step to refine, expand, or answer questions about the trip.
Explore and curate
Travelers heart places as they explore the guide. Those favorites get priority when the itinerary is generated — the system knows what matters before you have to explain it again. A map is available from any screen, showing the locations of all places in the current context, instantly.
Day-by-day planning
Tell the assistant how many days your trip is, or ask it to plan directly. The itinerary is generated from the guide's curated places, with named days, times, and durations assigned. Travelers can keep refining via chat — or manipulate the itinerary directly: add activities, remove them, reorder by drag and drop, adjust timing. Favorited places get priority; the rest of the schedule fills in around them.
06 · Reflection
What I'd do differently — and what this project was really for.
When I built the multi-agent framework, I designed it as a generalized, reusable system — an abstract graph of nodes, edges, and branching forks I could drop into any future project. The logic felt sound: invest in the infrastructure once, carry the benefits forward.
In retrospect, it wasn't worth it for this project. The abstraction added enough complexity that the framework itself became a drag on iteration. And more fundamentally: AI moves faster than any framework designed to abstract it. The models available today — Claude 4.5, GPT-5 — have the capacity to spawn and coordinate sub-agents in ways I genuinely couldn't have imagined when I was designing those directed graphs. The structural choices I locked into are already partially obsolete.
What I'd do differently: bake the multi-agent system into the application code directly. Not because good architecture doesn't matter, but because in a field moving this fast, the flexibility to rethink structural decisions is worth more than the elegance of a generalized abstraction. Keep the options open.
What this project was really for
In the early days of a fundamental technology shift, there is no substitute for building close to the API.
You cannot fully understand what function calling unlocks by reading about it. You cannot know what multi-agent orchestration really means until you've built one that breaks under real conditions and had to fix it. TravelBot was built to scratch a personal itch — and to develop the kind of first-principles AI product intuition that only comes from shipping something real, close to raw infrastructure, when none of the patterns had names yet.
More case studies: XOIP AI Voice Agent & Cerbex Hotel Marketplace