---
title: The Context Window Is the New Database
description: From 4K to 200K+ tokens — expanding context windows let AI agents fit your entire travel history into a single prompt.
canonical: https://nowah.xyz/blog/context-window-is-new-database
lastModified: "2026-08-07T08:05:15.762Z"
---

# The Context Window Is the New Database

From 4K to 200K+ tokens — expanding context windows let AI agents fit your entire travel history into a single prompt.

In 2022, the largest commercially available context window was 4,096 tokens. That is roughly 3,000 words. You could barely fit a multi-[turn conversation](/blog/multi-turn-conversation-engineering), let alone a user's travel history, preferences, and current search results.

By 2025, context windows exceeded 200,000 tokens. That is roughly 150,000 words. You could fit an entire novel. Or, more relevantly, you could fit every meaningful interaction a user has ever had with your travel platform, their complete preference profile, and the full results of a complex multi-destination search.

This 50x expansion in context capacity changed what AI agents can do. I want to explain how.

## What agents could not do at 4K

![Illustration for this section](https://pics.nowah.xyz/website-media/ai-research-010-img-1.webp)

At 4,000 tokens, an AI travel agent had to be aggressive about discarding context. A typical flight search query consumes 100-200 tokens. The flight results from a single search might consume 500-1,000 tokens. Add the model instructions (200-500 tokens), conversation history, and a few tool call results, and you are at the limit.

The agent had to forget things. Earlier parts of the conversation would get truncated to make room for new information. The user's preferences, if they were included at all, were a compressed summary that lost nuance.

This created obvious problems. The user mentions they prefer aisle seats in turn 2. By turn 10, that preference has been truncated out of the context. The agent recommends a middle seat. The user is frustrated.

Multi-turn [trip planning](/blog/[multi-city](/blog/multi-city-flight-booking-ai-agents)-trip-planning-ai-shines) was essentially impossible. A 20-turn conversation with tool calls would overflow the context window several times over. The agent would lose track of constraints, forget preferences, and contradict itself.

## The 200K leap

At 200,000 tokens, the game changes qualitatively.

You can fit the full conversation history for a complex multi-destination trip planning session. Every turn, every tool call, every result. The agent never forgets what happened earlier in the conversation because it is all right there in the context.

You can include a rich preference profile. Not just "prefers aisle seats" but a detailed record of past trips, hotel ratings, airline experiences, budget patterns, and explicitly stated preferences. The agent has full context about who this user is.

You can include complete search results. Instead of summarizing "I found 50 flights, here are the top 3," you can include all 50 flights in the context so the agent can re-rank, cross-reference, and answer follow-up questions about specific options.

A token is roughly three-quarters of a word. At 200,000 tokens, you have about 150,000 words of context. For most individual travelers, that is enough to include their entire history with the platform. Every trip, every conversation, every preference, every booking.

## Context window vs external memory

![Supporting diagram](https://pics.nowah.xyz/website-media/ai-research-010-img-2.webp)

A large context window does not eliminate the need for external memory systems. But it changes the architecture significantly.

**Pure context approach:** Stuff everything into the prompt. User preferences, conversation history, search results, [tool schemas](/blog/tool-schemas-llms-actually-understand). The model reasons over all of it simultaneously. This is simple to implement and avoids the complexity of retrieval systems.

**Pure retrieval approach:** Store everything in an external database. Before each model call, query the database for relevant information and inject it into a minimal context. This is more complex but scales better for users with years of history.

**Hybrid approach:** Use the context window for the current conversation and recent, high-relevance information. Use external memory for long-term storage and retrieval. This is what we do.

The hybrid approach wins because it combines the strengths of both. Current conversation context is always fully available (no retrieval latency, no relevance errors). Long-term memory is retrieved selectively, which means we can support users with years of travel history without hitting context limits.

The key engineering question is: what goes in the context and what gets retrieved? Our heuristic is recency and relevance. The current conversation is always in context. Recent trips (last 6 months) are in context. Older history is retrieved only when it is relevant (e.g., the user mentions "that hotel in Barcelona" and we need to find it in their history).

## Quality at scale

More context does not automatically mean better reasoning. This is a point that gets overlooked in the excitement about large context windows.

Research on long-context models shows a phenomenon sometimes called "lost in the middle." Models attend more strongly to information at the beginning and end of the context than to information in the middle. If a critical preference is buried 80,000 tokens into a 200,000-token context, the model might not weight it appropriately.

We mitigate this by structuring the context carefully. High-priority information (active constraints, recent preferences, current search results) goes at the end of the context, closest to the model's output. Background information (older history, static preferences) goes earlier. The most relevant information is always in the model's attention sweet spot.

We also found that retrieving and summarizing information before inserting it into the context often outperforms raw insertion. Instead of dumping 50 past bookings into the context, we retrieve the 5 most relevant bookings, summarize the key patterns, and insert a concise preference profile. Less noise, better signal.

## Cost implications

Longer contexts cost more. Token pricing applies to both input and output. A 200,000-token context costs 50x what a 4,000-token context costs in raw token fees.

The good news is that the cost of inference has dropped roughly 10x per year since 2023. The 200,000-token prompt that would have been prohibitively expensive in 2023 is economical in 2025.

Even so, we do not use maximum context for every request. Simple queries ("what time is my flight?") do not need 200K tokens of context. We dynamically size the context based on the complexity of the current request. A quick factual lookup gets a minimal context. A complex multi-city planning session gets the full treatment.

This dynamic sizing is an optimization problem in itself. Too little context and the agent misses relevant information. Too much context and we waste money and potentially introduce noise. We continuously tune the context selection algorithm based on task completion data.

## The hybrid approach in practice

Here is how our context construction works for a typical conversation.

**Model instructions:** Agent personality, capability descriptions, tool schemas. Always present. About 2,000 tokens.

**User profile:** Compressed preference summary, [loyalty programs](/blog/problem-with-travel-loyalty-programs), passport info, default travelers. Retrieved from the memory system. About 500-1,000 tokens.

**Relevant history:** Past trips and preferences that match the current conversation context. If the user is planning a trip to Spain, we retrieve their previous Spain trips and European travel preferences. About 1,000-3,000 tokens depending on history depth.

**Conversation history:** The full current conversation. Variable length; for a 15-turn conversation with tool calls, this might be 5,000-15,000 tokens.

**Active search results:** The most recent tool call results. Flight options, hotel options, pricing data. About 2,000-5,000 tokens.

Total: roughly 10,000-25,000 tokens for a typical conversation. Well within the 200K limit, with plenty of room for the model to reason.

For a first-time user with no history, the context is even smaller. The system starts lean and grows with every interaction.

Latency for first-token streaming is under 500 milliseconds even with large contexts. The user does not perceive any delay from the context construction process.

The context window is the new database in the sense that it is where the model does its reasoning. But like any database, what you put in matters more than how much it can hold. Selective, well-structured context at 25,000 tokens outperforms a 200,000-token context stuffed with everything we have. The art is in the curation, which is fitting given that curation is what our entire product is about.

---

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](https://app.nowah.xyz).
