Common Ground

A generic AI guesses what your group might like; Common Ground knows what each of you loves and finds the plan where those tastes overlap.

Live demo · Sample group · Without-Qloo comparison · Make your own group · The story · How it's built

Built for the Qloo Agentic Hackathon. MIT licensed. No sign-up, no keys, nothing to install.

Try it in a minute

1. Open the sample College friends, Bengaluru, Saturday night. Four friends and twelve tastes become one restaurant, with a reason for each friend.
2. Open the X-ray under the plan: every Qloo call, each friend's score for each place, and the evidence each reason cites.
3. Scroll to Without Qloo vs with Qloo: the same model with no Qloo tools, side by side.
4. Open Flatmates taking Amma out for her birthday, where simple averaging and our fairness rule pick different places.
5. Make your own group: a live run, about 20–30 seconds, capped at 3 per visitor per day.

Sample pages replay real recorded runs. They load instantly and make no Qloo or model calls. The people in them are fictional; their tastes went through the real agent and real Qloo data.

The problem

Saturday, 4:10 pm, a WhatsApp group of four. "Where are we going tonight?" Forty messages later: one friend is vegetarian, one is on a budget, one wants a brewery, one says "anything is fine" and then vetoes everything. Someone always ends up organising, and they're guessing what everyone else likes.

Recommenders are built for one person. A group needs a place that works for everyone, including the friend whose taste is least like the others, plus one line for each friend on why it works for them, so the organiser can paste it into the chat and be done.

What it does

Step	What happens	Qloo capability
Who's coming	2–4 friends, a few things each one loves (artists, films, shows, places, dishes), veg and budget limits	—
Resolving tastes	Each taste is matched to a Qloo entity or tag. Ambiguous names ("Anirudh") are resolved and stated; misses ("Sid Sriram's new song") are retried and stated, never guessed	/search, /v2/tags
Finding overlap	Candidate restaurants come from everyone's tastes combined, plus each friend's own top places so a minority taste gets a say. Fast-food chains are dropped by tag	/v2/insights with location, category, price and popularity filters
Scoring for each friend	Every candidate is scored for each friend from that friend's own tastes, along with which of their tastes drove the match	/v2/insights with filter.results.entities and feature.explainability
Picking fairly	Hard limits first (veg, budget). Then the place whose least-happy friend is happiest wins, with a tie-break on the average	Deterministic code, not the model
Building the plan	One sentence per friend, citing only evidence Qloo returned; a WhatsApp-ready message	Explainability, place tags and properties

How it's built

flowchart TD
    U[Browser: /new, /g/id] -->|POST group, capped| API[/api/plan, streams steps/]
    U -->|GET sample| R[(Upstash Redis: recorded runs, private)]
    API --> A[Claude agent, Tool Runner]
    A -->|tools| T[resolve_tastes · choose_option · find_candidates · rank_for_group · explain_pick]
    T --> Q[Qloo client: cache, 10 req/s throttle, retries, trace]
    Q --> QA[(Qloo API: /search, /v2/tags, /v2/insights)]
    Q <--> C[(Redis cache, 7-day TTL)]
    T --> S[score.ts + constraints.ts: percentile per friend, maximin, hard limits]
    A --> P[Plan: pick from the fair ranking + reasons checked against evidence ids]

The model never produces a number. Claude (claude-sonnet-5-5, effort medium) decides which tools to call, classifies each taste (artist, film, show, place, food), handles ambiguous and unmatched tastes, and writes one sentence per friend. Matching, scoring, constraints and the pick itself are plain TypeScript with tests. Before the plan is shown, the server keeps only the evidence ids that explain_pick actually returned for that friend. A reason with none left is labelled "unverified".

This is the beginning of the README. Read the rest at the original. Read the full README ↗