Why We Built an AI Agent, Not a Chatbot

The average traveler visits many websites and burns through 45 sessions before booking a single trip. Most people accept this as normal. We think it is broken beyond repair, and we think the fix has nothing to do with building a better chatbot.

When we started building Nowah, the first architectural decision we made was also the most consequential: we would build an AI agent, not a chatbot. The distinction sounds like semantics. It is not. It is the difference between software that talks about travel and software that books travel. And the gap between those two things is enormous.

I want to walk through that gap in detail, because I think it explains why most AI travel products disappoint users and why the few that work feel qualitatively different.

The question every traveler already knows the answer to

Sixty-seven percent of travelers report feeling stressed by the booking process. Not by the travel itself. By the process of buying it. That number has barely moved in a decade despite billions of dollars spent on travel technology.

The reason is that the fundamental interaction model has not changed since Expedia launched in 1996. You fill out a search form. You get a list of results. You sort, filter, compare, open new tabs, lose track of what you already looked at, and eventually book something out of exhaustion rather than confidence.

Every major travel platform has tried adding AI to this model. They bolt a chatbot onto the sidebar. The chatbot can answer questions about destinations, maybe suggest a few options. But when you want to actually book, you get pushed back into the same old interface. The chatbot is a feature. The search form is still the product.

This is where the architectural split between chatbots and agents begins to matter.

Request-response vs. goal-oriented systems

A chatbot operates on a request-response loop. You ask a question. It generates an answer. The interaction is stateless or nearly stateless. Each exchange is independent. The chatbot does not remember what you asked five minutes ago unless someone has bolted on a basic conversation buffer, and even then, it has no understanding of your broader goal.

An agent operates on a goal-oriented loop. You express an objective: "I need to get to Tokyo in April for under $1,500." The agent takes that goal and works toward completing it. It searches live flight inventory. It ranks results based on what it knows about your preferences. It presents curated options with explanations. When you refine your requirements, it adjusts without starting over. When you are ready to book, it handles the transaction.

The difference is not cosmetic. It is architectural. A chatbot needs one capability: text generation. An agent needs text generation plus tool execution plus memory plus reasoning plus transaction handling. Each of those components represents a substantial engineering investment, and they all have to work together.

Here is a concrete way to see it. Ask a chatbot "what are some good flights to Tokyo in April?" and you will get a paragraph of text listing some airlines and approximate price ranges based on the model's training data. The information might be months or years out of date. You cannot book any of it. The chatbot has answered your question and its job is done.

Ask an agent the same thing and it queries live flight APIs, pulls back real inventory with real prices, scores each option against your history of preferring direct flights and morning departures, selects the top three options that balance price and quality, and presents them as interactive cards you can book with one tap. The agent has not answered your question. It has started working on your goal.

Tool use as the dividing line

The technical capability that makes this possible is function calling, sometimes called tool use. This is the ability of a language model to invoke external APIs, databases, and services as part of its reasoning process.

Before function calling became reliable, getting an LLM to interact with an API required hacky workarounds. You would prompt the model to output a JSON blob in a specific format, parse that output with regex, hope it was valid, and then call the API yourself. The success rate was roughly 60%. For a travel booking system where errors cost real money, that was unacceptable.

Modern function calling changed everything. The model can now invoke well-defined tools with structured parameters at accuracy rates exceeding 95%. In a single reasoning chain, our agent processes 3 to 7 tool calls per complex query. Search flights. Check hotel availability. Verify seat maps. Compare fare classes. Process a booking. Each tool call returns real data that the agent incorporates into its response.

This is not a chatbot that sometimes calls an API. This is an orchestration system where tool use is the primary mode of operation. The language model is the reasoning engine that decides which tools to call, in what order, with what parameters. The text generation is almost a side effect. The real work happens in the tool calls.

We ship over a large set of tools in production. They cover the entire travel lifecycle: search, rank, book, modify, cancel, track, alert. The agent selects from this suite based on what the conversation requires. When you say "find me flights to Tokyo," it calls the flight search tool. When you say "actually, make it a round trip and add a hotel," it calls both flight search and hotel search, then correlates the results to ensure your check-in date matches your arrival.

Persistent memory turns interactions into relationships

The second capability gap between chatbots and agents is memory.

A chatbot treats every session as a blank slate. Even chatbots with conversation buffers only remember the current session. Close the app and come back tomorrow, and the chatbot has no idea who you are or what you were planning.

Our agent maintains persistent, cross-session memory. It stores three types of information:

Episodic memory records specific events. You booked a flight to Barcelona last September. You stayed at a boutique hotel in the Gothic Quarter. You told the agent the room was too small. These are facts about things that happened.

Semantic memory stores preferences and generalizations. You prefer aisle seats. You like boutique hotels over chains. Your budget for European trips is usually $150-200 per night. These are derived from episodic memory and explicitly stated preferences.

Behavioral pattern recognition identifies habits you may not even articulate. You always book flights 3-4 weeks in advance. You tend to pick morning departures. You have never booked a red-eye. These patterns emerge from booking history without being explicitly declared.

Context windows grew from 4,000 tokens in 2022 to over 200,000 tokens in 2025. That means we can fit entire trip histories into a single prompt. But raw context window size is only part of the solution. The agent also needs to know which memories are relevant to the current conversation and how to weight them. A preference you stated explicitly ("I always want an aisle seat") should outweigh a pattern we inferred from three bookings.

This is why memory is a competitive moat, not just a feature. Every interaction teaches the agent something. After your first trip, the agent knows your basics. After your fifth trip, it knows your patterns. After your tenth trip, it feels like talking to a human travel advisor who has known you for years. That accumulated knowledge cannot be replicated by a competitor on day one. It creates organic switching costs that compound over time.

AI-native platforms report customer acquisition costs 3 to 5 times lower than traditional OTAs, largely because retention is dramatically higher. Users do not want to start over with a system that knows nothing about them.

The UX collapse: when the agent is the interface

When you have an agent that can search, rank, book, and remember, something interesting happens to the user interface: most of it becomes unnecessary.

Traditional travel platforms have complex UIs because they have to. Search bars. Date pickers. Filter sidebars. Results grids. Pagination. Comparison tools. Map views. Each of these exists because the user is doing the cognitive work of finding and evaluating options. The UI is scaffolding for human decision-making.

When an AI agent does that work, the scaffolding disappears. The interface collapses to a conversation thread with inline cards. No search bar, because you describe what you want in words. No filters, because the agent applies your preferences automatically. No results grid, because the agent curates three options instead of dumping hundreds.

Traditional booking involves 15 to 20 decisions and takes 45 to 90 minutes. Conversational booking involves 1 to 2 decisions and takes 3 to 5 minutes. The user is not navigating an interface. They are having a conversation.

This is not just faster. It is categorically less stressful. That 67% of travelers who find booking stressful are stressed because they are doing work that an agent can do for them. Remove the work and you remove the stress.

Measuring the difference

The distinction between chatbot and agent is not just philosophical. It shows up in measurable outcomes.

Task completion rate is the north star metric. What percentage of users who express a travel intent end up with a confirmed booking? For chatbot-style interfaces bolted onto traditional platforms, this number tracks close to standard OTA conversion rates: low-single-digit. For agent-based systems, the numbers are substantially higher because the agent actively works toward completing the task rather than passively displaying information.

Turns to booking measures efficiency. How many conversational turns does it take to go from initial intent to confirmed reservation? Fewer turns means better intent understanding, better preference recall, and better curation. We track this obsessively because it directly correlates with user satisfaction.

Preference match scoring evaluates whether the agent's recommendations actually align with what the user wants. We measure this by tracking confirmation accept rates: how often does the user book the agent's top recommendation versus asking for alternatives? Higher accept rates indicate the agent is learning and applying preferences correctly.

User retention for AI-native products is 2 to 3 times higher than for products that bolt AI onto existing interfaces. I believe this is because the agent model creates a relationship that improves over time, while the chatbot model creates an interaction that resets every session.

What comes next: progressive autonomy

Everything I have described so far is the current state. The agent searches, ranks, presents, and books with your confirmation. You are still the decision-maker. The agent is a very capable assistant.

The trajectory we are building toward is progressive autonomy. As the agent demonstrates competence and earns trust, it gradually takes on more responsibility.

Level one is where most AI travel tools sit: information retrieval. "Here are some flights to Tokyo." Useful but limited.

Level two is where our agent operates today: curated recommendations with explanations. "Here are your three best options. I recommend option B because it is a direct morning flight, which you prefer, at a price below your usual range for this route."

Level three is confirmed delegation. "I found a great flight for your Tokyo trip. It matches your preferences and it is $200 below the average price for this route. Should I book it?" The user still confirms, but the agent did all the work.

Level four, which we are working toward, is autonomous action for low-stakes decisions. The agent rebooks your flight when it detects a cancellation. It adjusts your hotel when your arrival time changes. It handles the logistics so you can focus on the trip itself.

Three percent of flights experience significant disruptions daily. When your midnight flight gets canceled, you do not want to open an app and start searching. You want an agent that has already found alternatives and is waiting for your approval, or in the future, has already rebooked you.

The gap between chatbot and agent is not just about current capability. It is about the ceiling. A chatbot's ceiling is better answers to your questions. An agent's ceiling is handling your travel life so you barely have to think about logistics at all.

We chose to build the agent because we believe the ceiling matters more than the floor. The floor is easy. The ceiling is where the product becomes something that did not exist before.

The economics of agents vs chatbots

Building an agent costs more per interaction than running a chatbot. That is a fact worth examining.

A chatbot receives a user message, generates a text response, and that is it. One model call. Maybe 500-1,000 tokens total. At current inference pricing, this costs fractions of a cent.

An agent receives a user message, reasons about intent, calls 3-7 tools (each adding tokens for the schema, parameters, and results), synthesizes everything into a response, and maintains memory state. A complex interaction might consume 5,000-15,000 tokens. The cost per interaction is an order of magnitude higher.

This is worth it because the value per interaction is orders of magnitude higher. A chatbot interaction has roughly zero revenue potential. The user gets information and leaves to book elsewhere. An agent interaction can result in a $500 flight booking, a $200/night hotel reservation, and a lifetime customer who returns for every trip.

The unit economics of agents vs chatbots look bad on a cost-per-query basis and excellent on a cost-per-booking basis. We optimize for the second number.

There is also a compounding effect. Each agent interaction that results in a booking generates preference data that makes the next interaction more efficient. The agent learns what the user wants, so future conversations require fewer turns, fewer tool calls, and less exploration. The cost per interaction decreases over time for returning users while the quality increases.

AI-native platforms report customer acquisition costs 3 to 5 times lower than traditional OTAs. The agent architecture is more expensive to build and run, but it generates dramatically more value per user. The economics work because the product is fundamentally different, not because it is a cheaper version of the same product.

Why most "AI travel" products are chatbots in disguise

I want to name a pattern I see across the industry. Many products marketed as "AI travel agents" are chatbots with thin wrappers around traditional search APIs.

The tells are:

No booking execution. The "agent" generates recommendations but when you want to book, you get redirected to an OTA or airline website. This is a chatbot with affiliate links.

No persistent memory. Every conversation starts fresh. The "agent" does not remember your last trip, your preferences, or your name. This is a chatbot with a good prompt.

No real-time data. The "agent" discusses travel in general terms but cannot quote a specific price for a specific flight on a specific date. This is a chatbot using training data.

Form fallback. When things get complex, the "agent" shows you a traditional search form. The conversation was a facade over the same old interface.

We built Nowah to pass a simple test: can a user go from "I want to fly to Tokyo" to a confirmed booking without leaving the conversation? If the answer is yes, it is an agent. If the answer is no, it is something else wearing an agent's name.

The test matters because it aligns with what users actually need. Nobody needs another way to browse flight options. People need a way to book flights that does not take many websites and 45 sessions. Only agents deliver that.

The honest tradeoffs

I should be transparent about what we gave up by choosing the agent architecture. It is harder to build. The surface area for bugs is much larger. Tool orchestration introduces failure modes that pure text generation does not have. Memory systems require careful privacy engineering. The latency budget is tighter because multiple tool calls have to complete within a conversational response time.

We also took on more responsibility. When a chatbot gives bad information, the user can blame themselves for not verifying it. When an agent makes a booking, the agent owns the outcome. If it books the wrong flight, that is our problem to fix.

These tradeoffs are real. We accepted them because we believe the alternative, building another chatbot that talks about travel without booking it, does not actually solve the problem travelers have. And the problem, spending hours across many websites to buy something that should take minutes, is too important to solve halfway.

What we would tell someone starting today

If you are building an AI product in travel or any other complex consumer domain, here is what I would tell you.

First, decide whether your product is conversational decoration or a real system of action. If users cannot complete their core task entirely within your AI interface, you have built a chatbot with good marketing. There is nothing wrong with chatbots for some use cases. But do not confuse them with agents and do not promise agent-level outcomes from chatbot-level architecture.

Second, invest in tool reliability before scaling features. It is tempting to add tools quickly. Twenty tools with 90% accuracy is worse than ten tools with 99% accuracy. Each unreliable tool erodes trust, and trust is the scarcest resource in an AI product.

Third, build memory from day one. Retrofitting memory onto a stateless system is painful. Designing for memory from the start means every component expects persistent context and uses it naturally.

Fourth, accept higher costs per interaction and justify them through higher value per interaction. Agent architecture is more expensive than chatbot architecture at the per-query level. The economics work because the revenue per user is dramatically higher. If your unit economics depend on chatbot-level costs, you cannot build an agent.

Fifth, prepare for failure. Not in a pessimistic way. In an engineering way. Design error recovery as carefully as you design the happy path. In a system with 70+ tools and multi-step chains, things will go wrong. The quality of recovery determines the quality of the product.

The best travel app is the one that does the work for you. That requires an agent, not a chatbot. We built the agent.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.