Busy Brain

The calendar that explains itself — and finds the time, the energy, and the place that actually work for you.

Comment

About BusyBrain

Inspiration

I'm a Computer Engineering student who runs on a busy schedule, which means a calendar that just tells me when something is happening has never been the problem. The problem is everything invisible around the event: the travel time, the study blocks I never schedule, the social plans that fall apart because nobody accounts for how drained everyone already is by 6pm.

What it does

BusyBrain is a multi-agent planning system that doesn't just place events on a calendar. It explains why it placed them there. Every study block, workout, and meal reminder comes with a real reason computed from my actual energy windows: "matches your high-energy window," or "your energy is only medium here, lower than ideal for this task." A dedicated "Today's Flow" view turns that same logic into a real energy chart for the day, with each task scored as a Peak Match, Energy Dip, or Steady fit against my actual schedule. It's not a decorative gauge, it's an honest computation. When I want to meet a friend, BusyBrain ranks shared time windows using real signals: calendar load, transition gaps, and how demanding the prior event was. It explains exactly why one slot beats another. It then searches the live web (via Browserbase) for a real nearby venue, pulling actual address, hours, and phone number from the venue's own site, with a layered fallback (fast fetch, then a full browser session, then an honest "nothing found") so it never fabricates details about a place that doesn't exist online the way you'd expect.

How I built it

The backbone is a multi-agent system on Fetch.ai's uAgents framework. An orchestrator fans a request out to three specialist agents (study, calendar, wellness) registered on the Almanac, each calling ASI:One's hosted LLM, with the orchestrator synthesizing their responses into one plan. On top of that sits a deterministic scheduling core: energy-window matching, focus-block splitting, drive-time buffers. That means the "why this time" explanations are literally the scoring logic that picked the slot, not an LLM guessing after the fact. The frontend started as a Claude Design mockup to nail the visual identity (a soft jellycat aesthetic) before any backend existed, then got rebuilt as plain HTML/JS talking to a real FastAPI layer. Same design, but every number on screen is now a real computation. For location intelligence, I integrated Browserbase across three of its primitives: search.web() to find candidate venues, fetch_api for fast page reads, and a Stagehand browser session as an automatic fallback when a site's bot protection blocks simple fetching. I also built real content-extraction logic that searches fetched pages for address, phone, and hours patterns and explicitly skips promotional banner text. That's the difference between a demo that looks impressive once and one that's actually reliable across a dozen different sites.

Challenges I ran into

A four-hour debugging chain that came down to one stray environment variable. A placeholder API key exported into a shell profile months earlier silently overrode the correct .env value, breaking ASI:One auth in a way that looked like a credentials problem but wasn't. Two of my four uAgents never registered an Agentverse mailbox, invisible until I checked each agent's dashboard individually. Real websites fight back. Early venue lookups returned bot checkpoint pages instead of content. I built a tiered fallback (cheap fetch, then full browser, then honest failure) and smarter extraction that scores sentences by whether they contain a real address, phone, or hours pattern, actively skipping promotional text that happened to load first. Pika MCP access was blocked for live video generation across every path I tried. The chat based MCP connection, the developer API signup, and the hackathon's dedicated Claude Code setup flow all hit account tier restrictions, with the final attempt blocked by an authentication issue before it could complete. I did successfully generate one video through Pika MCP using a licensed stock reference image, confirming the integration itself works end to end. The blocker was specifically live, in app generation access on my account tier, not the technical integration. Rather than fake a live connection that wasn't real, the app's invite flow honestly reflects this: it shows the real permission gating UI and a "sent to Pika" confirmation rather than claiming a video renders live in app.

What I learned

The redundancy critique was right, and fixing it taught the actual lesson: an agent earns its place by being accountable for its decisions, not just fast at making them. A static calendar app can place a block on a grid. Mine has to be able to say why, and mean it, even when that means admitting a feature didn't fully work.

Built With

Share this project:

Updates