Front of House

Every show draws a different crowd, yet bars stock the same. An agent that reads each lineup with Qloo's taste graph, retunes bars, specials, sponsor screens and playlist, then waits for your OK.

Comment

Inspiration

An amphitheater hosts a country show on Friday, a pop show on Saturday and a metal show on Tuesday. Three completely different crowds, yet the bars restock "as usual", the sponsor screens run the same loop and the pre-doors playlist is whatever played last night. Venue teams know crowds differ, but nobody has the time (or the data) to translate a lineup into concrete changes before doors.

An LLM on its own can only stereotype ("country → beer"). Qloo knows how this lineup's fans actually rank real brands, food, places and artists. That turns "every crowd is different" into numbers a bar lead can act on.

What it does

Front of House is an operations agent for live-music venues. For each night it reads the lineup with the Qloo taste graph and tells every team what to change, then drafts one playbook per team and waits for the manager's OK before sending anything.

Try it with no sign-up (a demo venue is preloaded: the fictional Riverside Amphitheater in Austin, with real artists and brands):

  1. Week: six shows, each with a crowd shift meter that shows how differently tonight's crowd ranks the venue's menu compared with the season.
  2. Show brief:
    • The mix: the venue's whole menu as mixing-desk faders that move up or down against the season, each with a suggested par change.
    • Crowd profile: age and gender skew compared with the season.
    • Not on your menu yet: food concepts this crowd over-indexes on.
    • Sponsor rotation: who gets the pre-doors LED screens, the set break and the exit & lot screens.
    • Pre-doors playlist and local partners within 8 km.
    • Crowd map: where in the city this taste over-indexes.
  3. Run the week: one request ("Get the bars ready for this week. We can't sell spirits on the lawn.").
    • The agent scores every night and digs into the two biggest crowd shifts.
    • It drafts the playbooks and stops at an approval card. Nothing is sent until the manager approves.
  4. What the bar lead gets: a phone checklist per bar. House rules are venue data, so spirits changes never reach the lawn bars.
  5. Try any lineup: type any artists and read that crowd against the same venue.

How it's Qloo-powered

Every number in the app comes from a Qloo call (hackathon.api.qloo.com). Every section of the UI carries a chip naming the exact call behind it:

  • The mix: /v2/insights with filter.type=urn:entity:brand and filter.results.entities=<the venue's menu>.
    • We run it twice: once with tonight's lineup as the signal, once with the venue's last 24 headliners as the season baseline.
    • Ranking the same closed set in both calls lets us compare tonight with the season.
  • Crowd profile: filter.type=urn:demographics.
  • Menu gaps: filter.type=urn:tag with filter.tag.types=urn:tag:genre:place, keeping cuisines only.
  • Sponsor rotation: urn:entity:brand with filter.results.entities=<the venue's sponsors>.
  • Pre-doors playlist: urn:entity:artist, excluding the lineup.
  • Local partners: urn:entity:place with filter.location and filter.location.radius, restricted to hospitality categories.
  • Crowd map: urn:heatmap around the venue's city.
  • Entity resolution: /search matches the lineup, menu and sponsors to Qloo entities.

How we built it

  • Next.js 16 (App Router, Cache Components) and React 19, deployed on Vercel.
    • Qloo responses are parsed down to the fields we use and cached privately on the server ("use cache: remote"), as Qloo's terms allow. They are never committed to the repo.
    • The season baseline is computed once per venue and shared by every brief.
  • A deterministic brief engine (lib/brief) turns Qloo responses into the numbers. The agent never invents a number.
    • Taste index: the change in percentile position between tonight and the season, scaled to ±50.
    • Suggested par: half the index, until the venue's own sales calibrate it.
    • Crowd shift: 4 × the mean absolute index, capped at 100.
  • The agent is an AI SDK 7 ToolLoopAgent running on the Vercel AI Gateway.
    • Its tools wrap the brief engine (score_menu, crowd_profile, menu_gaps, rank_sponsors, local_partners, draft_playbook, send_playbooks). The model orchestrates and explains, and labels its own recommendations as judgement.
    • send_playbooks requires human approval (toolApproval: "user-approval"). Approvals are signed, so a client cannot forge the manager's OK.
    • It runs on a chain of free-tier models: Gemini 2.5 Flash, falling back to GPT-4.1 mini, GPT-5 mini, Kimi K2 and DeepSeek V3.1. Each model was checked to complete a tool-calling loop first.
  • Design: a dark "mixing desk" built for people working at night. Amber means up, blue means down. It is WCAG-checked with axe and has no horizontal scroll at phone width.
  • Tests: 45 Vitest unit tests (brief engine, Qloo params, schemas, playbook rules, model chain) and 18 Playwright end-to-end tests. The Playwright suite covers the judge path, an axe accessibility check and the phone layout.

Challenges we ran into

  • Comparing scores across calls. Qloo normalises affinity per query, so two calls can't be compared directly. Restricting both calls to the venue's own closed set (filter.results.entities) and comparing rank positions made "tonight vs the season" meaningful.
  • Real data is messy.
    • Place tags included campus Greek houses, so partners are filtered to hospitality categories.
    • Generic place genres showed up as "menu gaps", so only cuisines are kept.
    • One planned menu brand isn't a Qloo entity, so the demo menu uses one that is.
  • Rate limits on both sides.
    • Qloo's hackathon key allows 10 requests per second, so calls share a process-wide throttle with exponential backoff.
    • The AI Gateway free tier allows about 5 requests per minute per model, so the agent batches independent tools into one step and fails over across models.
  • Failing gracefully. If one Qloo section fails, it renders empty instead of breaking the brief. A degraded brief is cached for minutes, not days, and missing data is never turned into numbers.

Accomplishments that we're proud of

  • A complete product rather than a proof of concept: week, brief, agent, approval, phone checklist and an open "try any lineup" mode, all on live Qloo data.
  • The human stays in charge. The agent can't send anything without the manager's signed approval.
  • The agent and the UI agree because they read the same deterministic numbers. The model explains the numbers but never produces them.

What we learned

  • Taste data is most useful when it is turned into operational decisions (par levels, screens, specials) rather than recommendations to consumers.
  • A closed-set ranking beats raw affinity scores for any "this versus that" question.
  • An agent is more trustworthy when it orchestrates tools and has to ask for approval than when it writes free-form advice.

Why it matters

  • Live Nation hosted 65M fans at its venues in 2025. Onsite spending at its amphitheaters rose 6%, led by beverage, and non-alcoholic spend per fan rose 20% (YTD Oct 2025).
  • Crowds change every night, and so does what they buy. Front of House turns taste data into a per-night playbook for the people who actually change the stock.

Sources:

Limitations

  • The taste index is relative affinity, not a sales forecast. Demographics are relative skews, not headcounts.
  • The venue, its menu and its sponsors are a demo. The artists and brands are real Qloo entities.
  • Only lineups, a venue location and a product list are sent to Qloo, never information about people.

What's next for Front of House

  • Calibrate suggested pars with each venue's POS sales after the show.
  • An MCP endpoint so a venue's existing assistant can ask Front of House directly.
  • Comedy and sports nights.

Built With

Share this project:

Updates

Submission history