TastePilot AI

Turn the films, music and brands you love into dining, travel and movie discoveries—grounded in Qloo’s Taste Graph.

Comment

Inspiration

Taste is connected across categories, but discovery experiences often ask people to start over in each one. A person can describe the films, artists or brands they love more easily than an unfamiliar restaurant or destination. TastePilot uses those familiar preferences as the starting point for exploring dining, travel and entertainment together.

The goal is practical: help someone discover options that connect to their taste, inspect where those options came from, and improve the next search through explicit feedback.

What it does

TastePilot AI turns up to three favorite films, artists, brands, books or places into recommendations across three domains: restaurants in a chosen city, worldwide destinations and films.

The workflow resolves each favorite to a real Qloo entity and shows the match. It then queries Qloo's recommendations for the selected categories, applying the chosen city, a verified restaurant-category filter and a relative price ceiling to dining results. Destinations are worldwide ideas; they are not presented as a timed travel itinerary.

Users can like recommendations to add new taste signals or hide results to exclude them from the next search. An expandable trace shows the plan, entity resolution, Qloo calls and curation steps. When an upstream request fails or Qloo has no relevant results, the app explains the limitation instead of filling the screen with invented suggestions.

How it is Qloo-powered

Qloo supplies both the identities used as preference signals and the cross-domain recommendations. The application uses Qloo's Search API to resolve typed favorites and its Insights API to retrieve restaurants, destinations and films. It preserves Qloo's ranking and available metadata, deduplicates recommendations, and applies feedback exclusions.

Without Qloo, this implementation cannot produce its taste-based results. It has no hard-coded recommendation catalog and does not substitute generated venues when the API returns an empty category.

The agentic workflow

The agent executes a bounded sequence: plan the selected domains, resolve favorites, incorporate feedback, query the selected recommendation tools, and curate the results. Selected category queries run in parallel. Explicit user feedback changes the next execution's signals and exclusions.

This version uses deterministic orchestration around Qloo's AI recommendation service. It does not contain an LLM or an external agent framework, and it does not make autonomous bookings or purchases. Its agentic behavior is the tool-driven discovery and feedback workflow, with visible execution steps.

How I built it

The interface uses React 19 and TypeScript with accessible component primitives. Vinext and Vite produce a Cloudflare Worker-compatible server application. The browser submits a discovery brief to POST /api/plan; the server alone authenticates to Qloo and returns the matched preferences, recommendations, warnings and execution trace.

The server validates input lengths, category choices, price levels and feedback identifiers. It checks JSON requests and same-origin browser submissions, limits request size, applies upstream timeouts, restricts Qloo destinations and returns errors that do not expose credentials. The Qloo API key is a runtime server secret, separate from source code and deployment assets.

Preferences and feedback remain in the current page session. No persistent user profile is stored. Favorite names and feedback entity identifiers are sent to Qloo when a user requests discoveries.

Challenges I ran into

Named favorites must resolve to the right type of Qloo entity before they can become meaningful recommendation signals. Real API checks showed that Search responses expose a types array, so the resolver handles that format rather than assuming one subtype field.

Dining also needs category and geographic constraints. I verified the restaurant category against Qloo's tags endpoint and applied the city and price limit to the dining query. Cross-domain discovery required keeping worldwide destination ideas separate from local restaurant searches.

Finally, missing metadata, sparse geographic coverage and partial upstream failures needed honest interface states. The app renders available information, validates outbound links, and leaves unsuccessful categories visible with useful feedback. A post-deployment connection issue was corrected and verified against the hosted runtime.

Accomplishments I'm proud of

  • A deployed application backed by live Qloo entity resolution and cross-domain recommendation calls.
  • A feedback loop that turns likes into taste signals and excludes hidden recommendations.
  • A visible tool trace and clear handling of empty categories and partial failures.
  • Server-only credential handling, with empty example environment files and a secret scan covering source and built assets.
  • Passing automated tests, TypeScript checks, production build, and API smoke checks.
  • A public MIT-licensed repository containing the deployed application source.

What I learned

Cross-domain recommendations depend on precise entity resolution and well-scoped queries. Reliable discovery also depends on explaining uncertainty: a model affinity score is not a probability, a destination recommendation is not a complete itinerary, and an empty result is more useful than a fabricated venue.

Keeping credentials entirely on the server and testing against real API response shapes were essential to moving the project from an interface to a working product.

What's next

Next steps include saved profiles with explicit consent, better explanation of cross-domain connections, broader local-dining coverage tests, and stronger public-use request controls. We also want to prototype common-ground recommendations for two people with different tastes and test the usefulness with real users. These are future features, not part of the current demo.

Try it out

Open the public TastePilot demo

Source code and MIT license

Instructions for judges

  1. Open the public demo in a desktop or mobile browser.
  2. Select The film lover example, or enter up to three favorite films, artists, brands, books or places with the correct type. For example, select Artist for Coldplay.
  3. Set a dining city and relative price level. Select the dining, travel and entertainment categories you want to explore.
  4. Select Find my discoveries. Inspect the resolved favorites and the category tabs.
  5. Like a recommendation or hide one, then select Update my discoveries to apply that feedback.
  6. Open How your discoveries came together to inspect the execution trace.

Judges do not need an API key or an account. Qloo coverage varies by city; empty dining results are shown explicitly. Check opening hours, availability and booking options through the result links. Model affinity scores are Qloo output, not calibrated probabilities.

Built With

Share this project:

Updates

Submission history