Inspiration

Every time you join a new app — a streaming service, a food app, a shop, a new AI assistant — you start from zero. You answer the same "what do you like?" questions, or you get generic results for weeks until the app learns you. Your taste is locked inside dozens of separate apps, and none of it travels with you.

At the same time, every business fights the "cold start" problem: new users get bland recommendations, feel the app doesn't get them, and leave.

"Sign in with Google" ended the era of creating a new account everywhere. I wanted to do the same for taste.

What it does

TasteID is a portable, user-owned taste profile.

  • Build it once, in about 60 seconds. Name a few things you love — artists, movies, shows, restaurants, games. Qloo's taste graph expands them across every domain: music, film and TV, dining, brands, books, podcasts, games and travel. You tell it about your music; it finds your film, food and book taste too.
  • "Sign in with Taste." Any app adds one button. With your permission, it instantly receives a privacy-safe taste profile and personalizes from the very first screen. No name, no email, no personal data.
  • You stay in control. Choose which domains each app can see, see every connected app, and revoke access with one tap — tokens stop working immediately.
  • Works with AI agents. An agent playground compares a plain AI with an AI that uses your TasteID, side by side. TasteID also exposes an MCP endpoint so AI assistants can call your taste as a tool.

Try it

  1. Create your TasteID at the live demo.
  2. Open one of three demo apps — Reelhouse (streaming), Forkful (dining) or Threadline (shopping). Each shows "what every new user sees" next to "after Sign in with Taste," with a reason for every pick ("Because you love X").
  3. Ask the agent playground: "Plan my Saturday in New York."
  4. Revoke an app in Connections and watch it lose access.

The demo apps are fictional brands built to show integration. They connect only through TasteID's public SDK and API, exactly as a real third-party app would.

How I built it

  • Next.js, TypeScript and Tailwind on Vercel, with Supabase Postgres for passports, OAuth clients, grants and a private server-side Qloo cache.
  • A real OAuth 2.0 authorization-code flow with PKCE, scoped JWT access tokens bound to revocable grants, and a dependency-free drop-in JavaScript SDK that renders the "Sign in with Taste" button. It falls back to a full-page redirect when popups are blocked.
  • Qloo powers every core feature:
    • /search resolves what users name into Qloo entities.
    • /v2/insights with signal.interests.entities, run per domain, expands a few seeds into a cross-domain profile.
    • filter.type=urn:tag builds the user's "taste DNA," and urn:demographics adds the audience skew.
    • filter.results.entities re-ranks each demo app's own catalog against the user's taste. This is how a real app would personalize what it already sells.
    • feature.explainability turns contribution scores into "Because you love X" explanations.
    • filter.location.query finds places the user would love in a chosen city.
  • The agent runs a tool-calling loop on Gemini, through an OpenAI-compatible client, with tools for get_taste_profile, recommend, search_entities and explain. Its tool calls show as trace chips so you can see it working.
  • No PII by design: passports are anonymous, restorable with a one-time recovery key that is stored only as a hash.

Challenges I ran into

  • The live API differed from what I expected in a few places. I wrote a probe script that tests every endpoint and parameter, and adapted the client to what it found:
    • the game entity type that worked was urn:entity:videogame
    • unfiltered tag insights returned noisy tags until I restricted filter.tag.types
    • insights return the specific type in subtype
    • demographics come back per entity and needed averaging
  • Qloo silently ignores unsupported parameters, so I built a per-type parameter allowlist into the client so a typo can't quietly return wrong results.
  • The hackathon API key arrived late, so I built a full mock mode with the same data shape. This let the whole product be built and tested before the key arrived, then switched to real data with one script.
  • Getting a reliable, fast LLM for tool calling took a few model swaps. I added timeouts so the agent never hangs.

Accomplishments I'm proud of

  • A complete, working consent flow: create passport, authorize with PKCE, scoped token, personalized results, revoke, then access denied. It is verified by an automated production smoke test that passes 14 of 14 checks against real Qloo data.
  • Three demo apps whose "before" and "after" views make the value obvious in seconds.
  • A design where privacy is the default, not an add-on.

What I learned

Taste is the missing context layer for AI agents. Agents can reason and act, but without knowing what a person actually loves, they guess. Qloo's cross-domain graph is what makes a portable taste profile possible: a few seeds in one domain reveal taste in all the others.

What's next

  • Business model: free for users. Apps pay per connected user to solve cold start, and AI agent builders pay for API access.
  • Official SDKs for web, iOS and Android, and a published MCP connector for AI assistants.
  • Richer, more granular consent and a taste profile that learns as you use connected apps.

Built With

Share this project:

Updates

Submission history