DevBuds

• 

  Home Screen

• 

  Curated pathways

• 

  Results based on Taste Desk · Your taste, translated into a new city

• 

  Taste map

• 

  Your taste, in tags

Inspiration

The hackathon brief says agents are "culturally blind," and that matched something I kept noticing ask a general AI assistant where to go in a city you've never visited, and you get confident, generic answers, sometimes about places that don't exist.

Arriving in a new city means starting from zero. Your favorite film, band, or dish says a lot about you, but nothing connects those things to a place you've never been. I wanted to build the bridge your taste, translated for a new city.

What it does

You enter three to five favorites a band, a film, a dish and the city you're landing in. Taste Desk then:

• Resolves each favorite to a real Qloo entity, and uses taste tags when a favorite is a taste rather than an entity (like "ramen").
• Recommends real places from Qloo's taste graph, with the affinity and popularity Qloo returned for each pick.
• Maps where your taste lives in the city. Each favorite gets its own color, clusters are named by neighborhood, and overlaps are called out. In the Lisbon demo, Radiohead's and Amélie's fans both point toward São José.
• Describes your taste in tags, like Alternative Rock and Cerebral for Radiohead, and Whimsical and Magic Realism for Amélie.
• Explains every pick in plain language, citing which favorites led to it.
• Shows its work in an agent trace, and offers a side-by-side "Why not just ask a plain AI?" comparison.

How I built it

• Qloo, via the official harness. An Express server runs qloo exec and uses five workflows: describe, find_tags, recommend, where_popular, and entity_tags. The Qloo key lives only on the server.
• A model that can only explain. A Gemini Flash model (with a Groq fallback) writes the reason for each pick, but it may only use items Qloo returned. The server drops anything else it names, and the trace records what was removed.
• React + Vite front end with Leaflet and OpenStreetMap for the taste map. Neighborhood names come from Nominatim, cached and rate-limited, with a fallback label instead of raw coordinates.
• Reliability work: an hour of caching for identical Qloo calls, per-IP rate limiting, bounded retries that skip quota errors, and saved example plans that load instantly without spending quota.
• Hosting: Render, with a keep-awake health check. Code is MIT-licensed on GitHub, and I built it with Cursor as my coding agent.

Challenges

• Ambiguous names. "Radiohead" matches an artist and an album, "ramen" matched Irish restaurants called Ramen, and two Johannesburg restaurants shared a name. Qloo asked for a choice each time, so I built a resolution step that picks the right entity type, falls back to taste tags, and says so in the trace when something can't be resolved.
• The wrong gateway. My hackathon key was rejected by the main API and only worked on the hackathon gateway. Reading real responses early saved me from building on wrong assumptions.
• My first taste map was misleading. Querying at country level and merging points over a huge radius pointed a Johannesburg user toward the Western Cape. I rebuilt it to query the city, cluster at about 1.5 km, keep each favorite's clusters separate, and hide the map when nothing usable comes back.
• Junk in the tags. Radiohead's first tags were place attributes like "VISA" and "Two Star." I filtered by Qloo's tag types, which also kept real genres and cut generic ones.
• Gaps are real. Amélie has no heatmap in Johannesburg. I chose to show that honestly in the trace instead of faking a result.

What I learned

• Looking at real API responses before designing the UI prevented several dead ends.
• Grounding works best when the model's job is narrow: arrange and explain what the data returned, nothing

Built With

• css
• html
• javascript