TourTaste

Inspiration

Routing a tour is mostly guesswork for anyone without a big agency behind them. A promoter or a manager for a mid-size act picks cities from last year's sales and a hunch, books openers they happen to know, and pitches sponsors by cold email. A language model asked "where should this band play?" does the same guessing with more confidence.

Qloo already knows which cities, acts and brands share an audience. I wanted an agent that asks that question properly and shows its work, so a non-technical person can check the answer instead of trusting it.

What it does

You type an act and a short brief, for example "Khruangbin — six club dates in Germany and the UK, local openers and a drinks sponsor". TourTaste returns:

• Where to play: cities ranked by Qloo affinity with the act's audience, split fairly across the markets you named.
• Who opens: acts the same audience likes, below the headliner's tier.
• Who sponsors: brands that audience over-indexes on, inside the category the brief asked for.
• Where the audience already goes: places in the top two cities, for pre-show promotion.
• A written recommendation with cautions, and the full trace: each decision the agent made and each Qloo request with its result count and timing.

Try a comedian too ("Hannah Gadsby — theatre run in the US and Canada, no sponsors"). The agent switches entity type and drops the sponsor step.

What makes it Qloo-powered

Every name on the page comes from a Qloo query that uses the act as the signal. The language model is not allowed to cite anything Qloo did not return: names it invents are removed before the answer is shown. With the key removed the app has nothing to rank, and says so.

The agent does more than one lookup. It decides what to ask next from what came back:

1. Reads the brief into a plan (markets, number of cities, sponsor category).
2. Resolves the act with /search. Search is fuzzy, so it matches on the name, not on popularity, and retries as a person when no music artist fits.
3. Queries /v2/insights for destinations per market. It starts with the best-known cities and lowers the popularity floor only when a market comes back thin, and tells you when it did.
4. Looks up the sponsor category with /v2/tags ("drinks" → Qloo's Drinks brand category) and narrows the brand query with filter.tags. If the category is empty for this audience it falls back to all brands and says so.
5. Queries places for the top cities with the region attached, so "Canterbury" stays in England.
6. Writes the brief from those results only.

How I built it

A single Cloudflare Worker in TypeScript serves the page and one JSON endpoint. The Qloo client is a thin GET wrapper with the key held as a server-side secret. A small open model on Workers AI reads the brief and writes the summary. Workers KV keeps a daily usage ledger, run limits and a 24-hour cache, so the public demo cannot run up a bill and repeated requests are instant. If the model is unavailable the agent still runs with keyword rules and a templated summary over the same Qloo data. There are unit tests for the client, the guard and the agent's widening logic.

Challenges

• The first live results for "top destinations" were small resort towns. Taste affinity is not the same as "has venues", so the agent now prefers well-known cities and reports when it relaxes that.
• A two-country brief returned cities from one country only, because the higher-scoring market took every slot. Each market now gets its own share.
• Searching "Hannah Gadsby" also returns far more popular people. Picking the most popular hit planned a tour for the wrong person. Matching on the name fixed it.
• The model I use "thinks" out loud by default and spent its whole token allowance before answering. Turning that off made the brief parsing and the write-up work.

What I learned

The interesting part of a taste API is the second and third question. One affinity query gives a list. Deciding how to split it across markets, when to widen, and which category to look inside is where the agent earns its keep, and each of those choices is easy to explain to the user in a sentence.

What's next

• Venue-level suggestions once a city is chosen, and date clustering so the route makes geographic sense.
• Let the user pin or drop a city and re-plan around it.
• Compare two acts for a co-headline tour by intersecting their audiences.

Affinity describes aggregate audience taste. It is not a ticket forecast, and the page says so next to every recommendation.

Built With

• cloudflare-workers
• qloo
• typescript
• workers-ai
• workers-kv