Planning a Family Trip With Claude
Share on LinkedInI used Claude to plan a family trip to Salt Lake City built around a Zach Bryan show. Four of us, five days, one rental car for exactly one of them.
The output was a single printable itinerary. That part is unremarkable, and it’s not why I’m writing this.
What’s worth writing about is where the value actually came from, which was not raw capability. It was knowing which questions to go answer and which ones to leave alone.
Trip planning has a specific and expensive failure mode: confident fabrication. A restaurant that closed last year. A walk that’s further than it sounds. A forecast invented because a number was expected. You don’t discover any of it until you’re standing on a sidewalk in the heat with your family, and by then the afternoon is gone.
The interesting part is that avoiding all that didn’t make the plan more cautious. It made it better, because the same discipline that kills a bad recommendation is what surfaces a good one.
Start from documents, not from memory
I had three PDFs sitting in a folder: flight confirmation, hotel confirmation, concert tickets. The first instruction was to read those and build an itinerary from them.
That framing matters more than it seems. Every hard fact in the final document came from a file I already had, not from anything the model knew about airlines or hotels in general. Flight numbers, check-in dates, seat assignments, the confirmation codes. Nothing was recalled. Everything was read.
Grounding in source documents removes the biggest category of error. It does not remove all of it, and the way it fails is worth understanding.
Our seat assignment in the itinerary was wrong. Not because Claude misread the ticket, it read the PDF correctly, but because our seats had been moved after that PDF was issued. The document was accurate and stale at the same time. No amount of careful reading catches that. The only person in the loop who could know was me.
That’s the real limit of grounding. It anchors you to your sources, which is exactly what you want, and it inherits whatever those sources get wrong. Worth remembering before trusting any document-derived output without a look.
Research live, because the world changes
The second principle: anything that could have changed got looked up rather than recalled. Hours, closures, event schedules, transit construction. Training data has a cutoff, and a museum’s operating status is exactly the sort of fact that quietly goes stale.
The clearest example is a science museum I’d have happily put on the list. Before recommending it, Claude checked, and found it had permanently closed the previous autumn over building problems. So it never made the itinerary.
The part I appreciated more: the closure got written into the project’s memory file, not just left in the conversation. A fact that expensive to rediscover shouldn’t have to be rediscovered. That’s the difference between catching an error and actually retiring it.
What that research turned up
Verification is the defensive half. The same habit of looking things up rather than recalling them also produced the two best ideas in the trip, neither of which came from me.
The first is our whole Thursday. Claude suggested the Olympic Park up in Park City, which I wouldn’t have thought of, and then did something better than suggest it: it built the day around the heat. Outdoor activities bracketed by the two free indoor museums on site, so there’s an air conditioned break in the middle instead of six straight hours in the sun. The recommendation and the constraint arrived together.
The second saved us a genuine headache. I’d assumed driving to the concert and dealing with stadium parking. Claude found that the city runs a program where your event ticket doubles as free same day transit fare, so the light rail ride to the stadium and back costs nothing and skips parking entirely. Then it checked whether construction that year affected the relevant rail line (it didn’t) and looked at how the transit authority had handled service for past big shows at the same venue.
That is not a fact I knew to go looking for. It’s local, specific, and slightly obscure, which is exactly the shape of thing worth researching rather than guessing at.
The correction that mattered most
Claude drafted a recommendation for a well-known Mexican restaurant, framed as an easy option near the hotel.
Then it kept researching, found the place is somewhere between one and one and a third miles away with real wait times, and pulled its own recommendation before I ever acted on it. Substituted somewhere closer instead.
On paper that’s a small edit. In practice it’s the whole game. Temperatures were forecast above 100 degrees. “Easy walk near the hotel” and “1.3 miles each way plus a wait, in triple digit heat, with four people” are not the same plan, and the gap between them is the kind of thing you only find out the hard way. The error would have been completely invisible right up until it wasn’t.
The refusal
The one I keep thinking about is the weather.
I’d told Claude it was going to be over 100 degrees that week. It tried to verify that independently, went out to a couple of forecast sources, and got stale or broken results. So it said so plainly: it could not confirm a forecast on its own, and it was going to plan against my firsthand report instead.
It would have been trivially easy to produce a number there. Something plausible, appropriately hot, formatted with a degree symbol, and completely unsourced. I’d probably never have questioned it.
An unverified number delivered confidently is worse than no number, because it removes the prompt to go check. The heat plan we ended up with (outdoor things early and late, indoor and air conditioned between about 11 and 4) didn’t need a precise forecast to be correct. It needed an honest input.
Corrections have to land everywhere
The itinerary lived in three places at once: a working HTML file, a persistent artifact I could open anytime, and a structured memory file holding the underlying facts.
When something changed, and things changed constantly, it had to change in all three. Wrong seat numbers, revised rental car pickup window, a restaurant swap I decided on myself late in the process. A correction that only lands in the chat reply isn’t a correction, it’s a note that will be contradicted by the document the next time anyone opens it.
I wrote about the same pattern from a different angle when I ran a softball season this way. The lesson keeps repeating: the artifact is the thing people actually use, so the artifact is the thing that has to be right.
The deliverable
The end product is one self contained HTML file with no external dependencies. Quick facts at the top, then flights, hotel, concert logistics, and a day by day breakdown with optional extras marked for the days we had no car.
Two details I liked. I asked for every cost and budget figure to be stripped out, and rather than just deleting the obvious budget section, Claude searched the file afterward to confirm no stray dollar figures survived elsewhere. Then I said I wanted to print it, and it added a print stylesheet, page break control, background handling, margins, so the thing actually comes out of a printer looking like a document instead of a web page.
Nobody in my family will ever know or care that there’s a @media print block in there. They’ll just know the itinerary printed correctly.
What I’d take from it
For anything logistical, calibration matters more than capability.
A tool that produces a beautiful itinerary and is confidently wrong about one closed museum has cost you more than it saved. A tool that says “I couldn’t verify this, here’s what I’m assuming instead” lets you decide where to spend your own attention. The second one is far more useful and reads as far less impressive, which is probably why so much AI output is tuned to sound like the first.
The same instinct runs both directions. Checking before asserting is what caught the closure and retracted the restaurant, and it’s also what turned up a transit program I didn’t know existed. Restraint and initiative aren’t opposites here. They’re the same habit.
Ask where each fact came from. The good answer is a document you provided or a page it just read. The bad answer is silence.