Tastewell

Choose venue programming pilots with inspectable Qloo cultural evidence.

Comment

Inspiration

Programming a weak weekday night involves more than asking a model for event ideas. An operator needs to compare a plausible artist shortlist across rooms, see why each candidate appeared, and separate cultural fit from booking facts such as fees, availability, licensing, and staffing. Tastewell explores whether Qloo's aggregate cultural signals can make that choice more informed and auditable. It is a technical pilot, not a claim of proven commercial impact.

What it does

  1. An operator enters one to ten venues, a concept, target audience, region, objective, and optionally up to five artist names or a venue CSV.
  2. Tastewell asks the operator to resolve ambiguous Qloo concept or artist matches. It then creates up to three artist-led pilot options, each with inspectable source rows, Qloo IDs, query context, and explicit unknowns.
  3. The same resolved artist IDs are ranked separately for each eligible venue. A changed-audience or changed-region scenario reranks those fixed IDs and shows ordinal movement without treating affinity values from different calls as one universal score.
  4. A bounded agent inspects the saved shortlist and venue facts. It can request at most one operator-confirmed Qloo scenario, propose a cited pilot, ask for a missing fact, or abstain. The operator records the actual pilot choice and can later add an aggregate outcome.
  5. Decisions, evidence, review actions, plans, and outcomes are saved. The operator can reopen a decision, export JSON, or replay a labeled snapshot. An instant illustrative example uses invented names and IDs and makes no Qloo call.

How we built it

The frontend is Next.js. FastAPI runs the decision jobs and bounded review; SQLite persists decision snapshots. The backend connects to the Qloo harness over MCP. find_tags resolves a concept, recommend discovers artists and an optional partner, describe resolves supplied artist names, and rank compares a fixed shortlist. The agent's tool access and output are validated against saved evidence, allowed actions, and a decision fingerprint. A model cannot silently choose or record the operator's pilot. The hosted demo uses Docker Compose and Caddy on AWS Lightsail with HTTPS and a shared demo gate.

Challenges and lessons

  • The word “jazz” can map to several Qloo tags. A visible human choice avoids silently grounding a decision in the wrong ID.
  • A rank is meaningful inside its query context. A region change can change the order of the same artists, but the raw affinities across calls are not a common performance or revenue score.
  • Qloo does not supply artist fees, booking availability, staffing, licensing, attendance, or sales forecasts. These remain operator checks, and the agent must identify them rather than invent them.
  • A public-browser synthetic Brooklyn jazz run produced three saved options and a cited agent recommendation. A separate Los Angeles scenario moved Braxton Cook from rank 2 to 3 and Jesse Boykins III from 3 to 2; Ibeyi stayed at 1. This verifies a working technical path, not the quality of a real booking decision.

What's next

Test the decision with venue operators, capture their pre-Tastewell choice, and learn whether evidence changes their shortlist. Add stronger operational constraints, recoverable accounts, measured capacity, and an outcome workflow before treating this as production software.

Share this project:

Updates

Submission history