Side Quest

Website landing page
Login Screen
Side Quest System Architecture

Inspiration

Most AI tools want to make adults more productive. Side Quest is built on the opposite assumption - that most adults are over-optimized and under-adventured.

The seed insight came from one of our test paragraphs: "Job's fine. Marriage is fine. The house is fine. I have been 'fine' for about three years, and I don't have a good word for what that's costing me." If you've ever written a week off as "the same week as last week," this is for you.

The other inspiration was an honest read of where multi-agent AI products are in 2026. Most are panels of LLMs reacting to one input - indistinguishable from a single model with four system prompts. We wanted to build something where the multi-agent architecture wasn't decorative.

What we built

Side Quest is a weekly adventure. You describe your life once. Four specialist AI agents pitch one small quest each - in different domains:

Social - one specific person, one specific action
Creative - a tiny finished thing made in one sitting, for nobody
Physical - going somewhere with your body, transit edges, and public infrastructure
Generous - anonymous acts where the recipient never learns it was you

You pick one. Next week, you come back and report what happened. A fifth agent - the Logbook - writes a two-sentence reflection into your growing Side Quest Log. Then four new quests, this time informed by what you just did.

Behind the scenes, one of the four pitcher agents runs each session in wildcard mode - pitching against your apparent preferences. The four quest cards in the UI look identical. You don't know which is the wildcard. That's the design.

How we built it

The app was scaffolded from a natural-language description in MeDo. From that description, MeDo generated a full-stack React + Vite + TypeScript frontend, a Supabase backend with magic-link email auth, six relational tables, and three edge functions that call Gemini 2.5 Flash.

From there, the work was almost entirely agent prompt engineering. Each of the five agents got a system prompt of ~80 lines specifying:

A voice doctrine (e.g. "the friend who texts you weird ideas at 11 pm," not chipper, not therapeutic)
A list of quests it refuses to pitch (e.g. "call your mom," LinkedIn-tier networking, "host a dinner party," anything from the wellness register)
A banned-vocabulary list (no "amazing," no "journey," no "intentional")
Concrete good/bad examples to anchor the voice

We then voice-tested each agent against a 20-paragraph corpus spanning ages (23–64), energy levels, life situations (new parents, retirees, shift workers, new immigrants, the recently bereaved), and urban/suburban/rural shapes. Our bar: 15 of 20 paragraphs must produce a quest a real person would screenshot to a friend.

Multi-turn iteration in MeDo's chat handled architecture changes, schema refinements, RBAC for the wildcard rotation, and bug fixes. Direct configuration of the agent system prompts was the high-frequency work.

Challenges we faced

Personalization is the opposite of what a rut needs. Our first design generated four quests that were each good fits for the user's stated life. The result: a polite, on-rails experience that gave users the average of their existing life back. The wildcard mechanic was the architectural fix. One of the four agents now reads the user's context and pitches against the grain - opposite social density, opposite creative medium, opposite space, opposite generosity direction. The user sees four cards; we never reveal which is the wildcard. The misalignment shows in the choice, not the writing.

The Generous agent's anonymity mechanism. Our v1 prompt said "the recipient does not learn it was the user." When tested, the agent drifted toward "drop something on the recipient's desk" - nominally anonymous, practically obvious. v2 added a hard rule: delivery service, mail-slot drop with recipient absent, or buried-inside-existing-object. Direct face-to-face hand-off is banned. The mechanism enforces anonymity; the user's intent alone wasn't enough.

The model wanted to "improve" our prompts. When asked to update agent prompts via MeDo's chat, the platform's instinct was to shorten them - strip the refusal lists, drop the examples, compress everything to one sentence. We had to use strict "do not modify, do not improve, keep at provided length" instructions to preserve the detail. The detail is the product. A two-sentence agent prompt produces generic two-sentence quests; an eighty-line agent prompt produces specific, defensible ones.

What we learned

The structural-multi-agent test: Can the load-bearing platform feature be removed without breaking the product? For Side Quest, no - the wildcard rotation requires real per-agent state isolation, the four agents must have distinct refusal lists, and the Logbook is a different role entirely. That removal test is the difference between using a multi-agent platform as a product feature and using it as scaffolding for a chatbot wrapper.

The other thing we learned: prompts are character design, not configuration. The Social agent is a person with taste. The Generous agent is a person who refuses performance. The Logbook is a quiet documentarian. Once we wrote them as characters rather than roles, the outputs became defensible against the entire category of generic AI-quest products that already exist.