Two months out from a trip, you've got open browser tabs from a flight search you started Tuesday, a booking confirmation buried in your inbox, a Google Doc the friend you're traveling with started, a Notes app entry from when you were on the train, and a screenshot of a hotel review you took on your phone. None of them know about each other. By the time you actually need any of it — at the gate, at the front desk, at the rental counter — you're hunting through six places.
Trips, events, and moves all share the same shape: lots of small pieces of information, a hard date, several people involved, and dozens of decisions that need a record. A single vault per project, with the agent doing the searching, handles the whole arc.
One project, one parent page, child pages for every dimension
In Docapybara, the trip (or the wedding, or the move) gets a top-level page named for it: Italy 2026, October Wedding, Move to Portland. Pages nest indefinitely, OneNote-style, so the parent can have child pages for Bookings, Research, Itinerary, Packing, Budget, People, Day-of plan, and whatever else the project actually needs.
The agent treats the whole tree as one pile when you search. "What's the cancellation policy on the hotel in Florence?" gets answered from wherever you put it, not from where you'd guess. For longer trips with multiple legs, each city or stop can be its own child page underneath the parent.
Bookings — confirmations, reservation numbers, and the who-cancels-when
The Bookings page is the highest-stakes one and the one most likely to save you at a counter somewhere. Every flight, hotel, rental, tour, restaurant, and activity gets a row in an inline database via the :::database::: directive: vendor, type, date, confirmation number, cost, cancellation deadline, and notes.
Confirmation emails drop on the page as PDFs. Docapybara converts uploads to markdown via docstrange, so the agent can actually read them — "what's the check-in time for the Florence hotel and what did the email say about parking?" comes back with the answer and the source. No more digging through your inbox at the curb.
For multi-leg trips, the agent can build a chronological view: "List every booking in date order with confirmation numbers and cost." The output is the print-friendly itinerary that you can keep on your phone or text to whoever needs it.
Research — the places you considered, not just the ones you booked
Most trip planning involves looking at way more options than you'll ever pick. The Research page is where you keep the comparison work so you don't redo it next time.
For each destination, restaurant, vendor, or venue, a quick note: link, what looked good, what reviewers complained about, what it costs, why you ruled it in or out. The agent can summarize: "What were the three rental car companies I compared, and why did I pick the one I picked?" Useful three weeks later when your partner asks the same question.
For trips, the web_search tool inside the agent can pull current information. "Find current reviews of [restaurant name] in Florence — anything in the last six months." Comes back with sources. Saves the alt-tabbing. (If you're planning a trip with a lot of moving research, Documenting Travel Itineraries and Trip Research Without the Tab Sprawl goes deeper on the research-heavy version of this same shape.)
People — who's coming, who's helping, who needs to know
For trips with friends or family, weddings with a guest list, or moves with movers and helpers, People is its own page. Names, contact info, what they're doing, what they need from you. An inline database handles it well: name, role, contact, status (confirmed, waiting, declined), notes.
For weddings or events, the database scales to the full guest list — RSVP status, dietary restrictions, table assignment, plus-ones. The agent can pull subsets: "Who's confirmed with a vegetarian meal?" Comes back with the list. (The wedding-specific version of all of this is at Planning a Wedding (or Any Major Life Event) in One Vault.)
For moves, People is your moving company contact, your landlord on both ends, the building manager, the utility companies. When something goes wrong at 7 a.m. on moving day, the page is what you reach for.
Itinerary — the day-by-day, in one place
Once bookings are locked in, the Itinerary page is the day-by-day. One section per day, each with the morning/afternoon/evening blocks, the addresses, the phone numbers, the meeting points. For trips with anyone joining you partway through, this is what you share.
The agent can build it from the Bookings database: "Generate a day-by-day itinerary for the Italy trip, pulling from the bookings database. Include addresses and confirmation numbers." You get a clean printable. Copy-paste it into a message to whoever needs it, or keep it open on your phone.
For events, the same shape becomes the Day-of plan: 10 a.m. florist arrives, noon photographer arrives, 4 p.m. ceremony, reception logistics. The agent generates the run-of-show from your component pages.
Packing, budget, and the lists that nobody enjoys
A Packing page with categories (clothes, electronics, documents, toiletries) is straightforward but useful — especially when you reuse it across trips. Voice works well here. "Add to the packing list — sun hat, hiking shoes, the adapter for Italy." The agent updates the list.
For multi-trip travelers, keeping a Master packing list page that you fork for each trip saves rebuilding it from scratch. The agent can adapt: "Take the master packing list, give me the version for a 10-day trip to Italy in October." Comes back with the trip-specific cut.
The Budget page tracks what you've spent vs. what you'd planned. An inline database with category, planned, actual, and notes. The agent can pull the running total and the gap. "How much have I spent on the Italy trip so far, and how much over or under am I on each category?"
Decisions — what you picked and why, for next time
Every trip, event, and move makes you decide things you'll never decide again that exact way. But you'll decide similar things again. Decisions is the page that holds the reasoning so future-you doesn't redo it.
For each call — "why we picked this hotel over the cheaper one," "why we're driving instead of flying for this leg," "why we hired the moving company instead of doing it ourselves" — drop a few sentences. The agent can pull related decisions from past trips: "For previous Europe trips, what did I write about whether to buy a rail pass or book individual tickets?"
Over a few trips this becomes genuinely valuable. You're not researching the same questions from scratch each time. (The general shape of capturing decisions for later reuse is in Capture and Compare Options for Any Major Decision.)
Day-of, the close-out, and a starter shape
For trips and events specifically, the day-of page is what you actually open on the day. Phone numbers, addresses, the order of things, who's where. Stripped down. Print-friendly. Everything else stays in the deeper pages.
After the trip or event, a quick Retro note — what worked, what you'd do differently, what the surprise costs were, who was great, what to remember for next time. Five minutes. The next time you plan something similar, that retro is what makes the planning faster.
For any of these projects, this is what we'd suggest starting with:
- Project name — top-level parent
- Bookings — page + inline database
- Research — running notes per option
- People — contacts and roles
- Itinerary or Day-of plan — chronological
- Packing / Budget / Decisions — supporting pages
- Retro — five-minute close-out
That's it. The vault grows with the project, the agent does the searching, and you never lose the confirmation number again. For more on the broader "everything in one app" approach to life logistics, see Why Your Notes App Should Be the Same App for Work and Life.
Try Docapybara free — start the parent page for whatever's next on the calendar, and the planning has somewhere to live.