We built an AI-powered travel interface from scratch. Not a chatbot. Not a widget. Not a GPT-wrapper with a smiley face bolted onto a website. A full conversational interface with its own vector database, its own retrieval pipeline, its own memory system, and real-time streaming over WebSockets. Not to replace anything. To test whether conversational AI is actually ready to be a meaningful channel for travel. Here's what we found, what it took, and why we think most of what's out there right now is noise.
This is a two-part story. This first part covers the why: what problem we're solving, what we learned from failing at this before, and why a plugin will never get you here. Part 2 goes deeper on the architecture: the RAG pipeline, the memory system, the UI/UX decisions, and the technical tradeoffs we made.
What are you actually trying to solve?
That's the question I keep coming back to. Every time I see a company announce their new "AI-powered" feature. Every time someone asks me what we're doing with AI. Every time a vendor pitches yet another plugin.
It's the most important question in tech right now. And almost nobody is asking it.
Instead, the entire industry is working backwards: starting with "we need to do something with AI" and then looking for a place to put it. Companies hear "AI" and they hear "innovation" and they think they're falling behind if they don't do something right now.
The pressure to "do something with AI" has become louder than the question of what are you trying to achieve.
And so what happens? Companies reach for the most visible, most marketable application they can find: a chatbot. Slap it on the website. Give it a name and a friendly face. Connect it to a knowledge base. Done. "We do AI now."
Here's the problem: the integration is always limited. Some connect to a product database. Some pull live availability. But as a plugin, there's a ceiling to how deep that integration goes. It's always working with whatever data it gets access to, in whatever format the API provides, with whatever context the vendor decided was enough. The result is an interaction that looks conversational on the surface but is fundamentally constrained in what it can actually do.
And because it's a plugin, it can never be fully seamless. It will always be a separate layer on top of your website, not part of it. A different design language. A different interaction model. A different experience. The customer feels it, even if they can't articulate it. It's the difference between a room that was designed as a whole and a room where someone placed a kiosk in the corner.
A smarter gatekeeper is still a gatekeeper. Your customers wanted a door.
We've been down this road ourselves. Back in 2019, we built the first version of Joy on Flow.ai. An intent-based chatbot that could understand natural language, extract travel preferences from a single sentence, and generate leads for our specialists. It worked. Technically. But customer engagement was too low to justify keeping it alive. We retired Joy in early 2022.
The lesson wasn't that the technology was bad. The lesson was that people have learned to distrust chatbots. And rightfully so. For years, companies have used chatbots as a barrier to contact, even when they claim otherwise. Customers know this. They've experienced it. After three wrong answers, you don't think "let me try again." You think "how do I get to a real person?" Some people don't even bother engaging. They see a chat bubble with a face and their immediate reaction is to close it. Not because they're impatient, but because experience taught them it's a waste of time.
That's not a technology problem. That's a trust problem. And it's one you can't solve by making the same format smarter.
On top of that, the interface of a chatbot plugin is simply limiting. A small window in the corner of your screen. A few lines of text. Maybe a button or two. You can't show rich product cards in that. You can't display a map of a trip. You can't let someone browse, compare, save trips for later. The format dictates the experience, and the format is a box.
That experience is exactly why we didn't build another chatbot. Not a smarter one. Not a better one. Something fundamentally different. A full conversational interface, built from scratch, designed to inspire. Where someone can explore destinations, discover trips they didn't know existed, and when they're ready, transition into contact with a specialist after a conversation that actually felt good. Not after three failed attempts to get past a gatekeeper.
The real question was never "how do we add AI to our website?" The real question is: where does AI genuinely create value that wasn't possible before? That's what we set out to test.
Why I built what I built
I didn't build this because I think websites are dead or because I wanted to say we "do something with AI." I've written before about how much I despise that mentality.
I built this because of a question I've been testing for over a year now: is conversational AI truly ready to be a real channel?
In my Web 4.0 post, I wrote about the autonomous web, a world where AI assistants don't just retrieve information but act as independent digital consumers on behalf of their humans. Where Lisa tells her AI assistant "find me a two-week trip to Thailand" and the AI contacts travel companies through MCP-enabled interfaces, negotiates, refines, and presents options. Without Lisa ever opening a browser.
That might sound like removing humans from the equation. It's not. The technology enables full autonomy. But that doesn't mean we want to remove the human. It means the customer gets to choose. And our default will always be: lead to a person. More on that later.
That future is coming. Maybe not tomorrow, but it's coming. And if you're a travel company that takes itself seriously, you'd better be ready for it.
So I built Joy, an AI travel assistant for 333travel, not as a product launch, not as a marketing play, but as a serious test. Can we build a conversational interface that actually adds value? That understands our products? That doesn't hallucinate as much? That creates a genuinely useful experience as an additional channel next to our website, phone, and email?
I didn't build this to replace our website. I built this to answer a question: can a conversation be a meaningful channel for personalized travel?
What this actually is
Let me be specific about what Joy does:
Joy sits on top of our entire product database. Every roundtrip, every hotel, every excursion, every destination, all embedded as vectors in a dedicated database. When a customer says "I want something adventurous in Southeast Asia, around two weeks, not too touristy," Joy doesn't keyword-match against a PDF. She searches semantically across hundreds of products, reranks results based on actual relevance, and responds with options that genuinely fit the intent.
And she remembers the conversation. Not just the last message, the whole thread. She knows what trips were discussed, what was saved, what was dismissed. When you say "that trip you mentioned earlier with the cooking class," she understands what you mean even if she originally called it a "culinary experience."
But here's the key difference with any chatbot out there: she doesn't just know travel in general. She knows our travel. Our specific products. Our specific itineraries. Our destinations that our team personally visited. That's not something you can easily bolt on with a plugin, no matter how smart the LLM behind it is.
And the moment you want human contact? Joy hands the full context to a real travel specialist who knows exactly what you've been exploring. No "please describe your inquiry again." No cold transfer. Full continuity.
Joy doesn't replace conversations with specialists. She makes them better.
What she doesn't do (yet): she doesn't handle customer service queries, airline information, or post-booking support. This is purely a product discovery and inspiration channel. We'll get there. But we're not going to pretend she does things she doesn't. And honestly, when someone reaches out to customer service, there's already a problem. That's the worst possible moment to put a machine between you and your customer. That's when you show up. Personally. So we are still debating about what we want her to do there. The nuance is always in the details.
Why you can't get here with a plugin
You cannot achieve what we built by installing a plugin. Not with ChatGPT. Not with any off-the-shelf "AI widget." Not with any SaaS tool that promises to "make your website smarter in minutes."
And it's not because the AI models aren't good enough. The models are fine. The problem is everything around them.
The entire system depends on data that we own, structure, and control. Every trip in our database has been visited by our own team. Every itinerary is our own creation. Every piece of destination knowledge lives in our own systems. This isn't data we license from a third party or pull from a brochure catalog.
That means we can embed it. We can structure it exactly how we need it for semantic search. We can update it the moment something changes. We control the full pipeline from raw product data to vector embedding to retrieval to response.
You can't build a smart interface on top of piles of dumb data.
If your product data lives in someone else's system, if you're reselling trips from a catalog, if your "database" is a collection of PDFs from tour operators, you're at the mercy of whatever structure someone else decided on. You can't build intelligence on top of data you don't understand or control.
And many companies aren't just starting from zero, they're starting from a deficit. Their existing systems are already inadequate. The booking engine is outdated. The product data is scattered across spreadsheets and PDFs. The customer journey has gaps everywhere. And instead of fixing those fundamentals, they think it is smart to layer an AI chatbot on top of it. As if intelligence on top of dysfunction creates something functional. It doesn't. It just makes the dysfunction harder to diagnose.
You're not solving a problem. You're decorating one.
Building what we built required three things:
Owning our data. Every trip is ours. Visited by our team. Structured in our database. Embedded in our vector store. You can't build semantic search over data you don't structure yourself.
Owning our systems. Our own backend, frontend, deployment pipeline. When we needed a dual reranker, we built it. When we needed semantic conversation memory, we built it. When we needed an MCP server for Web 4.0 readiness, we built it. No vendor approval needed. No feature requests. No roadmap dependencies.
Owning the entire chain. From the moment a customer opens the chat to the moment they're talking to a specialist, every step is ours. The AI knows our products because we made the products. The specialist knows the conversation because our system feeds it to them.
The AI is the last 10% of the work. The first 90% is building a company that can support it.
In Part 2, I'll show you how it is actually running under the hood. The architecture, the search pipeline, the memory system that took many attempts to get right, and why 25 seconds of waiting can feel like 5 when you design it right.
Remco Loup.
