Crave — Taste Agent

Tell it what you love. It finds where you should eat. Crave turns cultural taste into ranked restaurant picks with a plain-language explanation for every one, powered by Qloo's Taste AI.

Comment

Inspiration

Every restaurant app asks the same food questions and returns the same popularity contest. But taste is one connected graph: the music you love, the films you quote and the neighborhoods you wander already predict the rooms you'll love eating in. Crave started from a simple question — what if a recommendation agent read your cultural taste and had to explain itself?

Crave is a taste agent. Two people name the culture they love; Crave reads both taste profiles from Qloo in parallel, gathers the restaurants that pass a strict dining test, scores the shared candidates for each person individually, and makes one dinner decision — ranked by the worse of the two ranks, so neither palate is sacrificed. Every pick carries its receipts: Qloo's native explainability shows which of your favorites drove it, and by how much. Don't like the decision? Skip it — Crave excludes the venue server-side and re-decides from the same taste evidence. Too few valid restaurants? It pulls the next page of results under exactly the same rules, and its trace tells you it did. Every line of that trace is a fact about the run that just happened.

Try it like a judge

  1. Run Radiohead + Inception in Solo mode.
  2. Add Björk + Studio Ghibli in Partner Mode.
  3. Compare the common-ground picks against each person's individual picks.

What it does

You name 1–6 cultural favorites — artists, films, shows, places. No food questions, ever. Crave resolves each favorite to a Qloo entity, builds a taste signal, and queries Qloo's Taste AI for restaurant affinities. It then summarizes the cuisine tags from the returned candidates in plain words ("your taste clusters around Seafood · American · Italian") and returns a ranked shortlist where every pick carries a one-line explanation traced to that cluster, plus its cuisine, price level, neighborhood and signature dishes.

Partner Mode runs two taste profiles and finds the overlap: venues both profiles independently surfaced come first (scored by the geometric mean of the two affinities); when there are fewer than three shared venues, it falls back to cuisine-level common ground — picks from either side whose cuisines live in both palates' clusters — then alternates each side's strongest remaining pull so neither palate dominates the table.

Partner Mode example: One person enters Radiohead + Inception and another enters Björk + Studio Ghibli. Venues recommended for both people are shown first, followed by cuisine-level common ground, clearly labeled as cuisine-level common ground — picks whose cuisines appear in both people's profiles, shown when the two profiles do not share enough venues on their own.

How we built it

Zero-dependency Node.js. A static single-page front end talks to two serverless functions (/api/search, /api/picks) so the Qloo API key exists only as a server-side environment variable — never in browser code, the repo, or any screenshot. The agent pipeline: /search entity resolution → /v2/insights with filter.type=urn:entity:place and a restaurant tag filter → cuisine clustering → explanation composition → (in Partner Mode) cross-profile merge. Event-API flakiness is absorbed with bounded retries and backoff.

One finding shaped the build: the broad restaurant genre tag admits museums, markets and malls with cafes. The restaurant category tag (urn:tag:category:place:restaurant) returns dining-grade results, and a cuisine-presence guard drops venue-cafes that inherit a restaurant category without any cuisine identity of their own. Qloo's hosted place photos return 403 to hotlinking, so cards use a designed tag band instead — every visual element on the page is data the API actually returned.

Tonight's upgrade, built after judge-style audits of the first version: native explainability (feature.explainability=true) preserved end-to-end into a per-person 'Why this fits each of you' panel; location scoping via filter.location.query across eight verified cities; vetoes via filter.exclude.entities; shared-candidate scoring via filter.results.entities ranked by minimize-the-worse-rank. Eligibility is now a strict dining test — cuisine evidence of a venue's own plus dining-only place categories — because cuisine tags alone let malls borrow their food tenants' tags: Westfield World Trade Center was the #2 global pick before this rule existed. The agent works under a 10-call session budget; a typical Partner decision uses 4.

Challenges we ran into

  • Landmark skew: unfiltered place insights return observatories and bridges, not dinner. Reduced with tag filtering, verified tag-family by tag-family (see above).
  • Fewer than three shared venues: two genuinely different palates often share fewer than three identical venues. The cuisine-level common-ground fallback keeps Partner Mode honest — convergence is computed from returned data, never faked.
  • A flaky event API: long stalls in bursts. Bounded retries server-side; the UI keeps the user's profile intact on failure.

Accomplishments that we're proud of

  • A complete recommendation → explanation loop on a live taste graph, in a demo that runs in under two minutes.
  • Explanations that never invent: every claim in every sentence traces to a tag or field Qloo returned (no LLM in the loop).
  • Partner Mode's two-tier overlap (venue, then cuisine) — a real answer to "where should we eat?" instead of averaging two lists.

What we learned

Taste graphs reward precision about which taxonomy you query: the difference between a genre tag and a category tag is the difference between a museum and a restaurant. And an explanation users can audit beats a score they can't.

What's next for Crave

Crave already exists as an iOS restaurant picker; this web agent is its taste-graph brain. Built during this hackathon was the Qloo-powered web Taste Agent, while the earlier iOS Crave restaurant picker already existed before this hackathon. Next: location-aware ranking (a city picker over the same signals), dietary and budget constraints as first-class filters, and group mode for 3+ palates.

Built With

Share this project:

Updates

Submission history