Inspiration
The idea for TripSentry came from my trip to Japan. I was using Gemini as my guide and it was honestly great for setting everything up. The issue showed up when I needed immediate advice on the go.
There was a moment where I missed a train and needed a quick alternative right away. I had to stand there and re-explain my whole itinerary to the AI because it had lost the context of what I had already finished and where I needed to be next. It slowed me down when I needed it to be fast. We built TripSentry to solve that specific problem so the AI always knows exactly where you are in the plan.
What it does
TripSentry is an autonomous "Marathon Agent" that protects travel plans from chaos. Unlike a passive itinerary app, it actively monitors the gap between Intent (the plan) and Reality (delays, weather, fatigue).
It manages three priority states to keep the trip successful:
- The Guardian: The "Sentry" acts as a smoke detector for external threats (like rain or train delays) via
reality_simulation. It proactively calculates new routes to prevent failure. - The Optimizer: If a gap opens up in the schedule, the Sentry acts as a vacuum detector, scanning the Itinerary Debt (backlog) to re-insert missed items so a temporary delay doesn't become a permanent loss.
- The Concierge: A guided discovery mode where the user can actively shop for options, mixing backlog items with fresh search results.
How we built it
We moved beyond the standard stateless chat paradigm to build a persistent, stateful architecture using Gemini 1.5 Pro and Gemini 3.
- Stateful Orchestration: We dump the user's entire unstructured research into the 1M token window, allowing the agent to optimize for the user's specific definition of a "Good Trip."
- The Agents: We split the logic into specialized roles. We use High Thinking for The Solver (crisis management and database transactions) and Low Thinking for The Concierge (exploration and chat latency).
- Visual Verification: We built The Scout, which allows users to point their camera at a sign (e.g., "Closed for Renovation") to update the
reality_simulationand trigger the Sentry loop.
Challenges we faced
The biggest hurdle was giving the agent true Agency without causing "Logistics Panic."
We had to ensure that when the Sentry detected a conflict, it didn't just hallucinate a fix. We implemented a "Bridge Pattern"—a native grounding layer that verifies real-world availability before the Solver suggests an option.
We also had to solve for Trust. Users need to know why the AI moved their dinner reservation. We leveraged Gemini 3's Thought Signatures to display the agent's raw reasoning in a "Logic Console" on the UI. This proves to the user that the model is maintaining its reasoning state across multi-step tool calls.
What we learned
Building TripSentry taught us that the future of AI isn't just in answering questions, but in managing lifecycles. By treating the itinerary as a living object rather than a static list, we learned how to build an agent that manages Itinerary Debt and maintains continuity across a multi-day "Marathon," effectively healing the schedule when the world tries to break it.
Built With
- gemini
- supabase
- vue
Log in or sign up for Devpost to join the conversation.