Beautifood — taste-aware restaurant software, with Qloo

Inspiration

Chains pay for consumer research before they change a menu, a playlist or their opening hours. A hawker stall or a neighbourhood restaurant can't. It knows what it sells, but not what the people around it love. Beautifood already runs these restaurants' queue, ordering, POS and kitchen screens, so it knows what sells. Qloo's taste graph knows what an area, or a fan base, loves across dining, music, TV and more. Together they can answer the question small owners actually ask: what should I try next, and why?

What it does

Qloo shows up in three places.

1. The owner's Taste page. For the branch's area, Beautifood asks Qloo for:
   • the places people love;
   • the same-cuisine places closest to their tastes;
   • the artists they listen to and the shows they watch;
   • what those favourite places are known for.

It sets that against the restaurant's own menu and its last 30 days of best sellers, and turns it into things to try this week:

• a weekend special for a cuisine the area loves and the menu doesn't serve;
• a brunch or late-night service;
• a dining-room playlist;
• a themed night;
• which nearby places to keep an eye on.

Every suggestion shows the Qloo finding behind it and where it came from.

1. Guests at the table. A guest tells the menu assistant "I love BTS, what should I get?" (also in Malay or Chinese).
   • Beautifood asks Qloo which places BTS fans around the branch love, and reads what those places are known for: coffee, nasi lemak, cendol.
   • The assistant's dish concepts map that onto this menu's dishes.
   • It's a ranking boost applied after every filter, so "I'm allergic to peanuts" still removes anything unsafe.
   • The answer says plainly that this is what fans like in aggregate, not a guess about the guest.
2. The owner's own AI agent. Over Beautifood's MCP server, with a personal token, the owner's Claude or ChatGPT gets two tools:
   • merchant_taste_brief returns the same brief;
   • merchant_taste_query runs any read-only Qloo workflow for its own research.

The agent can then act with Beautifood's other merchant tools (menu, promotions, reports). It gets Qloo through Beautifood, within Beautifood's permissions and quota.

How we built it

• App. A Cloudflare Worker with a D1 database, React, TypeScript throughout.
• Taste service. Qloo's hackathon harness (qloo mcp) runs in a small Cloudflare Container. It wakes on demand and holds the Qloo key as its only secret. The Worker calls it with a bearer secret, and no key ever reaches a browser.
• Making a brief. A brief is one round of Qloo calls:
  • find_tags for the cuisine;
  • recommend for places, artists and TV with a location signal, and for places with a restaurant tag filter;
  • entity_tags for what the area's favourite places share.

Deterministic code then compares the result with the menu and the sales, so each suggestion can cite its exact reason.

• Guest side. The guest assistant is our own small intent model, with no LLM call per message. Its dish "concepts" are what lets a Qloo tag like "milk tea" find "Teh Tarik".
• Caching. Each Qloo answer is cached for a day and each brief for 12 hours, and calls are capped per day.
• Privacy. Nothing about a guest is sent to Qloo. A brief sends only the restaurant's public name, area and cuisine; the guest feature sends only the name the guest typed.

Challenges we ran into

• Locations. Qloo didn't know a mall like "Suria KLCC", so the brief widens to the city.
• Place results without tags. We read what places are known for from Qloo's shared entity tags and their descriptions instead.
• Ambiguous names. "BTS" is more than one entity to Qloo, so we pick the most likely one when it asks back.
• Wrong kind of place. Malls and hotels came back as "places people love" until we filtered to restaurants.
• Wrong suggestions. Early versions suggested "Malaysian" to a Malaysian restaurant, and "Café" as a special. Both are filtered now.

What we're proud of

• Every suggestion can say why, and where the finding came from.
• The guest feature never weakens allergy safety.
• It is already in a working product a restaurant can run today, not a separate demo.

What we learned

Taste data is most useful when it's set against a business's own data. "People here love brunch" alone is trivia. "People here love brunch, and you don't open until 11" is an action.

What's next

• A trial tracker: when the owner runs a suggested special, Beautifood's reports measure what it did to sales.
• Briefs per branch for chains, and alerts when an area's tastes shift.

Built With

• cloudflare-containers
• cloudflare-d1
• cloudflare-workers
• model-context-protocol
• playwright
• qloo-taste-ai-(hackathon-mcp-harness)
• react
• typescript