Tastecraft

Type a restaurant. An agent reads who loves it on Qloo's taste graph and returns next week's 3 dishes, an event and a supplier order, with every cited Qloo name and score checked.

Comment

Tastecraft tells an independent restaurant what its own crowd likes, from Qloo's taste graph, and turns it into next week's plan: three dishes to test, an event, a post and a supplier order.

Judge it in 60 seconds

  1. Open https://tastecraft-xi.vercel.app and press Replay on the Gjelina, Los Angeles card. It's a real run (Qloo + Claude) that I recorded, replayed in about 15 seconds. Katz's Delicatessen is the one with the best concert matches.
  2. Under the headline you'll see this run's crowd lift (×2.8 for Gjelina). It's labelled in-sample, because the agent saw the crowd-vs-city contrast it's scored on. Right below it is the same model with and without Qloo, scored with the same formula.
  3. Open "Three dishes to test". Each dish shows its lift and the local menu counts behind it. If a term sits on fewer than 5 menus, it's marked "low count". An evidence line gets a check when the Qloo names and scores it cites came back in that run.
  4. If you want it live, type any restaurant and city. It takes about 2 minutes (median 128 s over 5 runs). Live runs are capped per day so the demo stays up. If the cap is hit, the page says so and offers the replays, which are always instant.

Or skip the wait: on the home page, scroll to "Now switch Qloo off" and flip the switch. It's the same recorded run with and without Qloo, both scored the same way.

What Qloo adds, measured on restaurants the model never saw: +27% over the same model alone (95% interval +7% to +48%), better in 6 of 8 restaurants. That's the number I lead with. The setup is in eval/SUMMARY.md in the repo: 8 restaurants in 8 cities, the same model at the same effort in every arm, and each dish scored only on a held-out half of Qloo's restaurant lists (5 random splits). The model's dishes get a crowd lift of ×0.90 on their own, ×1.00 with Qloo affinity data and ×1.15 with Tastecraft's crowd-vs-city contrast. Against affinity data alone the gain (×1.15, interval ×0.89 to ×1.53) is within the noise of 8 restaurants.

One thing to know about the ruler: it comes from Qloo too. Crowd lift is computed from Qloo's own menu tags, so it tests whether the dishes follow this crowd's Qloo signal, not whether guests will order them. The bigger numbers you'll see are in-sample. The badge on each replay (×2.8 Gjelina, ×2.9 Katz's, ×3.2 Casa Lucio) comes from an agent that saw the contrast it's scored on, next to a quick no-Qloo answer from one low-effort call. My first in-sample benchmark read ×2.44 against ×0.91.

How it fits the judging criteria

  • Technical implementation. Eight Qloo workflows: seven over /search, /entities, /v2/insights (entities, tags, demographics, heatmap) and /v2/analysis/compare, plus concert ranking with the rank workflow from Qloo's official qloo-harness package. A crowd-vs-city contrast built from two Qloo queries, checked on a held-out benchmark. The Qloo names and scores cited in each evidence line are checked against that run's own Qloo responses. Bounded retries, request smoothing, 175 unit tests with CI and an MCP server.
  • Design. You watch the agent work through Qloo call by call and see the plan drafted live. A one-click switch on the home page turns Qloo off and on for the same question. The with/without-Qloo comparison sits right under the headline. Then a taste constellation, a taste map with named neighbourhoods, lift and evidence on every dish, print-ready assets, in English and Spanish.
  • Potential impact. More than 7 in 10 US restaurants are single-unit, with no insight team. Tastecraft gives the owner dishes, an event, a campaign, a supplier order and a week plan. There's a business case with a price hypothesis and a measured cost per playbook below.
  • Quality of the idea. It uses the guests' other tastes and compares them with the city to find what's specific to this crowd. Katz's guests' other favourite places are cheap pizza slices, hot-dog counters and dive bars, which points to a weeknight pub-snack menu rather than more deli classics.

Inspiration

Before this I built Supplora, an AI tool that read supplier delivery notes for a family-run restaurant in Spain and loaded them into its management system (715 notes processed by September 2026). Sitting in that kitchen I kept seeing the same thing. The owners know their costs to the cent, but the week's special, the Thursday event and where to hand out flyers get decided on gut feel. Chains have insight teams for this. A 40-seat restaurant has the owner, at 11 pm, after service.

A general chatbot doesn't fix it. Ask what a tapas bar should add and it answers from the cuisine, so every tapas bar gets roughly the same advice. What's missing is who actually loves this specific place, what else they love, and what sets them apart from the rest of the city. That's what Qloo's taste graph knows.

What it does

The owner types the restaurant, the city and a goal ("fill quiet weeknights"). A Claude agent works through Qloo's taste graph in front of them and builds a playbook in three acts:

  • Read the room. What the guests also love (local places, music, brands, films) as a taste constellation, what this crowd's favourite restaurants serve more often than the city's most popular ones, who they are, where in the city this taste lives, and what only this restaurant or only its closest rival is known for.
  • The moves. Three dishes to test, each with a price, a crowd lift and Qloo evidence. An event built on the guests' music taste and on nearby concerts whose fans match this crowd. A ready-to-post caption aimed at the right neighbourhoods.
  • Opening night. A supplier shopping list (CSV plus an order email), print-ready chalkboard and Instagram images, and a 7-day plan you can drop into a calendar.

The concert part is easiest to see with Katz's. The recorded run found two shows its crowd over-indexes on: Amber Mark at the Blue Note, 0.9 km away (fan match 92), and Will Varley at Mercury Lounge, 0.1 km away (fan match 87). The playbook turned them into a free pickle plate with any sandwich for ticket holders after the Blue Note set, and a dog, fries and beer combo before doors at Mercury Lounge.

An honest note on Gjelina. Its bet is a daytime coffee moment plus a cheaper late-night pizza window, and that overlaps with Gjelina Take Away next door at 1427 Abbot Kinney, which already sells wood-fired pizza and sandwiches from breakfast to dinner. The agent itself flagged that Take Away guests may be mixed into the signal. So I read the Gjelina playbook as: bring that daytime crowd into the restaurant itself. The replays are well-known restaurants on purpose. Qloo has rich data on them and a judge can check the output against what they know. A small place with thin data gets a thinner playbook, and its caveats say so.

How I built it, and how it uses Qloo

  • The agent is Claude (claude-opus-5-5) with the Anthropic SDK's tool runner, adaptive thinking and streaming. It has eight Qloo-backed tools and a schema-checked publish_playbook tool, so the UI never parses free text.
  • /search and /entities find the restaurant (exact, close or ambiguous, with a one-click switch). /v2/insights gives cross-domain affinity (places filtered to the city, other domains localised), tag families, demographics and the urn:heatmap taste map. /v2/analysis/compare sets the restaurant against its closest rival. Concerts are ranked for this audience with the harness rank workflow.
  • Crowd lift is the score on every plan, and the server computes it. I make two Qloo queries in the same city: the ~150 restaurants this restaurant's audience loves most and the city's ~150 most popular. Only the ones with menu tags count (145 and 139 for Gjelina), and every count on screen uses those denominators. A dish's lift is how much more often the crowd's favourite places serve its food terms than the city's do. It replaced my first score, the mean affinity of the cited facts, after I measured that Qloo's top dish tags average 99.2 for one audience and 99.6 for the whole city. That score read 96 to 100 on every plan.
  • Every name and score Qloo returns is recorded on the server. Each evidence line lists the Qloo names and scores it relies on; a name has to have come back in the run and a score has to match within 1 point. Names and numbers in the rest of the text aren't checked, and the app says so.
  • It's also an MCP server (taste_profile, taste_playbook), so a POS copilot or Claude Desktop can call Tastecraft.
  • Next.js 16, React 19, Tailwind 4, Leaflet with OpenStreetMap. Instant replays come from an encrypted private cache, so there's no Qloo data in the public repo. Live runs are rate-limited and have a kill switch.

Business case

Who pays: independent restaurants and small groups of 2 to 10 locations, per location per month, with the first playbook free. My price hypothesis is US$49 per location per month. I haven't tested it with a paying owner yet, and it's the first thing a pilot has to check.

What a playbook costs me: US$0.32 to 0.37 of Claude, from the token counts of two logged runs at Claude Opus 5.5 list prices (82k and 93k input tokens, mostly cache reads, and 8.7k and 9.2k output tokens). On the Qloo side it's 17 to 34 API requests, counted from the code paths the three recorded runs took. The crowd and city lists alone are 6 requests, and the concert ranking adds one lookup per artist. A weekly playbook is about US$1.50 of Claude per location per month. Qloo's commercial price isn't public, so I left it out.

How it reaches owners: the app marketplaces that POS systems run (Toast, Square and Clover each have one) and reservation platforms' partner programs, through the MCP endpoint. Food distributors are the third route, because the shopping list is already an order for them.

How big it can get: there were 412,498 independent restaurants in the US at the end of 2025, per Technomic data reported by Nation's Restaurant News. The National Restaurant Association's 2025 pocket guide says more than 7 in 10 US restaurants are single-unit. Just as arithmetic, not a forecast: 1% of US independents at that price is about 4,125 locations and US$2.4M a year.

Why it's good for Qloo: every playbook is Qloo API usage, and a weekly one turns each subscribing restaurant into a recurring Qloo customer by proxy. Why me: I've already shipped an AI tool into a working restaurant kitchen, and I know where the owner's time goes.

Responsible data handling

No personal data, only Qloo's aggregated, privacy-first signals. Scores are written as group tendencies, never as predictions about a guest. Qloo responses are cached on the server only and never published in the repository (replays are encrypted at rest). The owner decides everything; nothing is ordered or posted automatically.

Challenges

  • Finding the right restaurant. Names collide, and one of my own sample buttons resolved "Gjelina, Los Angeles" to the convention centre until I added a name-only fallback.
  • A score that tells plans apart. Affinity sits near 100 for anything popular, so I built the crowd-vs-city lift and measured it.
  • Reading Qloo's outputs carefully. When I compared two places, every shared tag came back with the same weight (about 0.731), so I stopped showing it as a score and now show what only one side has.
  • Small counts. A term on 4 menus against 0 reads about ×4.8 after smoothing, so the app marks anything on fewer than 5 menus as low count and never leads with it.
  • A fair benchmark. My first one let the model see the contrast it was scored on, which gave ×2.44. With a held-out split it's ×1.15 against ×0.90, and that's what I report.
  • Two languages. Qloo's menu tags are mostly English, so when I asked for a playbook in Spanish, its dishes got scored on words few local menus use (brocheta, where the menus say skewer). My test run read ×0.7 with Qloo and ×0.7 without it, which told me nothing. Now each dish also carries its English name, on both sides of the comparison, and English playbooks score exactly as they did.

What I'm proud of

  • +27% over the same model alone on restaurants it never saw, with the method, the per-restaurant results and the limits published.
  • The cited Qloo names and scores in every evidence line are checked against that run's own responses, and the page says what isn't checked.
  • From a restaurant's name to a supplier order, a post and a calendar in about 2 minutes.

What I learned

The value isn't that AI writes a plan. It's that the plan starts from who actually loves this restaurant, and from what makes them different from everyone else in the city.

What's next

Connect POS sales to learn which bets worked. Run a first paid pilot with a small independent. Use Qloo's trending and audiences endpoints to flag artists and brands rising with a crowd. Game-day and concert-night playbooks.

Known limitations

Crowd lift is a proxy, not demand: it says the crowd's favourite places serve dishes like these more often, not that guests will order them here. Many per-term counts are single digits, the benchmark covers 8 restaurants, and coverage varies by city. On held-out restaurants, the gain over Qloo affinity data alone is within the noise. The full list is in the README.

Built With

Share this project:

Updates

Submission history