🧭 Caravan
The agentic group trip planner. Caravan replaces the unpaid "trip mom" inside every group chat — the one person who DMs everyone for dates, aggregates them by hand, proposes destinations, absorbs 200 forwarded reels, and sends the reminders — with a team of purpose-built AI agents living inside a shared trip room.
One admin creates a trip and shares a code. Everyone else joins with Google, in about twenty seconds. The agents extract constraints from what people say, run the date math, force decisions to close, propose destinations with real reasoning, build the itinerary, and chase the stragglers — so the group chat converges on a plan instead of dying in a pile of "so are we doing this or not?"
Live Deployment: https://caravan.amitpile.com/
Table of contents
Why Caravan exists
Group trips don't fail because chats don't capture information — they capture plenty. They fail because a group chat has no mechanism to close a question. "Anyone free the 2nd week of Dec?" gets four replies, two jokes, and then dies. Three weeks later someone asks "so are we doing this or not?" and the cycle restarts. Meanwhile prices go up and the window closes.
Caravan's product thesis rests on three bets:
- Convergence, not note-taking. An agent that summarizes the chat is a toy. An agent that says "3 of 5 want Goa, Rhea's budget caps things at ₹15k so Nov 12–15 beats Dec 20–24, voting closes Friday 6pm, silence counts as a yes" is the organiser. Deadlines, quorum, and defaults-on-silence are the core mechanic — not the LLM.
- Private inputs, public consensus. People don't say "I can't afford ₹20k" in a group of eight. Every member gets a private 1:1 lane with the agent — budgets and hard constraints go in privately; only the aggregate ("the plan needs to land under ₹16k/head") ever surfaces publicly.
- The state is the product, chat is just the input. Dates, budget ceilings, the locked destination, the itinerary — these are real rows in a database with a lifecycle, not something buried thirty messages back.
- The system nudges before an admin has to. A decision locks the instant everyone's voted — no deadline required, no admin tap. The moment it locks, the next thing (itinerary, cost, checklist) generates on its own. If a vote stalls on 1-2 people, they get a private, specific nudge instead of the admin having to notice and DM them. If the group's been talking for a while, an agent recaps it and surfaces what's clearly emerging as an idea.
Screenshots
Every screen below is a render of docs/design/screens.html — the hi-fi design spec this app was built from, organized into the same seven flows (A–G) the spec itself uses. These are the design reference, not live-app screenshots — a few details have since diverged as the build evolved (invite codes are plain 6-character codes now, not hyphenated; joining is Google OAuth for everyone, not a name/email form; Your Trips gained avatar stacks and richer status styling; and several screens below — the destination page, the per-member facts page, settings' danger zone — were redesigned past what's pictured here). Cross-reference against Feature tour for what's actually implemented today.
A · Setting up a trip
B · Joining
C · Intake, in a thread with the agent
D · The room
E · The plan
F · Decisions
G · After the decision
Feature tour
Onboarding & identity
- Google OAuth for everyone — admin and members alike — via Supabase Auth. No name/email form, no separate guest-JWT system.
- Invite by code or link (
/join/[code]); if you're already signed in, clicking the link drops you straight into the lobby.
- Joining can be shut off mid-lobby without kicking anyone already in.
The room
- Shared group chat with a visually distinct agent lane (kickoff messages, decision lifecycle announcements, Scribe's "filed: ..." receipts).
- Threads — a private 1:1 lane per member with the agent (intake happens here; "ask the agent" questions land here too).
- Composer actions: paste a link → files it as an Idea; put something to a vote; ask the agent a plain-language question about costs/dates/who's said what.
- Realtime everywhere via a custom Supabase broadcast channel (not just
postgres_changes, which under RLS only ever reaches the trip's admin — see Architecture), with a polling safety net so nobody's screen can get permanently stuck.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
