Wondr

Inspiration

Whether you just arrived in a city or have lived there for years, planning a day out can take longer than the day itself. Between review tabs, map pins, and group chats, most people give up and end up at the same few places. Visitors don’t know what’s worth their time, and locals get stuck in routines and never see what’s a few neighborhoods away. We wanted to hand all of that work to an agent: you say when you’re free and what you’re in the mood for, and it takes care of the rest. Not knowing where you’re going also turns out to be fun, so we made the surprise part of the product.

What it does

• Researches real places and events near you, using live web search, Google Places, and each venue's own website • Checks opening hours, dates, and addresses, and only keeps stops it can back with a source that fit inside your time window • Narrates its work live while it plans ("Checking dates, addresses, and opening hours…") • Adds each stop to your Google Calendar as "WONDR · Mystery stop 1, 2, 3", with the time and a dress code but not the place. Friends on the plan get the invite too • Keeps each stop locked until it's time to reveal it, then shows the name, address, directions, and what to do there

How we built it

• Agent: runs on Omnara, which hosts the model and the agent loop. Our tools run server-side on Vercel: search_events and search_places (Exa and Google Places), fetch_page (reads the venue's own page to verify hours and details), and save_plan. • Guardrails in code, not just in the prompt: every plan is validated with zod before it's saved. Stops must fall inside the user's window, carry a real source URL, and not overlap, and every time is stored as ISO 8601 with a timezone offset. A malformed plan never reaches the screen. • App: Next.js and TypeScript on Vercel, with Supabase for Google sign-in, Postgres, and the plans table. The browser creates a plan row, the API claims it atomically (so a double click can't launch two paid agent runs), answers immediately, and the agent keeps working in the background while it streams progress into that row. • Personalization: a three-step onboarding saves your taste to your profile, and it's merged into every plan the agent makes: loves become interests, hard passes become exclusions, and diet, budget, energy, and travel distance become constraints. • Calendar: Google Calendar API with an offline refresh token, captured at sign-in and stored encrypted with AES-256-GCM. Events are tagged with hidden plan IDs, so re-runs never create duplicates. • Bookings: a tiered pipeline (prefilled booking links, email requests through Resend, walk-in swap as the fallback) with consent gating, a spend cap, idempotency, and a dry-run mode, ready to plug into the agent.

Challenges we ran into

• Hallucinated venues. Language models happily invent places that sound real. We made every stop come from a tool result, checked it against its source page, and preferred three verified stops over six invented ones. • Long agent runs on serverless. A thorough plan takes minutes, but web requests want to finish in seconds. The API answers right away, the agent runs after the response within a time budget below Vercel's limit, and progress lives in the database, so the page never waits on a single request. • Google gives you the calendar refresh token only once, at the moment of sign-in. Missing that moment means no calendar at all, so we capture and encrypt it in the auth callback. • Two teammates building the agent in parallel. We converged on one written contract (shared types plus the plans table), which let Omnara's agent drop into the app without changing the UI. • Timezones. A day planner that mixes local and UTC times breaks quietly, especially on a daylight-saving weekend like this one. Every stored time carries its offset, and we test across the switch.

Accomplishments that we're proud of

• An agent that does real things, not just generates text: it searches the live web, verifies places against their own pages, and writes to your real Google Calendar. • It's live on the internet right now, with Google sign-in and onboarding that remembers you, and anyone can try it. • Guardrails that hold: plans are validated in code before they reach the screen, and fallbacks are designed in at every step. In our tests, a booking that fails becomes a walk-in venue swap instead of a broken plan. • The secret stays secret: the mystery stops sit in your calendar without giving the place away.

What we learned

• Agents get reliable when the code around them is strict. A clear contract and validation did more for plan quality than prompt tweaks did. • Make long work asynchronous from the start: a database row plus a status field beats holding a request open. • OAuth is where hackathon time goes. Scopes, refresh tokens, redirect URLs, test users, and publishing all have to line up, and it's worth setting up in the first hour. • Agree on the contract early. Our two agent builds came together fast because both sides spoke the same types. • "Surprise" is a real product feature: people liked not knowing more than we expected.

What's next for Wondr

Turn on bookings in the live agent: deep links and email requests first, then a sandboxed browser agent and voice calls for phone-only venues. • Reveals on a timer plus a fast-forward demo mode, with the calendar event updating itself at each reveal (the server side is already built). • Re-plan mid-day: "running late", "skip this", "swap it". • Group days: friends join by link and their preferences merge into the plan. • Ratings and reviews from Google Maps to rank places, plus more cities and a shareable recap of the day.

Built With

• exa
• google-calendar-api
• google-oauth
• google-places
• next.js
• node.js
• omnara
• postgresql-(sql)
• react
• resend
• supabase
• tailwind-css
• typescript
• vercel
• zod