Why portable preferences
You re-enter your passport on every booking site. You re-explain “window seat, aisle never” to every new assistant. You go looking for your own loyalty numbers. Each product keeps its own walled copy of you, none of it complete, none of it yours to take elsewhere. The usual fixes (bigger profiles, more cookies, deeper account walls) make the lock-in worse, not the memory better.
A file you own, not a profile you’re trapped in
Traveler.md inverts the model on four points:
- You own the file. Not the booking site, not the assistant, not the supplier.
- Format, not platform. Any tool that reads markdown and follows the field conventions can use it. Nothing to integrate, no API to be granted into.
- Markdown, not JSON. You can read and edit it directly. Agents can still parse it cleanly. Both win, which is rare.
- Built for agents. It assumes a world where most travel decisions are mediated by an LLM, and gives every one of them the same head start.
Why agents need this
LLMs are poor at remembering you across sessions, and the workarounds don’t travel. A vector store is private to one product. Tool memory is locked inside whichever assistant built it. Start a new agent and you’re a stranger again.
Traveler.md gives any agent (Claude, an OpenClaw build, a Hermes pipeline, something custom) one parsable file with everything that matters. The payoff is concrete: an agent that knows you’re vegetarian on its first run, not its fifth.
Why now
Several things lined up that weren’t true a couple of years ago:
- LLM tool use through MCP is reliable enough to trust with real personal data.
- Travelers increasingly expect an assistant to already know their preferences, and notice when it doesn’t.
- MCP has given the ecosystem a common interface, so a single file can serve many tools instead of one.
Portable traveler memory only works if there’s a standard way for tools to reach it. That standard now exists, which is why Traveler.md is possible as a format rather than just another app’s database.