Sitebrief: Data-backed site selection for restaurants

Stop guessing where to open. Scout smarter with Qloo-powered audience intelligence and evidence-backed AI.

Comment

SiteBrief — Find Your Next Restaurant Location with Taste Intelligence

Tagline: Stop guessing where to open. Scout smarter with Qloo-powered audience intelligence and evidence-backed AI.

Inspiration

Opening a restaurant is one of the biggest bets an operator can make. Yet location decisions still rely heavily on gut instinct, broker recommendations, demographic reports, and expensive market studies.

Traditional location tools tell you who lives in an area. But they rarely tell you something equally important: Does this neighborhood actually align with the tastes of your future customers?

A neighborhood might have the right income, population, and foot traffic, but that doesn't automatically make it a good fit for a specialty coffee brand, a family café, or a new dining concept.

We wanted to go beyond demographics and generic heatmaps.

What if a restaurant owner could describe their concept, reference brands their customers love, choose a city, and receive a practical shortlist of places worth investigating?

And what if every recommendation had an evidence trail instead of an AI-generated explanation that merely sounded convincing?

That's why we built SiteBrief.

What it does

SiteBrief is an AI-powered restaurant location scouting agent that combines Qloo's Taste AI with grounded research to help operators discover promising areas for their next restaurant.

Instead of asking users to interpret dozens of dashboards, SiteBrief turns audience preferences into a focused, actionable site brief.

Here's how it works:

  1. Describe your concept. Choose a city, search radius, and brands or cultural references that represent your target audience. For example, explore where a Blue Bottle-style specialty coffee concept might fit in Toronto.

  2. Discover neighborhood taste signals. SiteBrief uses Qloo to identify relevant entities, audience affinities, popularity, shared interests, related brands, and nearby venues.

  3. Find areas worth visiting. A transparent ranking process screens candidate locations using disclosed popularity thresholds and taste-affinity signals. Rankings and ties are calculated in code, not invented by the language model.

  4. Research a specific location. The agent selects an eligible visit and locks its identity and coordinates before conducting additional research. Gemini uses Google Search grounding to retrieve external sources relevant to the visit.

  5. Inspect the evidence. Users can explore locations on a map, see Scout / Maybe / Skip assessments, review supporting signals and source links, and understand why an area was selected or excluded.

  6. Take the brief into the real world. Export a one-page PDF or detailed notes to guide an actual scouting visit.

SiteBrief is intentionally a scouting assistant, not a lease recommendation engine. It helps operators narrow down where to investigate, without pretending to know actual footfall, available units, rental economics, or guaranteed demand.

Try SiteBrief: https://sitebrief-circuitstudio.vercel.app/

Start with the Blue Bottle in Toronto example, watch the agent execute its tools, inspect the evidence, and download the resulting site brief.

How we built it

We built SiteBrief as an AI agent with a deliberate separation between taste intelligence, decision-making, and external research.

Qloo is the intelligence foundation.

Using the Qloo Hackathon API, SiteBrief connects several capabilities:

  • Entity Search: Resolves the brands and audience references supplied by the user.
  • Insights and Heatmaps: Retrieves location-level affinity, popularity, and ranking signals.
  • Places: Discovers nearby dining venues and their associated taste context.
  • Tags, Demographics, and Brands: Explores audience interests, demographic affinities, and relationships between brands.
  • Analysis / Compare: Examines shared and distinguishing taste signals across references and venues.

Those results become the basis for the actual shortlist.

Gemini 2.5 Flash acts as the agent.

Through function calling, Gemini decides which approved tools to invoke, inspects Qloo evidence, and returns structured decision codes. Google Search grounding provides external research links for the chosen visit.

But we deliberately avoid giving the language model unrestricted authority.

Ranking thresholds, tie handling, and the final eligible visit selection are enforced in code. The server locks the visit ID and coordinates before research begins, preventing a later model response from quietly changing locations.

When research is insufficient or cannot be validated, SiteBrief withholds unsupported local summaries rather than filling the gaps with plausible-sounding claims.

Our stack:

  • Next.js and TypeScript for the application
  • Vercel for deployment
  • Qloo Hackathon API for taste and location intelligence
  • Gemini 2.5 Flash for agent orchestration and grounded research
  • Upstash Redis for atomic daily admission limits
  • Model Context Protocol (MCP) over Streamable HTTP for reusable scouting tools

We also expose five read-only tools through /api/mcp, allowing the same scouting capabilities to be used by compatible MCP clients.

The project is open-source under the MIT license.

GitHub: https://github.com/circuitstudioai/sitebrief

Challenges we ran into

1. Preventing plausible AI recommendations from becoming fake evidence

A language model can easily produce a convincing explanation of why a restaurant would succeed in a neighborhood. The harder question is whether that explanation is supported by actual data.

We separated Qloo-derived signals from model decisions and external research. If Qloo cannot provide sufficient evidence, SiteBrief doesn't manufacture a location shortlist.

2. Keeping the agent geographically grounded

Early in the design, we recognized a subtle risk: an agent could evaluate one location, research another, and produce a final explanation that blends the two.

We addressed this with server-enforced visit locking. Once the highest-ranked eligible visit is chosen, its identity and coordinates must remain consistent through the research workflow.

3. Distinguishing taste affinity from market demand

High brand affinity doesn't prove that a neighborhood has unmet demand, sufficient footfall, or viable economics.

We explicitly avoid presenting Qloo scores as revenue forecasts or visitor counts. Nearby venue counts provide useful context, but aren't treated as proof of a market gap.

4. Balancing research quality with reliability and cost

Grounded research may return incomplete or insufficiently local evidence. Rather than invent conclusions, SiteBrief withholds unsupported summaries and exposes available sources for inspection.

We also implemented a shared, Redis-backed daily admission budget with fail-closed behavior to protect live API usage.

Accomplishments that we're proud of

We built an end-to-end scouting workflow, not just a chatbot connected to an API.

Users can begin with an audience concept and finish with a map, transparent candidate screening, evidence links, visit notes, and a downloadable PDF.

What we're especially proud of:

  • Qloo-driven discovery: Real taste signals generate the candidate locations. The model doesn't invent them.
  • Explainable selection: Ranking rules, eligibility thresholds, and ties are visible and enforced in code.
  • Location integrity: Server-side visit locking keeps research tied to the selected geographic point.
  • Evidence-first experience: Unsupported local claims are withheld rather than presented as facts.
  • Reusable agent tools: The scouting capabilities are available through an MCP endpoint, not just the web UI.
  • Runnable public demo: Judges can explore an actual end-to-end experience without configuring API keys.

SiteBrief is designed to make uncertainty visible, not hide it behind polished AI prose.

What we learned

Our biggest lesson was that better AI recommendations don't necessarily come from better prompts. They come from better evidence and clearer boundaries.

Qloo provides a dimension that traditional demographic-based location tools often miss: the relationships between people's tastes, brands, interests, and places.

But taste affinity alone cannot tell an operator whether a lease will succeed.

We learned to separate three responsibilities:

  • Qloo determines what the taste data actually supports.
  • The agent orchestrates tools and makes constrained, structured decisions.
  • Application code enforces selection rules and evidence requirements.

That separation makes the resulting brief more transparent and useful.

We also learned that a product willing to say "we don't have enough evidence yet" can be more trustworthy than one that confidently recommends every location.

What's next for SiteBrief

Our next goal is to turn SiteBrief from a working scouting prototype into something restaurant operators can use during real expansion planning.

We're focusing on three areas:

Deeper evidence validation. Strengthen geographic relevance checks and source verification so locally grounded research can be surfaced confidently.

A clearer scouting experience. Improve map legends, taste-signal visualization, and comparison views so operators can understand candidate neighborhoods quickly.

Validation with real operators. Test SiteBrief with restaurant owners, franchise operators, and people evaluating new dining concepts. Understand which signals actually help them decide where to visit and what additional data they need before making an investment.

Longer term, we see SiteBrief becoming a practical starting point for restaurant expansion research, connecting cultural fit with the on-the-ground due diligence operators already perform.

The vision is simple: Make restaurant location scouting more intelligent, explainable, and accessible — without confusing AI confidence with real-world evidence.

Built With

  • agentic-ai
  • ai-agents
  • brand-affinity
  • consumer-insights
  • data-visualization
  • function-calling
  • gemini-2.5-flash
  • geospatial-analysis
  • google-search-grounding
  • location-intelligence
  • model-context-protocol-(mcp)
  • next.js
  • node.js
  • pdf
  • qloo
  • qloo-api
  • react
  • redis
  • restaurant-tech
  • site-selection
  • streamable-http
  • taste-ai
  • typescript
  • upstash-redis
  • vercel
Share this project:

Updates

Submission history