Inspiration

The admin of moving abroad is well served by apps; the cultural side is not. You have a visa and a flat, but for months you have no "your café", no bar where you feel at home, no idea which neighbourhood is yours. HR relocation teams know that slow social integration is a main reason international assignments fail. Erasmus students know it too. We wanted an agent that treats taste as something you can carry with you: you start from what you already love and translate it, place by place, into the new city.

What it does

You tell TasteBridge which city you live in, where you are moving, and up to 8 things you love at home: venues, artists, or habits. The agent then:

  1. Resolves each favourite in the Qloo taste graph (/search, biased to your home city so "Drop Coffee" is the Stockholm roastery, not a namesake in Turkey or Brazil). Habits and vibes ("natural wine", "sunday flea markets") are resolved to Qloo place tags (/v2/tags) instead.
  2. Translates each favourite into a like-for-like "then → now" match in the new city. Real examples from the live API: Drop Coffee → Copenhagen Coffee Lab (Lisbon) or Scandinavian Embassy (Amsterdam); Tyge & Sessil → Vino Vero (Lisbon) or Glouglou (Amsterdam); Moderna Museet → New National Gallery (Berlin); Fasching → A-Trane (Berlin); Pustervik → Lee's Palace (Toronto). Each match shows the taste tags the two places share, a Qloo affinity score, explainability, and two alternatives.
  3. Ranks neighbourhoods for your taste profile, using a Qloo affinity heatmap combined with where your matches cluster.
  4. Plans your first week: 7 days of 1–3 stops each, grouped by neighbourhood. Clicking a day draws its route on the map.

Every step of the agent's reasoning streams live in the UI, so you see what it searched and why.

How we built it

  • Stack: Next.js (App Router, TypeScript) on Vercel. The map uses MapLibre GL with free CARTO/OSM tiles.
  • Agent loop: runs server-side with Gemini function calling. It has six tools: search_entities, lookup_tags, find_equivalents, find_taste_matches, rank_neighbourhoods and submit_plan. Each step is streamed to the browser as NDJSON.
  • Qloo client: typed, using the X-Api-Key header against hackathon.api.qloo.com. It has a 6-hour LRU response cache, an outbound token-bucket rate limiter, bounded 429 retries, and response normalisation that drops logistics tags (payments, wheelchair access, takeout) so only taste tags are compared.
  • Grounding:
    • The model can only reference entity ids that Qloo returned, and unknown ids are dropped, so it cannot invent venues.
    • Shared tags are computed from Qloo data, not written by the model.
    • Each favourite gets a different place; weak or missing affinity scores are labelled as such.
  • Fallbacks:
    • A chain of free-tier Gemini models, then a deterministic "autopilot" that runs the same tools, so the demo never dead-ends.
    • Pre-recorded live journeys replay instantly.
    • A per-IP limiter protects the quota.
  • Tests: Vitest covers the agent, the client, and the parsers against trimmed real responses recorded from the hackathon API.
  • Built with substantial help from Claude Code (Anthropic's AI coding agent), as stated in the README.

How we use Qloo

Step Endpoint and key parameters
Resolve favourites GET /search?query=…&filter.location=<home lat,lon> (plus an unbiased lookup for artists)
Habits → tags GET /v2/tags?filter.query=…&filter.parents.types=urn:entity:place
One-to-one equivalents GET /v2/insights?filter.type=urn:entity:place&filter.location.query=<city>&signal.interests.entities=<one favourite>&filter.tags=<its primary genre>&filter.exclude.tags=<hotels…>&feature.explainability=true
Habit matches GET /v2/insights with filter.tags=<habit tags> and signal.interests.entities=<the places already resolved>
Whole-profile picks GET /v2/insights (places), with all resolved favourites as signals
Neighbourhood fit GET /v2/insights?filter.type=urn:heatmap&filter.location.query=<city>&signal.interests.entities=…

Qloo is the reasoning substrate. Without it, the agent has no idea that a minimalist Södermalm roastery and a Lisbon bakery-café share a taste audience. The LLM only plans, sequences and narrates. We send Qloo only public cultural entities and city names, never personal data, and the UI presents affinities as aggregate taste rather than predictions about the user.

Challenges we ran into

  • Finding the right "Drop Coffee". /search is global and returned namesakes on four continents first. Passing filter.location with the home city's centre fixed it, but that filter only returns places, so a second unbiased lookup keeps artists reachable.
  • Making the "equivalent" precise. Seeding insights with the whole profile returns good places, but not one-to-one translations, and hotels crowd the top. One insights call per favourite, filtered to the source's primary genre and excluding lodging, gave much better matches.
  • Habits. Tag signals alone were slow (~15 s) and noisy for places. Filtering by the habit's tags while ranking with the user's resolved places took under a second and was precise.
  • Results outside the city. Lisbon queries included Cascais and Ericeira, so we over-fetch and keep places within 11 km of the centre.
  • Keeping the LLM honest. Ids are validated server-side, shared tags come from Qloo, and the prompt forbids unverifiable claims.
  • Reliability for judges: streaming, caching, rate limits, model fallbacks, an autopilot, and instant replays.

Accomplishments that we're proud of

  • An end-to-end agent you can watch think. It runs in 20–30 seconds and finishes with a concrete plan on a map.
  • Explainable matches: shared tags, an affinity score and alternatives for every "then → now" card.
  • Free-text habits work alongside named places.
  • Works for eight destination cities on live Qloo data.

What we learned

Taste is a better input for relocation than demographics. People describe themselves badly but describe their favourite places precisely. Cross-city equivalence is a natural fit for a taste graph, as long as you translate like for like (wine bar to wine bar) and let the user's other favourites rank the result.

What's next for TasteBridge

  • B2B white-label for relocation companies and HR mobility teams, with a dashboard of cohort taste and neighbourhood fit for incoming employees.
  • A "Settle-in score" that tracks how quickly someone has built a new set of favourite places.
  • Saving and sharing a bridge, ICS export of the first week, and any city (Qloo already covers them; we only need neighbourhood outlines).
  • Two-way bridges for couples: find the neighbourhood that best fits both partners' tastes.

Try it

Built With

Share this project:

Updates

Submission history