Marquee — Project Story

Inspiration

Some people are naturally great at hosting events and bringing people together. The hard part usually is not the people — it is everything digital around the event. The second you decide to host something like a hackathon, you suddenly have to be a brand designer, a web developer, a Slack admin, and a sponsorship salesperson, all at once. That setup eats weeks before anyone even shows up.

We built Marquee because we kept seeing the same pattern: organizers who were excited about the room were drowning in the tooling around it. The integration work — keeping branding, registration, community channels, and outreach aligned — was the real job. We wanted a system that could hold that dependency graph so the human could focus on the people and the room.

You bring the room. Marquee builds everything that gets people into it.

What it does

Marquee is a stateful event-planning orchestrator. You describe your event in a chat conversation — like texting an assistant — and it builds the whole digital side:

Brand identity — logo lockup, palette, hero assets, and invite graphics
A live registration website — generated, deployed, and shareable
Community platforms — Slack workspace setup and Devpost draft configuration
Sponsor outreach — drafted emails ready for your review

The flow is deliberate: Marquee interviews you, writes everything into a structured Event Profile, pauses for your APPROVE, and only then fans out the build work in parallel. Reversible tasks run automatically; anything that touches money or real relationships stops for you. Drafts are produced; you send.

It is built for anyone running an event without a big team — whether it is your tenth or your first. Weeks of cross-platform coordination collapse into minutes.

How we built it

Marquee is a three-part system:

Layer	Stack	Role
Dashboard (`app/`)	React 18, TypeScript, Vite, Tailwind	Chat UI + live deliverable cards (Brand, Website, Outreach, Location)
Backend (`backend/`)	Python 3.11, FastAPI, Redis, FastMCP	Orchestration engine — interview loop, approval gates, integrations
Landing (`landing/`)	Static HTML	Marketing page with a direct link to the demo

Deployed stack:

Dashboard → Vercel
API + Redis → Railway
Generated registration sites → Vercel

Orchestration flow:

User chats (dashboard in Live mode, or Poke over SMS/iMessage)
Dispatcher runs a branched interview; each answer updates the Redis EventProfile
Consensus gate — summary posted, execution pauses for APPROVE
On approval, parallel pipelines run:
- Branding — OpenRouter image generation (with SVG fallbacks)
- Website — UI/UX Pro Max skill guides an OpenRouter coder that writes index.html, then deploys via the Vercel API
- Platforms — Slack API + Browserbase headless automation for Devpost
- Outreach — draft-only sponsor emails (Tier 3 — never auto-sent)
Handoff — live URL, credentials, and drafts surface in the dashboard; the event archives to a Past events menu

We instrumented the backend with OpenTelemetry → Arize so every orchestration span (interview, image gen, site build, deploy) is traceable. The dashboard polls /admin/traces for a live observability panel.

The frontend and backend communicate through a typed API seam (app/src/api/), with a Demo mode that runs a canned timeline for offline showcases and Live mode that talks to the real Railway backend.

Challenges we ran into

1. Orchestrating many fragile integrations in one run

A single event build touches image APIs, an LLM site coder, Vercel deploy, Slack, Browserbase, and optional Supabase — each with different failure modes. We built graded fallbacks (e.g. SVG stubs when image APIs fail) and made sure a failure in one vertical does not crash the whole run.

2. Site generation is non-deterministic

Asking an LLM to write a full registration site and deploy it is powerful but unpredictable. We constrained the problem with the UI/UX Pro Max design skill, a shared event-site template, and filesystem tool-calling so the coder writes into a known structure instead of inventing one from scratch every time.

3. External platforms change without warning

Headless automation against Devpost and similar sites breaks when their DOM changes. We designed for graceful degradation — the run continues, and the organizer gets a manual guide instead of a hard failure.

4. Calibrating autonomy

The product only works if organizers trust it. We tiered every task: Tier 1 (reversible, auto), Tier 2 (plan + deliverable review), Tier 3 (money/relationships — draft only). Getting the gate UX right — pausing at the right moments without making the loop feel dead — took real iteration.

5. Stateful async flows across chat surfaces

The interview can happen over Poke (SMS) while the dashboard mirrors progress in real time. Keeping Redis session state, MCP tool calls, and the React dashboard in sync across async exchanges was a significant wiring challenge.

Accomplishments that we're proud of

End-to-end event build from a single conversation — interview → approve → brand + site + Slack + outreach drafts, all from one thread
A real deployed stack — live dashboard on Vercel, API on Railway, generated sites that actually go live
Stake-calibrated autonomy — not "AI does everything," but "AI knows when not to act"
Observable orchestration — Arize traces across every integration span, visible in the dashboard
Built for the UC Berkeley AI Hackathon 2026 as our pilot — dogfooding the exact problem we are solving

If we frame the time savings simply: if manual setup is on the order of (T_{\text{manual}} \approx 2\text{–}4) weeks and Marquee compresses that to (T_{\text{marquee}} \approx) hours, the win is not just speed — it is removing the organizer as the human integration layer entirely.

What we learned

The hard part of event planning is integration, not any single task. Persistent state (Redis EventProfile) plus explicit approval gates matter more than any one model call.
Agents need boundaries. The most trustworthy systems are not the most autonomous — they are the ones that pause before irreversible actions.
Fallbacks are a feature. Production-grade orchestration means assuming APIs and third-party UIs will fail, and designing the run to continue anyway.
Observability is not optional when you chain generative calls. Arize tracing let us see which spans were slow, expensive, or failing — and prune accordingly.
Demo mode and Live mode serve different audiences. A canned timeline is essential for judges and offline showcases; Live mode is where the real product lives.

What's next for Marquee

Deeper Poke integration — full SMS-first flow so organizers never need to open a dashboard
Deliverable review loop — REVISE gate to re-run branding or site generation with amended inputs before handoff
Richer platform automation — more resilient Devpost/registration-form setup via Browserbase
Multi-event memory — organizers who run recurring events can pull from archived profiles in the Past events menu
Sponsor send flow — explicit Tier-3 approval UI for SEND / EDIT / SKIP on outreach, with audit trail
Expand beyond hackathons — conferences, summits, and community meetups with branching interview logic that skips irrelevant questions per event type