Inspiration
Independent musicians book their own tours. They guess which cities will show up, cold-email venues that may not fit, and pick support acts from whoever they already know. A bad guess costs an empty room and a long drive. The audience data that would settle these questions usually belongs to labels and agents.
What it does
Type in an artist and a country. Roadie returns a tour you can act on:
- Cities ranked by how closely local taste matches the artist's audience.
- A venue in each city chosen to fit that audience.
- Support acts with overlapping fans. You can bias the search toward smaller acts, so the support is someone you can actually book.
- Brand partners the audience already likes, for sponsorship pitches.
- A route ordered by nearest neighbour, with the distance of each leg and the total.
Each stop includes a one-sentence reason drawn from Qloo's data. The agent's steps appear live while it works.
How we built it
Roadie is a Next.js and TypeScript app, deployed on Vercel, with a tool-calling agent on the server. The LLM is Gemini, with OpenRouter as backup. The agent has five tools, and each one is a Qloo call:
| Tool | Qloo endpoint |
|---|---|
search_artist |
/search |
similar_artists |
/v2/insights, urn:entity:artist |
rank_cities |
/v2/insights, urn:entity:destination |
find_venues |
/v2/tags to resolve the venue tag, then /v2/insights, urn:entity:place |
find_brands |
/v2/insights, urn:entity:brand |
The agent finishes by calling submit_tour. The server checks every city, venue, artist and brand in that submission against the results the tools actually returned. Any name that doesn't match is rejected and sent back for the model to fix, so the model can't invent a venue.
If no LLM is available, for example when the quota runs out, a deterministic planner runs the same Qloo tools in a fixed order. The demo keeps working and the UI labels which planner produced the result. Qloo responses are cached for 30 minutes, and API keys never leave the server.
Challenges we ran into
- Qloo silently ignores invalid parameters. A wrong filter returns a successful response with no results, so each parameter had to be checked against the docs.
- A plain place query returns restaurants, so venues have to be filtered by a resolved venue tag.
- LLMs tend to fill gaps with plausible names they made up. A prompt rule wasn't enough to stop this, so we added server-side validation.
Accomplishments that we're proud of
- Grounded output. The server rejects any city, venue, artist or brand the tools didn't return.
- A planner the user can follow. Each tool call streams to the UI as it happens, so you see how the plan was reached.
- No dead ends. If the LLM fails, the deterministic planner takes over, and the UI says which planner ran.
- Fast. A full four-stop plan takes about five seconds.
What we learned
The taste graph should be the source of truth and the LLM only the planner. The useful part of an agent here is the reasoning between steps, for example trading a higher-affinity city against a long drive. The facts come from Qloo.
What's next for Roadie
- Use real tour constraints: dates, capacity and budget.
- Use draw estimates from past shows.
- Export a booking sheet and draft venue outreach emails.
Note on the demo
We applied for a hackathon Qloo API key but hadn't received it at submission time. Until it arrives, the live demo runs the real Gemini agent against clearly labelled sample data shaped like Qloo responses. All Qloo calls are implemented in src/lib/qloo.ts against the documented endpoints. Once the key is set as an environment variable, the same deployment uses live Qloo data. No code changes are needed.
Built With
- gemini
- next.js
- node.js
- openrouter
- qloo
- react
- typescript
- vercel
Log in or sign up for Devpost to join the conversation.