Receipt

Receipt checks AI recommendations against your tastes using Qloo. It returns evidence, catches weak or unverified picks, and guides the agent to revise before delivery.

Comment

Inspiration

A restaurant can have excellent reviews and still be the wrong recommendation for the person asking. AI concierges can produce convincing shortlists, but the answer rarely comes with evidence that the places match that person's tastes.

We wanted to give those agents a way to check their own answers before sending them to a customer. The concrete use case is simple: someone is going to a concert, and an agent suggests dinner nearby. The artist they love gives us a starting point for understanding their taste.

That became Receipt: a taste check your AI calls before it recommends. Qloo supplies the cultural evidence; Receipt turns it into feedback the agent can use to revise its answer.

What it does

Receipt checks an agent's proposed places against the things a person loves and the requirements of their request. It is available as a live web app, an HTTP API, and an MCP tool integration for an existing AI client.

  1. The AI proposes a list. Supply the person's favourites, proposed places, city, and optional distance from a venue.
  2. Receipt checks the list using Qloo. It reports taste matches, weak matches, places it could not verify, and places outside the request. Each result includes available place details and the evidence behind the decision.
  3. The AI revises its own answer *. * Receipt returns structured critique. The agent chooses changes and submits them for another check against the same comparison set.
  4. A person reviews the result. The browser lets someone inspect and confirm the exact result, producing a visual receipt and downloadable evidence. The MCP integration gives the agent no tool to approve its own picks.

Developers can also test captured recommendation lists across multiple taste profiles and see a report card. A ticketing app could use Receipt to check a pre-show dinner suggestion before sending it with a ticket; concierge and travel teams could check recommendations before sharing them with a guest.

How we built it

We built the backend with Python, FastAPI and Pydantic, and the browser interface with JavaScript, HTML and CSS. The application runs on Hetzner behind Nginx, with Qloo credentials kept on the server.

Qloo's Search and Tags endpoints help resolve favourites, places and restaurant categories. Qloo's Insights API supplies the affinity evidence connecting cultural interests, including music and film, to places.

Receipt scores a fixed set of place IDs for the person's tastes. Its optional Distinctive taste check also scores those same places for three declared comparison profiles: pop, metal, and Latin. It measures how much higher a place ranks for the person than the average for those profiles. These are reference profiles, not a representative sample of the public.

We also remove one favourite at a time and rescore to show which inputs change a place's rank. Code computes the ranks, requires complete score coverage, checks the requested scope,e and freezes the comparison across revisions.

The real agent demonstration uses Claude connected through the official Model Context Protocol Python SDK. Claude proposes places, reads Receipt's critique,ue and chooses its revisions. The hosted app also offers a clearly labelled ratings-based rules agent.

We reused a generic local FastAPI starter for web-server scaffolding and used AI coding assistance during development and review. The Qloo integration, evaluation logic, agent tools, browser workspaces, and review flow were built for this hackathon.

Challenges we ran into

Names do not always identify one thing *. * Informal restaurant names and titles such as Dune can be ambiguous. We added common spelling aliases and explicit title selection instead of silently guessing. A place we cannot resolve stays unverified.

A revised answer needs a fair comparison. ** Changing the comparison set could make it look better without actually improving it. Receipt keeps the same tastes, place IDs, location requirements, and strictness across the revision loop.

Missing evidence must remain visible. The no-interest city query available to us did not return the affinity values needed for our original baseline. We left that metric unavailable and built the separately named reference-profile comparison. Incomplete scoring never becomes an invented rank.

A suggested replacement is still only a suggestion. We require another audit of the agent's changed list. Coming from Qloo's suggestions does not automatically make a place pass.

Accomplishments that we're proud of

  • A real Claude run went from 0/3 to 2/3 to 3/3. For a Nina Simone and David Bowie fan seeking dinner near Mission Ballroom in Denver, Claude revised its own picks through Receipt's MCP tools. All rounds used the same fifty-place comparison. The initial failures were one weak match, one unverified place,e and one place outside the request.
  • We made the test suite part of the product. With real Qloo data, we checked the same three highly rated restaurant picks against ten curated taste profiles. 18 of 30 did not clear Distinctive taste: ten had insufficient lift over the reference profiles, five were weak matches, es and three were unverified. Twelve cleared. This diagnoses a ratings-based agent; it is not a controlled LLM benchmark or a study of people's enjoyment. Method and complete results.
  • 124 automated tests pass. ** Browser checks also cover desktop and phone widths, revisions, review, ambiguous names, and missing evidence.
  • The product is usable end to end. Judges can try the hosted application, inspect the evidence,e and read the public MIT-licensed source.

What we learned

A useful recommendation check needs more than a score. It needs a clear definition of what passed, a comparison that stays consistent, and an honest answer when the data is incomplete.

We learned to let the language model propose and revise while code handles the calculations and review rules. We also learned that an explanation is more useful when it points to actual Qloo evidence or a measured change after removing a favourite.

Agreement with a taste graph is evidence, not a guarantee that someone will enjoy dinner. Opening hours and availability still need separate checks.

What's next for Receipt

We want to calibrate the checks against real preference feedback, broaden and test the reference profiles, and pilot Receipt inside existing ticketing, concierge and travel workflows.

For developers, the next step is making recurring agent evaluations easier to run and compare before a release. For the person receiving the recommendation, the goal stays simple: a choice with a clear reason it belongs in their answer.

Make every recommendation earn its receipt. **

Built With

Share this project:

Updates

Submission history