Tourwise

An AI agent that plans a tour around where an artist's fans already are. It uses Qloo taste data to pick cities, venues, openers and sponsors, with evidence for every pick

Comment

Inspiration

Small bands usually plan tours by gut feeling: a city a friend mentioned, a venue from an old group chat, a sponsor nobody replied to. The cost of a wrong guess is brutal. You drive across the country to play to a nearly empty room while the fans you do have are in a city you skipped. Big acts have agents and data teams for this. Indie artists have a spreadsheet. We wanted to give them the same kind of answer from taste data: where are my listeners, which rooms do they go to, and who should open for me?

What it does

Tourwise plans a tour for any artist in four regions (North America, Europe, India, Australia & New Zealand). You search an artist from Qloo's catalog, pick a region and a number of stops, and press Plan tour. An AI agent then works through the plan step by step, and you watch each step happen:

  1. Map the audience. A Qloo heatmap over the region shows where people with this artist's taste are concentrated. Hot points are matched to real cities and scored.
  2. Read the audience. Qloo demographics and similar artists describe who the audience is, as aggregate taste signals.
  3. Scout each city. For each candidate city, Qloo finds music venues whose crowd matches the audience, artists the same fans like nearby (support acts), and brands they like there (sponsors).
  4. Route the tour. Stops are put in the order with the shortest total travel.
  5. Show the evidence. The final plan is a gig poster: each stop lists its venue, opener and sponsor brands, plus the Qloo signals behind those picks. It also lists strong cities it left off and why, and the limits of the data.

Plans are saved and shareable by link, so opening a saved plan is instant.

How we built it

  • Next.js 16 app on Vercel, with the agent built on the Vercel AI SDK (ToolLoopAgent). The agent has five tools: audience_hotspots, audience_profile, scout_city, plan_route and submit_plan. The final plan is a Zod-checked tool call, so the UI renders typed data, not free text.
  • Qloo Insights API for everything about taste: /search for artists, plus /v2/insights with urn:heatmap over a region polygon, urn:demographics, and artist, place and brand insights scoped to each city.
  • Free-tier LLMs only: Gemini Flash Lite first, then a second Gemini model, then Mistral. A small fallback wrapper moves to the next model when one is rate limited or overloaded.
  • Neon Postgres caches every Qloo response server-side for 30 days and stores saved plans.
  • MapLibre with OpenFreeMap tiles for the route map. The UI streams the agent's progress live: hotspots appear on the map while cities are being scouted.

Challenges we ran into

  • A tight API budget. The Qloo key allows 10,000 calls a month and 5 per second. We cache every response in Postgres, space calls out to stay under 5 per second, and cap live calls at 300 per day for the whole app. A repeat plan for the same artist costs almost nothing.
  • "Places" are not venues. Without filters, Qloo's place results for San Francisco included a famous painted-lady house. Filtering by Qloo's venue tags (live music venue, concert hall, night club, live music bar) turned that into The Independent, Great American Music Hall and SFJAZZ.
  • Small free models make small mistakes. Gemini Flash Lite once sent a finished plan with map coordinates for every stop but no city names, which failed validation and threw away a three-minute run. A repair step now fills a missing city from the nearest known city before validation runs.
  • Building before the key arrived. The API key took days to arrive, so we built against a mock client that returns the documented response shapes, then checked every call against the live API when the key came.

Accomplishments that we're proud of

  • Every venue, opener and sponsor on the poster is a real Qloo entity the agent actually received. The prompt forbids invented names, and each pick shows the signal behind it.
  • With a warm cache, a full multi-stop plan finishes in about 10 to 20 seconds on free models.
  • It follows Qloo's safe-use guidance: results are framed as aggregate taste signals, never claims about individual fans, and the key never reaches the browser, the prompts or the repo.
  • The whole stack runs on free tiers, so it can stay up for judges at no cost.

What we learned

  • Taste data is most useful when it is concrete. "Your audience over-indexes here" means little to a band, while "this 450-capacity room in Glasgow fits your crowd" is something they can act on.
  • Agents behave much better with a few narrow tools and a typed final answer than with one big prompt.
  • Caching is a design decision, not an afterthought, when the API budget is small.

What's next for Tourwise

  • Venue capacity and booking contacts, so the agent can match room size to expected turnout.
  • Dates and routing by real drive or flight time instead of straight-line distance.
  • A one-click pitch email per venue that includes the Qloo evidence.
  • More regions, and comparing two artists to plan a co-headline tour.

Built With

Share this project:

Updates

Submission history