TasteMatch Trips

Inspiration

Group travel often ends with one person quietly compromising. TasteMatch Trips treats fairness as a first-class planning signal: not just the average preference, but whether anyone is being left out. Qloo lets a group start with cultural favourites rather than detailed personal profiles.

What it does

Each traveler supplies a nickname and a few favourite movies, artists, brands or shows. The agent resolves them with Qloo's /search API, retrieves destination affinities with /v2/insights, and compares the same candidate cities for every traveler. Its destination score combines 40% mean affinity, 40% minimum affinity and 20% group affinity.

For the selected city, it finds local venues, applies venue filters and cross-scores candidate stops for the group. It plans, self-checks and can re-plan once to reduce an imbalance: the least-matched traveler gets priority, while group-aware choices consider who is furthest behind. The interface exposes per-traveler scores, itinerary provenance, a fairness self-check, a map and an agent trace rather than hiding the decisions behind a generic travel paragraph.

The group can also choose its own destination. Unmatched favourites are reported. Share links encode the planning inputs and generate a new plan when opened; they do not freeze the previous results. Affinities are cultural associations, not predictions of an individual's enjoyment.

How we built it

A Python/FastAPI service coordinates entity resolution, Qloo affinity queries, fairness ranking, venue cross-scoring and itinerary self-checking. The browser interface uses HTML, CSS and JavaScript. httpx handles Qloo requests, with an in-memory cache, bounded retries and a per-plan time budget. The repository includes an optional n8n Telegram workflow, Docker configuration and offline pytest tests. The existing demo is hosted on Vercel.

Narration is a deterministic summary of retrieved facts. An optional LLM rewrite is supported but is not enabled on the hosted demo. Without a Qloo key, local development uses an explicitly labelled mock graph; mock results are not presented as live Qloo evidence.

Challenges and current limitations

Free-text favourites can resolve to the wrong entity, and city names can be ambiguous. Per-person top-N lists also fail to provide a fair comparison, so the agent scores a shared candidate set. Venue lists need filtering before they become plausible sightseeing stops.

The current hosted prototype can substitute zero for some missing per-traveler affinities, which can affect the fairness scores and self-check. Its venue filtering can also fall back to less suitable listings when candidates are scarce. These are limitations of the current demo, not claims of complete data or guaranteed suitability. Improvements to missing-data handling and fallback explanations are still being prepared.

What we learned

A useful agent needs explicit objectives, verifiable tool results and honest failure states. Qloo's cross-domain taste graph becomes more useful when its candidate set and provenance are made visible. Fairness is a planning heuristic to inspect, not a promise that everyone will enjoy a trip equally.

Try it

Open https://tastematch-trips.vercel.app, select Load sample, then Plan our trip. No login is required. Planning uses the configured Qloo API and can be affected by its availability or rate limits. The public MIT-licensed repository includes setup instructions and an offline mock path: https://github.com/heavycastles/tastematch-trips.

What's next

Budget and travel-time constraints, group polls and additional destination coverage are future work, not capabilities claimed by this submission.

Built With

• fastapi
• python
• qloo