This is how you book a flight today. You open Skyscanner or Google Flights, put in some dates, scroll past twenty options, open four tabs, weigh layover times against baggage fees, decide you would actually rather fly from a different airport, and half an hour later you book something you hope was the best choice.
This is how it will go. You tell your assistant: book me a flight to Lisbon on Tuesday morning, no connections, landing before ten, use my Flying Blue number. Twenty seconds later you get one proposal with the reasoning attached. You say yes.
That difference looks small. It is the biggest thing happening to websites in the next few years.
What actually shifts
In the first case, you do the comparing. The website has to convince you, so it is built to convince you: good photography, reassuring design, a button that stands out, a note that only two seats are left.
In the second case an agent does the comparing, and it works differently. It acts as an orchestrator: it spins up specialised sub-agents to solve individual pieces, say finding the best hotel, checking it against your loyalty points and verifying the cancellation policy, then combines those results into a single answer. All you do is confirm.
That agent is immune to your design. It does not see a scarcity banner and does not feel urgency. It wants to know what it costs, what the terms are, whether it is available, and whether it can complete the booking.
This is not about travel
The flight analogy is useful because everyone recognises it, but the mechanism is not specific to travel. Anywhere someone currently compares options before choosing, this is coming. Insurance. Suppliers. Professional services. Asking three companies for a quote.
When your customer tells an assistant “find three firms that can do this and request quotes”, the question is no longer whether your website looks good. The question is whether you make the list of three.
The uncomfortable part
Your website was almost certainly built to win a click. Twenty years of SEO practice is about ranking high enough that someone clicks, and then persuading that visitor once they arrive.
If there is no click, that model stops working. The awkward bit is that you will not watch it happen. When search traffic drops you see the numbers fall and you go investigate. With agents there is no signal. There is no line in your analytics saying an assistant considered you three times and ruled you out three times because your pricing was not readable anywhere. You simply notice nothing, and that is exactly the problem.
What an agent needs
The practical translation is less exotic than it sounds. Agents need three things, and you probably have two of them half sorted.
Structured data. Schema.org has been the standard for years for telling a machine what is on your page: this is a product, this is the price, this is availability, this is a service with these properties. For search engines that was useful. For agents it becomes the foundation.
Current information. A 2024 price list inside a PDF is annoying for a human and worthless to an agent. Anything you want taken into account has to be correct and machine-readable.
A way to do something, not just read something. This is the big one. In travel it is now said plainly that companies have to become API companies. That applies far beyond travel. If an agent can only read at your site while it can book, request or reserve at your competitor’s, you know how that ends.
The standards taking shape
Several parties are building the plumbing right now. MCP servers for search and shopping. WebMCP and Cloudflare Markdown as protocols for agent browsers. Google is working on UCP, a universal commerce protocol, which has not been adapted to travel yet but almost certainly will be. And underneath all of it sits plain Schema.org.
Nobody knows which of these is the standard in three years. That is not a reason to wait, because there is a layer underneath that does not change: your data has to be correct, structured and retrievable from outside. That work is never wasted money, whichever protocol wins.
What we would do now
No large programme, no bet on a single technology:
- Get your structured data right. It costs little, already helps with ordinary search engines today, and is the base for everything that follows.
- Look at what an agent actually sees on your site. Not what you see in your browser. Fetch your own pages the way a machine does and check whether prices, terms and availability are in there, or only inside an image or a script.
- Make your key data retrievable. Start small: one endpoint with your services, rates or availability. You do not have to open up your whole business to count.
- Experiment with one agent protocol. Stand up an MCP server for a bounded part of your offering and see what happens. That is a week of work, not a quarterly project.
Why now and not next year
Because this work is cheap while it is small, and expensive the moment you have to do it under pressure because a competitor already has.
And because falling behind here is invisible. You get no warning. You see no decline. You just get proposed less and less often, by assistants your customers have come to trust, and by the time it shows up in revenue you are a year behind.
Where do you stand?
In forty-five minutes we will look at your site the way an agent would and tell you what is readable and what is not. No pitch about the future, just what is there now and what we would tackle first.
Book a 45-minute call or email contact@3bird.nl.
