Why Agents Struggle to Book Travel

There is a quiet assumption behind a lot of AI product design right now: that a model which knows enough about the world can act in it. For most domains, that assumption holds up long enough to ship a demo. In travel, it collapses immediately.

A language model can tell you that Lisbon is warm in October, that TAP flies there from Paris, and that the Alfama neighborhood is worth staying in. What it cannot tell you is what a seat on tomorrow's 7:15am costs right now. Not because the model is weak, but because that number did not exist when the model was trained, and it will not exist in ten minutes either.

Travel prices are not facts, they are events

Most data an LLM absorbs is reasonably stable. Capital cities, chemical properties, the plot of a novel. Travel pricing is the opposite. An airfare is the output of a revenue management system reacting to load factors, competitor moves, day of week, booking curve position, and inventory buckets that open and close continuously. The same seat can move 40% in a day. Hotel rates behave similarly, with dynamic pricing engines repricing against occupancy and local demand signals in near real time.

This means training data about travel prices is not slightly stale. It is structurally meaningless. A price without a timestamp and an availability check attached to it is not information, it is a guess dressed up as a fact. And when an agent presents a guess to a user who is about to spend money, that is not a small failure mode.

The consequence is straightforward. Any agent that wants to do real work in travel has to reach outside itself, every time, for every request. There is no cached version of the world that gets you there. The only path to a live fare is a live API call against real inventory.

The search box was built for humans, not for agents

Once you accept the API requirement, the next problem shows up fast: most travel APIs were designed as the backend of a search box.

They expect an origin, a destination, an exact date, a cabin class, a passenger count. Fill in the boxes, get a list. That model made sense when a human sat in front of a form and had already done the hard part, which is deciding what they wanted.

Agents do not arrive with that work already done. They arrive with intent. "Somewhere sunny in November under 400 euros." "A place near the conference venue with a desk and good wifi." "Get the three of us from different cities to the same place for a weekend." "Same trip as last time but a week later."

Every one of those is a legitimate travel request and none of them map cleanly onto a classic search endpoint. The usual workaround is to make the agent guess: pick a destination, pick a date, run a query, throw away the result, guess again. That is slow, expensive, and produces worse answers than the user would have found on their own.

We built Jinko's API the other way around. The primitives accept broad intent and resolve it into real, priced, bookable options. Flexible dates, open destinations, multi-origin group travel, budget-anchored discovery, and constraint-driven filtering are first-class inputs, not things you simulate with a hundred sequential calls. An agent should be able to ask the question the user actually asked.

From search-only to booking

Search-only integrations produce agents that are, in the end, elaborate research assistants. They surface options and then hand the user off to a booking flow somewhere else, which is where the value leaks out and where the experience breaks. The user came for a trip and left with a list.

A whole category of new search APIs is being built for agents right now, because the ones designed for human web browsing do not serve a machine that needs structured, current, verifiable answers. Exa is one of the companies leading that shift, and we work with them. What becomes obvious quickly is that travel is the hardest surface in that landscape. It resists indexing: there is no page to crawl that holds tomorrow's fare, prices move constantly, and interpreting them correctly takes real travel expertise, from fare construction and inventory buckets to the rate structures behind a hotel's nightly price. A general web index cannot absorb that, and it should not have to. Jinko will power these companies with the real-time travel layer underneath their search, so that when an agent asks a travel question it gets a live answer rather than a stale approximation.

Booking is another beast entirely. You have to be an accredited travel agency, take the payment, and own everything that happens after confirmation. Jinko is accredited in Europe and in the United States, with flights and hotels live today and trains, car rental, and activities being added.

The execution layer is where travel actually gets hard

The license is the entry ticket, not the product. The difficulty lives in everything that happens after an agent has found something, and that is the layer almost nobody is building for agents.

Execution starts with recommendation. Returning two hundred fares is not an answer, it is a deferral. Something has to reason about which option is genuinely right for this traveler given their constraints, their tolerance for connections, their loyalty status, the refund terms they can live with. An agent needs a partner that surfaces the right product, not a firehose it has to re-rank blindly.

Then the agent has to pay. Not hand a checkout link to a human, actually settle the transaction: card on file or agent-native payment rails, 3DS where required, currency handling, fraud exposure, and the fare rules that determine whether the price you quoted thirty seconds ago is still the price. This is where most agent travel projects quietly stop, because it is the point where the problem changes from software to financial and regulatory infrastructure.

And then the trip has to be managed. Travel is not a purchase that ends at confirmation. Schedules change, flights get cancelled, guests need a name correction, plans move, refunds have to be qualified against fare conditions, and someone has to hold the ticket through all of it. An agent that can book but cannot change, cancel, refund, or reissue has handed its user a liability rather than a service.

Jinko is building both halves. The search layer that speaks intent, and the execution layer underneath it: recommendation, agent payment, ticketing, and full post-booking management exposed through the same API. The complexity is real and it does not go away, but it should be ours to absorb, not something every builder has to rediscover.

A new class of companies is being built right now to give agents the execution layer they need, and some of them are tackling the general problem rather than a single vertical: Sapiom, Naïve, AgentCard, Ophelia. Jinko wants to be the travel part of that stack, and we are glad to partner with those kind of companies to bring travel capabilities to the agents they serve.

Agents as economic actors

Agents are moving from things that produce text to things that produce outcomes, and outcomes involve money. Payment rails for autonomous agents are being built right now. Merchants are beginning to think about agent traffic as a distinct customer segment rather than as bot noise to be blocked.

Travel is one of the largest consumer categories in the world, almost entirely digital, and defined by exactly the kind of live, high-stakes decision-making agents are good at. It should be one of the first categories where they transact at scale. What has stood in the way is not model capability. It is infrastructure built for a buyer that is not a person, and trust: handing an agent a card for a few thousand euros of holiday is a leap.

That is the gap Jinko exists to close. Live inventory, intent-native interfaces, an execution layer that runs from recommendation through payment and beyond, and the licensing to complete a sale. But making a booking technically possible is the easy part. Our job is to make sure the agent does the right thing: the option fits the traveler, the quoted price is the charged price, the fare rules are understood before ticketing, and a real agency is standing behind the trip when a flight is cancelled at midnight. That is what turns an agent from something a user experiments with into something a user trusts.

Agents are becoming economic actors. Our job is to make sure that when one books a trip, the person who asked for it was right to let it.

Building an agent that needs to book travel? The Jinko API, MCP server, and CLI are available to builders at gojinko.com.