Search just grew hands.
Google’s AI Mode picked up a set of travel tools this week: flight price tracking, award space searching with mile rates, and hotel booking. TechCrunch, 9to5Google, Search Engine Roundtable, and Live and Let’s Fly all covered it, and Google’s own blog framed it as three new ways to plan and book travel in Search.
On the surface, that reads like a product update. If you build bots for a living, it’s something else. It’s a reference implementation for the pattern most of us have been prototyping in private repos for the last two years.
The line between answering and acting
Every chatbot I’ve shipped eventually hits the same wall. The model can explain something beautifully, then falls flat the moment a user says “okay, do it.” Explaining is stateless. Acting is not.
Look at what these three features actually require underneath:
- Flight price tracking means persistent state. Something has to remember a user’s route and dates after the conversation ends, poll for changes, and reach back out. That’s not a prompt. That’s a scheduler, a datastore, and a notification channel.
- Award space and mile rates means messy, fragmented data sources. Award availability isn’t a clean public API. Anyone who has tried to normalize loyalty program data knows the shape of that pain.
- Hotel booking means write operations. Money moves. Confirmations exist. Mistakes cost real dollars and can’t be fixed with a “sorry, let me try again.”
Those three sit at increasing levels of difficulty, and that ordering isn’t accidental. It’s roughly the maturity ladder for any agent you’re building.
What this tells you about your own architecture
I’ve been rebuilding one of my own assistants around this idea, and the Google news mostly confirmed the direction. A few things I’d argue are non-negotiable once your bot starts doing things instead of just saying things.
Separate the conversation loop from the work loop
Price tracking is the clearest example. The user’s chat session is ephemeral; the tracking job is not. If you’re storing tracked items in conversation memory, you’ve built a feature that dies the moment someone closes the tab. Put the job in a real queue with its own lifecycle, and let the chat interface be one of several ways to inspect it.
Treat every write as a two-phase commit with a human in the middle
Booking a hotel is the kind of action where a confidently wrong model becomes expensive. My rule: the agent assembles a complete, structured proposal, renders it back in plain language, and waits. No implicit confirmations. No “I’ll assume you meant the cheaper one.” The model’s job is to get the user to a decision point, not past it.
Wrap flaky data sources in your own contract
Award availability and mile rates come from sources that change format, rate-limit unpredictably, and occasionally lie. Don’t let that variability reach your model. Put an adapter layer in front of each source that either returns clean typed data or returns a clear failure. A tool that sometimes returns garbage teaches your agent to hallucinate around it.
The uncomfortable part
There’s a competitive read here too, and I’d rather say it than dance around it. A lot of independent bot projects are thin wrappers over a model plus a couple of API calls. Travel planning assistants were a popular category for exactly that reason: the data is public-ish, the value prop is easy to explain, and the demo looks great.
Google shipping this natively into Search compresses that category hard. Not because Google’s version is necessarily better, but because it’s where people already are. Distribution beats a clever prompt almost every time.
The opening that stays open is depth. Google is building for the median traveler. The award space feature is interesting precisely because it hints at how far the general-purpose version can go before it stops making sense — loyalty optimization is a rabbit hole with an obsessive, underserved audience, and general tools rarely go deep enough for them. Same story in a dozen other niches. If your bot knows one domain absurdly well, holds state that matters to a specific type of user, and integrates with tools a general assistant will never bother wiring up, you’re not competing with this. You’re building on the assumption it normalizes.
What I’d build this week
Pick one action your assistant currently only talks about. Give it persistent state, an approval step, and a typed adapter to whatever data it needs. Ship that one thing properly instead of five things halfway.
The interesting work in bots stopped being conversation quality a while ago. It’s reliability under real-world side effects now, and that’s a much harder, much more useful problem.
🕒 Published: