A price used to be data. Now it is a function call.
For forty years an airfare was a filed artifact: you could fetch it, cache it, diff it and argue with it. It is becoming a per-query model output, and almost everything built on top of travel quietly assumed the old thing.
For about forty years, an airfare was a row in a file. An airline filed it, a distributor published it, and everyone downstream fetched the same artifact. You could cache it. You could diff last night's file against this morning's. When a customer said the price changed, you could open the record and see exactly which rule moved.
That object is being replaced by a model call. Not a faster lookup of the same thing: a different kind of thing, computed on request, for that request.
Almost every system in travel assumes the old one. Most of them will keep running and quietly stop being correct.
What a filed fare actually was
Strip the romance and a fare was a small program. A base amount, plus rules: book fourteen days ahead, stay a Saturday night, no changes, no refund. Those rules were published in the filing, identical for every buyer, and they were the mechanism.
Economists call this second-degree price discrimination, and the distinction matters more than the jargon suggests. The seller publishes a menu; buyers sort themselves by choosing which restrictions to accept. The airline never had to work out who you were. It made you declare it, by picking the cheap fare and living with the Saturday night.
That is why the rule had to be readable. A menu nobody can read is not a menu. Every "book on a Tuesday" tip anyone ever gave you was a person playing a game whose rules were posted, and the posting was not a courtesy. It was load-bearing.
What replaces it
A generative pricing engine does not file a rule and wait. It takes demand signal, route, competitive position, booking window and time to departure, and returns a number for this query. Then it does it again, differently, because the inputs moved.
There is no menu. There is no restriction to accept in exchange for a discount. There is an output, and the inputs are not things you control.
The part that breaks your systems
This is not a pricing story. It is a story about an interface changing shape underneath a lot of code that was written against the old one.
| You assumed | Because a fare was data | What is true of a model output |
|---|---|---|
| A price can be cached | The filing changed a few times a day | It is valid for the query that produced it |
| Two searches agree | Same file, same answer | Divergence is normal, not a bug |
| A price is reproducible | Re-read the record | You cannot re-run yesterday's inputs |
| Tests can assert amounts | Fixtures were stable | Golden-file tests rot immediately |
| A change is explainable | Point at the rule that moved | There is no rule to point at |
| Offers are comparable | Everyone fetched the same artifact | Each comparison is a fresh inference |
Read the third row twice, because it is the one that will cost you a support team. "It was cheaper an hour ago" used to be a checkable claim. Someone opened the fare history and either agreed or did not. Against a per-query price, that sentence is unfalsifiable in the strict sense: there is no artifact to check, and the honest answer is that nobody can reconstruct what you were shown.
That answer is unacceptable to a customer, so somebody will invent a better-sounding one. Cache what you displayed, with the inputs and a timestamp, or accept that your support desk is going to start guessing.
The rule was the product
The consumer story hiding inside the architecture is simpler than the privacy debate suggests, and worse.
Charging different people different prices does not require knowing anything personal about them. It requires knowing the shape of their trip. A one-way out Tuesday morning and back Thursday evening, booked eleven days ahead, on a route with one nonstop, is a business trip. No name, no browsing history, no loyalty number, no cookie. The itinerary is the profile.
So a system can price you precisely while touching nothing a privacy lawyer would recognise as personal data, which is exactly what makes the current wave of regulation slide off it.
The FTC published its surveillance pricing study on 17 January 2025, finding data as fine as mouse movements and abandoned baskets used to set individual prices. New York's Algorithmic Pricing Disclosure Act took effect on 10 November 2025, requiring the notice "This price was set by an algorithm using your personal data." Maryland signed the first outright ban on 28 April 2026, enforceable from 1 October, scoped to grocery. Connecticut followed on 27 May 2026.
Read the trigger in every one of them. Personal data. A model that reads only the shape of your trip discloses nothing, bans nothing and triggers nothing, while producing the outcome people object to. That is not a loophole anyone exploited. It is what happens when a rule is drafted against a story about creepy data collection and the actual mechanism turns out to be arithmetic on a booking window.
Why your shopping agent does not fix this
The comforting version is that it evens out. They get a pricing model, you get an AI agent, the arms race nets to zero.
It does not, and the reason has nothing to do with model quality. The seller's model is trained on years of its own transactions: every fare offered, every one accepted, every one abandoned, across every route and season. It has seen the distribution. Your agent sees one session. It cannot know what the passenger in 14B paid, and it cannot know what you would have paid, which is the only number the other side is trying to find.
The testing is blunt about where agentic booking actually is. When Bain put large language models against real flight search in March 2026, airline sites were reached directly only about 5% of the time, autonomous browser agents ran 5 to 30 minutes before hitting a date picker or a login wall, and no tool completed a booking reliably.
There is a second-order problem underneath that, and it is the one that will decide how this settles. Travel search has always been rationed by a human being having to sit down and click. An agent has no such limit: it does not tire, does not settle for good enough, and does not care what a query costs the system answering it. Every serious shopping agent makes the seller's search economics worse, and the rational response to that is to meter, throttle or charge for the looking.
So the buyer's agent degrades the seller's economics, and the seller's fix is to restrict the buyer's agent. That is not an arms race. One side has a model and a meter. The other has a chat window.
What to build instead
None of this argues for pretending the old world still exists. It argues for treating a price as what it now is.
- Store the offer, not the number. An amount with no inputs, timestamp and expiry is not a record of anything.
- Make expiry explicit in your API. A price without a TTL is a lie your own client will believe.
- Revalidate before commit, always. The gap between shown and charged is now the product.
- Test behaviour, not amounts. Assert that a stale offer is rejected, not that a fare equals a fixture.
- Log what the customer saw. When the record and the display disagree, the display is the promise you made.
The industry spent forty years building on the assumption that a price was a fact you could look up. It is becoming a claim generated for one person at one moment, and the only durable version of it is the copy you kept.
Source
- FTC Surveillance Pricing Study Indicates Wide Range of Personal Data Used to Set Individualized Consumer Prices, Federal Trade Commission, 17 January 2025
- Generative AI 'Super Analyst' May Change How Airlines Set Prices, Aviation Week, 7 January 2025
- Is the Airline Industry Ready for Agent-Led Bookings?, Bain and Company, 16 March 2026
- Maryland Enacts a First-of-its-Kind Surveillance Pricing Law, IAPP, May 2026
- Dynamic Pricing in the Crosshairs: California Launches Sweep; New York's Algorithmic Pricing Disclosure in Effect, Lowenstein Sandler, 2026
