Inspiration
It came from a genuinely annoying moment: planning a trip a few days out, opening a dozen browser tabs for flights, hotels, weather, and still checking a calendar separately to see if the dates even worked. Nothing about it was hard. All of it was tedious, and most "AI assistant" tools we'd tried just talked about what to do instead of doing it.
We wanted to build something that actually closes that gap. The name, Shundo, comes from the Japanese word 旬 (shun), the exact moment something is at its peak and ready. That became the whole premise: give it a goal in one sentence, and it finds the right real action for that moment, not a suggestion, an actual execution against real tools.
What it does
Shundo takes a plain-language goal and runs it through three cooperating agents built on LangGraph:
- A Planner that decides which tools a goal actually needs
- An Executor that calls those tools for real, in parallel where possible
- A Critic that rechecks the result against fresh, live data before calling anything finished
If the Critic finds a problem, like a scheduling conflict, it sends the goal back to the Planner and the loop runs again. We proved this during testing: we deliberately booked a conflicting calendar slot, and watched the Critic catch it, send it back, and get a corrected result on the second pass.
It has eleven real tools behind it: Google Calendar, Gmail drafts, live flight and hotel search, restaurant and attraction lookup, general web search, weather, currency conversion, task tracking, budget logging, and PDF document parsing. Every visitor gets their own isolated session, and anyone who signs in with Google gets their own real calendar connected, not a shared demo account.
How we built it
The backend is Python and FastAPI, with LangGraph handling the Planner, Executor, and Critic as a real state graph with a conditional edge that can loop back on failure. The LLM layer is swappable between NVIDIA NIM, OpenRouter, and Hugging Face through a single environment variable, since free-tier availability shifted more than once during the build. Every step of a run streams to the frontend live over a WebSocket, so the interface shows the agent thinking instead of a spinner followed by a wall of text.
The frontend is React with Vite, with a full set of real pages: a landing page, login, a dashboard for running goals, and dedicated pages for calendar, tasks, budget, document upload, and profile. We spent real time on the visual identity too, landing on a glassmorphic design with an animated interactive cursor trail and a custom loading screen, since we wanted it to feel like a finished product rather than a hackathon prototype.
Deployment is Render for the backend and Cloudflare Pages for the frontend, both on free tiers, connected to a shared GitHub repo across our team.
Challenges we ran into
Getting real, live flight and hotel pricing turned out to be a genuine wall. We tried Amadeus, OAG, and a couple of other aviation APIs, and each one either gated real fares behind a commercial account or only offered flight status data with no pricing at all. We ended up building a search-based fallback that pulls real web results and has the LLM extract structured pricing from them, which works well most of the time and is honest about being an approximation rather than a live fares feed.
Free-tier LLM inference was the other recurring fight. Response times swung anywhere from a few seconds to a few minutes depending on which provider was under load at that moment, so we built in the ability to swap providers with one environment variable and kept a couple of fallback models ready.
We also hit a real cross-domain session bug late in the build: our frontend and backend live on different domains, and modern browsers quietly block or expire cookies set across domains like that. Sign-in kept randomly reverting to guest mode until we tracked it down and switched to a token-based session stored by the frontend instead of relying on cookies at all.
What we learned
That a multi-agent system is only as convincing as the moment it visibly corrects itself. The single most important thing we built wasn't a tool or a UI polish, it was making sure the Critic's real conflict-catching loop was rock solid, because that's the difference between "a chatbot with extra steps" and something that actually earns trust.
We also learned to be upfront about what's genuinely live versus approximated. Being honest about the travel pricing limitation, instead of hiding it, made the rest of the project feel more credible, not less.
What's next
Real per-user verification with Google so the app can move past the "unverified app" warning screen, and a proper fares API integration once one is within reach for a project at this stage. We'd also like to build out true multi-tenant calendar support so a group of people can use Shundo together without any shared state at all.
Built With
- canvas-api
- cloudflare-pages
- css
- fastapi
- github
- gmail-api
- google-calendar-api
- google-oauth-2.0
- html
- hugging-face
- javascript
- langchain
- langgraph
- nvidia-nim
- open-meteo
- openrouter
- openstreetmap
- pydantic
- pypdf
- python
- react
- react-router
- render
- serper-api
- sqlite
- vite
- websockets
- wrangler
Log in or sign up for Devpost to join the conversation.