Vision paper

Travelers today carry everything but their context. A passport in the pocket, a boarding pass in an app, a hotel confirmation in an email — and behind all of it, a hundred profiles, scattered across a hundred platforms, none of which know each other and none of which travel with the person they describe.

The arrival of capable AI agents changes the stakes. For the first time, software is good enough to actually plan, book, and manage travel on a person’s behalf. But every agent the traveler meets is an amnesiac. Every conversation starts from zero. Every preference must be explained – again. The agents are sophisticated; their relationship with the traveler is not.

We believe the missing layer is a portable, travel memory — a structured artifact that any agent or service can read with permission, and that the traveler can take with them wherever they go. We call the long-lived profile traveler.md. We call the per-trip context trip.md. Together, they are the foundation for a hyperpersonalized travel future where the memory belongs to the traveler, not the platform.

This document describes the vision behind that foundation: why it is necessary, what it makes possible, and where we believe the technology needs to go from here.

We are rapidly approaching a hyperpersonalized world.

A world where your flight rebooks itself before your second sip of coffee, because it already knows your kid’s daycare hours and that you stopped flying red-eyes years ago. Where the hotel has your room ready the way you like it, because you told it once, three years ago, and the note has followed you ever since. Where the cab driver skips the small talk on Monday mornings because Monday mornings aren’t your thing. Where your AI travel companion pings you at lunch to say a last-minute cancellation has opened up tonight at the restaurant you have been dreaming of for three years — and asks if you would like it to grab the table.

A world where travel finally becomes about the trip — not the logistics of the trip.

This world is closer than most travelers realize. The AI models are good enough. The booking systems are becoming integrated enough. The agents are smart enough. But there is a question hiding underneath every demo, every keynote, every promise. How?

How does the world come to know you that well? Whose servers store the memory? Whose policies govern it? When you switch from one AI to another, does your context come with you — or do you start over, again, explaining for the hundredth time that you cannot do connections under ninety minutes with two kids?

The technology is ready. The foundation is not.

We believe the foundation should belong to the traveler. We believe memory should be portable, not platform-bound. We believe a person should be able to carry their context between agents, services, and tools without asking permission. We believe trust starts with the ability to read what is written about you, and ends with the ability to revoke access whenever you choose.

We believe travel is for presence, not paperwork.

We believe a traveler’s memory should travel with them.

This is the story of how we think that foundation should work, and why we are building it.

We are The Travel Memory Company.

For most of the history of travel, the agent who knew you was a person. They sat behind a desk in your neighborhood. They knew you flew to see your sister twice a year. They knew you would not stay above the seventh floor. They knew which seat you wanted and which airline you would not fly. You did not have to explain it. They were paid, in part, to remember.

Then the agent slowly disappeared, though not entirely. Booking moved online. Memory got replaced by accounts. A thousand accounts. One for the airline, one for the hotel chain, one for the second hotel chain, one for the rental car company, and one for each travel site you have ever used to compare them. Each account knows a sliver of you. None of them knows the whole.

You compensate for the gap. You re-type the passport number. You re-paste your loyalty number into a form that should have remembered it. You re-upload the visa. You learn which booking flow forgets which detail, and you build muscle memory around it. The friction is so distributed across so many small interactions that you stop noticing how much of your life it consumes.

And then the agents came back. Not the human kind — the new kind. Large language models with access to tools. Conversational interfaces that can read a request and act on it. The promise was that the agent who used to sit behind the desk could be reborn at scale, available to everyone, always.

The promise is real. The technology is here.

But the agents are still amnesiac. Each one starts from zero. You teach Claude how you book flights. Then you teach ChatGPT. Then you teach the booking site’s new AI. Then you teach the airline’s agent. You become a travel writer of one — endlessly producing the same essay about yourself, for an audience that never gets to keep a copy.

This is the world we are walking into. Powerful agents, fragmented memory, and a traveler who carries the entire burden of context on their own shoulders.

It does not have to be this way.

If the problem is that agents do not remember you, the most natural solution is to make them remember.

This is what most of the industry is now doing, and it is a step forward.

Every major AI platform is building its own memory layer. Sign in to the assistant, let it learn your preferences, and over time, it gets meaningfully better at predicting what you want. The pitch is reasonable. The execution is competent. For the traveler who lives mostly inside one assistant, the experience meaningfully improves.

But the memory belongs to the platform that built it.

If your travel context lives inside one assistant, switching assistants means starting over. If your preferences live inside one booking experience, the next booking experience does not see them. If your loyalty data lives inside one airline, the airline you are not loyal to does not know you exist. This is not a failure of any individual platform — every one of them is solving the problem they are positioned and incentivized to solve. It is a consequence of the architecture. Memory built inside a platform belongs to that platform, by definition, no matter how generously its policies are written.

There is a second, more subtle consequence. When memory is held by the platform, the policies governing it are written by the platform. What is collected, what is retained, what is shared with whom, what survives a change of ownership, what is recoverable when an account is closed — all of this sits in policies the traveler can read but cannot revise. Most platforms write those policies thoughtfully. Even when they do, the policies are not the traveler’s to write.

This is the first dip in the story. The agents have arrived, and they have brought real value with them. But the question of who holds the memory has not been answered yet. Each platform has answered it for itself. No one has answered it for the traveler.

The amnesia tax is shrinking, slowly, within the borders of any given platform. Between platforms, it is still the full price.

For more than a decade, the travel industry has been working toward a vision it calls the connected trip.

The phrase shows up in airline keynotes, in hotel-group strategy decks, in OTA investor presentations, and in the product roadmaps of the largest travel-technology platforms. It refers to a future in which every part of a traveler’s journey — the flight, the hotel, the rental car, the rideshare, the in-destination experience, the dinner reservation — is woven together into a single coherent experience instead of fragmented across a dozen disconnected vendors. The vision is sound. The economic story for the champion is compelling. The pain point being solved is a reality for travelers around the world.

In 2025, UN Tourism recorded an estimated 1.52 billion international tourist arrivals, a new post-pandemic record, and that figure does not even count the billions of additional domestic trips taken every year. The traveler feels the fragmentation every time they have to stitch together their own itinerary from a half-dozen confirmation emails, multiplied by 1.5 billion people doing it at once.

The fragmentation is not theoretical. McKinsey’s clickstream research found that the average purchase journey for a single hotel room lasts 36 days and involves 45 separate digital touchpoints across search engines, intermediaries, and supplier sites. Expedia Group, in its own Path to Purchase research with Luth Research, found that the average trip consideration window stretches 71 days and that travelers consume 141 pages of travel content in the 45 days before they finally book. TripAdvisor and Similarweb, looking at the same problem from a different angle, found that half of all travel purchase journeys involve 30 or more travel touchpoints. These are not edge cases. They describe how a normal person plans a normal vacation.

The numbers make a clear case that the traveler’s experience is broken. They do not, however, make a case for any particular fix.

The leading approach to solving the fragmentation has been to assemble the connected trip inside the platform — to bring more of the journey under one roof. Airlines, hotel groups, online travel agencies, credit-card programs, and travel-technology providers are each, reasonably, building toward a future where more of a traveler’s experience is coherently delivered through their channel. Every one of these efforts is genuine. Every pursuit is making real progress for the travelers who stay within their walls.

But the trip itself does not stay within walls. And the traveler doesn’t either.

A traveler might book their flight through one channel, their hotel through a second, their rental car through a third, plan the trip with an AI assistant from a fourth, and ask a fifth for restaurant recommendations once they arrive. In a hyperpersonalized future, they might use even more — a corporate travel tool, an agentic concierge, a destination specialist, an in-destination experiences marketplace. Each of these touchpoints has good reasons to exist, and many of them are working hard to be excellent at what they do.

Traveler.md is a layer that benefits every actor in the travel ecosystem — the traveler first, and every platform serving them.

Every platform working on the connected trip is trying to solve the same underlying problem: they do not know enough about the traveler to deliver the experience they would like to deliver. They are building memory layers, preference systems, and personalization engines to close that gap — and spending heavily to do it. But each of those efforts starts cold with every new traveler, and each is bounded by what that platform happens to see. An airline knows how the traveler flies. It does not know how the traveler sleeps. A hotel knows the room preference. It does not know the layover the room is connected to. A planning AI knows the trip being researched. It does not know the trip the traveler took last year and loved.

Reading a Traveler.md is the fastest way for any platform to know its customer. The booking site that reads it gets better conversion, because it stops asking questions the traveler has already answered. The hotel that reads it gets a better stay, because the room is right the first time. The AI that reads it gets a better plan, because it is not starting from zero. Every platform that engages with the file does more of what it was already trying to do — and does it better, faster, and with less friction for the customer it is trying to serve. We are not asking platforms to give anything up. We are giving them a shortcut to the thing they have been building toward.

The question is not whether any single platform can deliver a connected trip within its walls. Many of them can, and increasingly will. The question is what happens to the connection in the gaps between them — between the airline and the hotel, between the booking moment and the in-destination experience, between the planning AI and the booking platform that fulfills the plan. Those gaps are where the traveler still lives. And right now, the gaps are where the connection breaks.

The connected trip is not a single trip assembled inside a single platform. The connected trip is a trip that stays connected to the traveler — so that every platform the traveler chooses to use, including the ones doing excellent work to deliver connected experiences within their own walls, starts from the same memory and contributes back to it.

The connection lives with the person. The platforms remain the platforms. The trip stays whole because the traveler does as well.

Step back from the implementation, and the real question becomes visible.

It is not will the world know me? The answer to that one is obvious — yes, soon, in detail, whether we plan for it or not. The technology is here, the incentives are aligned, the rollout is already underway.

The real question is on whose terms?

Who holds the memory? Who decides what it contains? Who can read it, write to it, sell access to it, and retain a copy of it after you leave? When you change your mind about a preference, where does the correction propagate? When you change your mind about a platform, what comes with you and what is lost?

Hyperpersonalization without portability is a one-sided relationship. The traveler is known, in extraordinary detail, but cannot move. The relationship has the asymmetry of a tenancy — a landlord who has read every page of your diary and a renter who cannot take the diary with them when they leave.

We do not think this is the future that people actually want. We think it is the future people will end up with by default, unless someone proposes a different foundation.

So we are proposing one.

The insight is small, almost embarrassingly so.

What if the memory belonged to the traveler?

Not a profile inside an app. Not a record in a vendor’s database. An artifact — a real, portable file — that the traveler owns, edits, carries between services, and revokes when they choose. A document in a format that humans can read with their eyes and machines can read with their tools. Something simple enough to inspect, durable enough to keep, and standard enough that any agent willing to follow the protocol can use it.

Markdown is the right format for this. It is plain text. It is human-readable. It is machine-readable. It has survived every wave of formatting fashion for thirty years because it does the minimum thing well: it lets a person write structured information without surrendering it to a particular tool. A traveler.md file looks like a document because it is a document. The traveler can open it, read it, change a line, and close it. No proprietary viewer required. No platform lock-in. No translation layer between the person and what is written about them.

A traveler.md captures the long-lived layer of who you are as a traveler: your preferences, your constraints, your habits, your dream destinations, the trips you have already taken and remember fondly, and the kinds of trips you avoid. A trip.md captures the per-trip layer: where you are going, when, with whom, what you have already booked, what you still need, what has gone wrong, and what has been worked around. Together, they describe a traveler in a way an agent can actually use — and they do it in a file the traveler keeps.

The shift is small. The consequences are large. Once the memory is portable, every agent in the traveler’s life is reading the same source of truth. The platforms remain the platforms. The traveler can move between them without losing themselves along the way.

If this idea were as simple as we have just described it, it would already exist. It doesn’t, for two reasons. The first is coordination: making this work means many stakeholders — agents, services, providers, regulators — agreeing to read and write a shared artifact, in shared ways, with shared rules about what each is allowed to do. The second is self-interest: until now, no platform has had a strong enough reason to do the hard work of building portability rather than the easy work of building enclosure. The technology has been ready for a while. The motivation has not.

The first hard problem is trust. If many agents and services can read and write the same artifact, the artifact has to be defensible against bad edits. A booking site that rewrites your preferences to suit its inventory is a worse outcome than no memory at all. Solving this requires careful scoping of what each agent is permitted to do, version history that lets the traveler see exactly what changed and when, and an audit trail that makes silent corruption impossible.

The second hard problem is portability, without chaos. A file that lives in fifteen places at once is a file that disagrees with itself. The foundation has to support concurrent access by multiple agents without producing a tangle of conflicting versions. This means optimistic concurrency, conflict detection on write, and a clear model for which version is canonical at any given moment.

The third hard problem is privacy and the right to be forgotten. European law, and increasingly law in many other jurisdictions, gives travelers the right to demand that their data be deleted. A portable memory artifact has to honor that right, not just in the primary store, but in every system that has cached, copied, or processed it. The architectural choices for deletion propagation are non-trivial. We are designing the foundation so that the obligation is built in, not bolted on.

The fourth hard problem is governance. Who can write what, and under what conditions. Governance and compliance has to be expressible in a way that travelers can actually understand. A consent flow that requires reading a thousand-word policy is consent in name only. The permission model has to be small enough to fit on a screen and strong enough to mean something.

We are not the first people to attempt portable user data. The graveyard of past attempts — federated identity protocols, data wallets, self-sovereign credentials — is large, and we have read the tombstones. What is different now is that the agents finally have a reason to use the file. For the first time, there is a population of consumers (LLMs, AI assistants, agent runtimes) that can read structured markdown, follow a protocol, and act on what they find. The memory layer is no longer waiting on a chicken-and-egg problem. The egg has already hatched.

This is the deepest part of the journey. The problems are real, and we do not pretend otherwise. Naming them is the first step to solving them.

We are building two things, and they are inseparable.

The first are the files themselves — traveler.md and trip.md — defined, structured, portable, and human-readable.

The second is the platform that lets a traveler manage every connection to those files — every agent, every service, every tool that reads or writes them. The platform is where the traveler grants access, revokes access, sees what has been read, sees what has been written, and decides what comes next. It is not a settings page tucked away inside a profile. It is the control plane for the entire portable-memory model. Without it, “you own your data” is a slogan. When you have a platform with the traveler in control, it is a feature with edges, audit trails, and consequences.

Here is what each piece does, and what is being built today.

The files. A traveler.md captures the long-lived layer of who you are as a traveler: preferences, constraints, past trips, dream trips, and the kinds of trips you avoid. A trip.md captures the per-trip layer: where you are going, when, with whom, what you have already booked, what you still need, what has gone wrong, and what has been worked around. Both are expressed in markdown. Both are designed to be human-readable first, machine-readable second. The traveler can open either one in any text editor and understand it without explanation. The file is the thing the traveler owns.

The platform. A web experience at the traveler’s account that does four jobs:

• It is where the traveler creates and edits their files directly, with a friendly UI on top of the raw markdown.
• It is where the traveler sees, at a glance, every agent and service connected to their memory — Claude, ChatGPT, a booking partner, a future travel concierge — with the scopes each has been granted (read, create, update).
• It is where the traveler revokes any of those connections instantly, no support ticket required.
• And it is the audit surface: a clear log of what was read, what was written, and by whom, so the traveler can verify the system is behaving the way they expect. The platform is the place where the traveler holds the pen, and the place where they hold everyone else accountable.

The connector. A protocol-level integration that lets external agents reach the files, with the traveler’s permission. The integration runs over the Model Context Protocol (MCP). This means Claude Desktop, Claude Cowork, Claude Code, ChatGPT, Codex, and other services that support MCP can already read and write to a traveler’s files today. Ability to set up custom connectors on services like Claude and ChatGPT may vary depending on the user’s plan and device (i.e. web vs. desktop). We are also applying for an official Claude connector and an OpenAI app, both of which would make connecting a one-click experience rather than something the traveler has to set up themselves. The connector layer is what makes the files actually portable — without it, the file is just a document; with it, the file is a memory that travels.

Tripp. A voice agent that sits between travelers and the systems they interact with — a third voice in the conversation, alongside the traveler and the underlying services. Tripp is a foundational layer of the TravelAI Agentic Network, used across multiple TravelAI surfaces, not only Traveler.md. Within Traveler.md, Tripp’s first job is onboarding: a short conversation, asked the way a thoughtful travel agent would ask it, that produces an initial traveler.md without making the user fill out a form. The transcript becomes the profile; the profile becomes the foundation. Outside Traveler.md, Tripp does other work for other brands, which is part of why Traveler.md is durable — the voice the traveler talks to is the same voice everywhere TravelAI shows up.

This is the MVP. It is deliberately small.

Our approach is to ship the foundation first, prove it works for real travelers and real agents, and grow it from there. Speed over surface area. The grander architecture — additional connectors, deeper integrations, the ecosystem of agents reading the file — will come once the foundation has weight under it.

What we are shipping today is a portable file, a platform that lets the traveler manage every connection to it, and the simplest possible way to actually use the system end-to-end. Everything else in this paper describes where that foundation goes next.

A profile tells an agent who you are. It does not tell the agent how you want things done.

These are different problems. An agent that knows you have two kids, a 6′2″ frame, and a meeting Tuesday morning still has to decide, when it sits down to book your flight, whether to optimize for legroom or for the most convenient schedule, whether ninety extra dollars for an exit row is worth it, whether a seventy-five minute layover in Atlanta is fine or risky, whether to send you the options or just book the obvious one. Two agents reading the same profile will make different choices. Most of them will be wrong.

Knowing isn’t enough.

We think of the missing piece as skills — small, portable instructions that travel with you and tell any agent how to handle a specific kind of task on your behalf. A flight skill. A hotel skill. A rebook-when-it-rains skill. A what-to-do-when-the-airline-loses-my-bag skill. Each one is a short, human-readable document the traveler writes once — or has written for them — that turns vague competence into specific behavior. There are often no right answers, but shades of grey. There are wrong answers, however.

A flight skill might say: prefer Star Alliance, never basic economy, exit row if I’m in coach, no layovers under 90 minutes in ATL or ORD, ask before anything over $1,200 round trip. Any agent reading it knows exactly what to do.

The reason this matters is the same reason traveler.md matters. Without portable skills, every agent re-learns you. You teach Claude how you book flights. Then you teach the airline’s agent. Then the booking site. Then the new agent your company gave you last month. Each one approximates. None of them is right. The amnesia tax has a sibling — the re-instruction tax — and most travelers pay both without realizing they’re being charged.

Skills make the tax go away. Write the flight skill once, carry it everywhere, edit it when your life changes, revoke it from any agent that loses your trust. The skill is yours. The agent is just borrowing it.

And this is where the system stops feeling like a tool and starts feeling like a team. The agent isn’t guessing. It isn’t making you fill out a form for the hundredth time. It is reading the instructions you wrote, the way a good travel concierge would read the notes from your last assistant, and getting to work.

Skills are the natural next layer on top of traveler.md and trip.md, drawing on the profile for context and on the trip for the situation, and they extend the artifact from a description of the traveler into a set of instructions the traveler has authored for the world to follow on their behalf. We are designing the foundation today with skills in mind, even though the first version we ship will not include them. The shape of the file is forward-compatible with the shape of the future.

A portable memory artifact is only as useful as the number of agents that can read it.

This is the network effect at the heart of the foundation, and it is the same insight that has shown up at every prior moment of platform formation. A document standard is worth nothing if only one editor understands it. A protocol is worth nothing if only one client speaks it. A memory artifact is worth nothing if only one agent reads it.

This is also the reason most prior attempts at user-owned data have failed. They got the file right and got the readers wrong. The wallet had no merchants. The credential had no verifiers. The portable profile had nowhere to go. The foundation was correct, the ecosystem was empty, and the foundation died for lack of company.

We do not think traveler.md will have that problem, because the readers are already here. Anthropic, OpenAI, and the broader Model Context Protocol ecosystem have built agents that can read structured files with permission and act on what they find. The travel industry is racing to integrate those agents into bookings, support, and planning. The demand for context is enormous, and the supply, today, is nothing — every agent starts from zero with every traveler. A standard the agents can rely on is a standard the agents will use.

Each new agent that learns to read traveler.md makes the artifact more valuable to every traveler who has one. Each new traveler with a profile makes the artifact more valuable to every agent that reads it. The flywheel is the same one that has spun up every successful protocol in the history of the web — email, RSS, OAuth, ICS calendars — and it spins fastest when the format is open, the file is the traveler’s, and no party has a structural reason to keep the doors closed.

We are betting that the next decade of travel will be defined less by the agents themselves and more by the foundation they share. The agent layer will be competitive, fragmented, and fast-moving. The memory layer underneath should be cooperative, stable, and slow. One belongs to the market. The other belongs to the traveler.

Today, travel is a logistics job with a vacation hidden inside it. You spend the week before rebooking the flight that changed, hunting the visa form, and telling the hotel about your allergy again. You spend the trip itself toggling between maps, translators, currency converters, and four group chats trying to figure out where dinner is. You spend the week after filing expenses and chasing the refund for the bag that arrived three days late. The vacation, somewhere in the middle, is the part you remember.

We believe this is backwards.

Travel should be about presence. The meal you flew six hours for. The afternoon you didn’t plan. The conversation with the stranger at the next table. The look on your kid’s face the first time they see the ocean. These are the things travel is actually for, and they are the things modern travel makes the least time for. Travel is about the memories you make.

Hyperpersonalized agents change the math. When your travel memory is portable, and the agents around you can read it, the friction collapses. The flight rebooks itself because the agent already knows you cannot do red-eyes with kids and that you have a meeting on Tuesday morning. The hotel knows you always start a romantic vacation with your wife with a glass of champagne. The agent handles the visa paperwork, the lost-bag claim, the dinner reservation, the airport rideshare, or the rebook-when-it-rains. You stop being the logistics manager of your own trip.

And you get the hours back. Not the abstract hours of “saved time.” The real ones — the long ones, the ones with nothing scheduled, the ones where you sit down somewhere unfamiliar and finally remember why you came.

This is the future we are building toward. Not an AI that replaces the traveler. Not a platform that owns the traveler. An assistant — a team of assistants, eventually — that knows the traveler well enough to disappear into the background, leaving only the trip behind.

We believe a traveler’s memory should travel with them.

We believe a traveler should be able to walk between AI assistants, booking sites, airlines, hotels, and concierges without leaving their context behind. We believe the file that describes them should be readable in any text editor, owned by the person it describes, and revocable from any service that loses their trust.

We believe hyperpersonalization is coming, and that the only real question is on whose terms.

We believe the foundation of the next decade of travel should belong to the traveler, not the platform.

We believe the long, slow work of building that foundation — honestly, in the open, with the hard problems named and addressed rather than hidden — is worth doing.

We believe travel is for presence.

We are The Travel Memory Company. We are building traveler.md. We are at the beginning. We are excited for what is Up Next.

The figures cited throughout this paper, particularly in “Rethinking the Connected Trip,” are drawn from publicly available industry research. Each is listed below with its source. Together, they describe the state of travel planning under the previous generation of digital tools — the baseline from which the trajectory in this paper begins.

For more on the technical architecture, design requirements, and roadmap behind Traveler.md and Trip.md, see our developer documentation and product pages at traveler.md.