What's the Name?

Inspiration

Film and TV art departments constantly need to source props and set pieces, but the person looking for them often doesn't know what the item is actually called. That gap is the whole problem — because neither does anyone selling one. Prop House A lists it as a caged desk fan. Prop House B calls it a bullet fan. On Facebook Marketplace it's kipas meja (fan in Bahasa language). Same object, three names, and no keyword that finds all three.

Sourcing today means browsing catalogues, calling suppliers, and juggling spreadsheets, largely because nobody agrees on what things are called. And once you've finally identified the thing, the real work starts: emailing four suppliers, chasing the two who don't reply, checking what's actually available on your shoot date, and booking a viewing around a day that's already full. It's hours of coordination that produces nothing creative — the kind of work nobody went into film to do.

So we built an agent that does both halves. Describe the item in plain language or just show a photo, and it works out what it is, who has it, and then goes and does the boring part: writing to suppliers, tracking who replied, and putting the viewing in your calendar. The art director makes one decision instead of forty small ones.

What it does

What's the Name? is an AI agent for film production art departments. A user can:

Describe an item in plain language, by voice, or by uploading a photo
Get matched against a real inventory catalog, with photos, tags, warehouse/supplier, and distance
Ask the agent to draft and send a real inquiry email to the supplier
Ask the agent to schedule a real pickup/viewing appointment on Google Calendar
Track whether a supplier has replied to an inquiry, right from the sidebar (Unread / Replied)

Every one of these steps is genuinely functional — the agent really queries a live database, really sends email, and really creates calendar events. Nothing here is a mockup.

How we built it

Gemini, orchestrated through Google Cloud's Agent Development Kit (ADK), is the reasoning engine. It interprets natural language, voice transcripts, and uploaded photos, and decides what to do next.
ClickHouse Cloud stores our catalog (75 real props, each with tags, category, warehouse, availability, distance, and a real photo). The agent queries it through the official ClickHouse MCP server (mcp-clickhouse) — Gemini writes the actual query itself at runtime.
A lightweight FastAPI backend serves the browsable catalog and notification data directly from ClickHouse, separate from the conversational agent.
Gmail API and Google Calendar API (OAuth) let the agent take real action — sending inquiries and booking appointments — not just talk about doing so.
A reply-tracking system checks Gmail threads for new messages and updates each inquiry's status automatically.
The React frontend has a resizable three-panel layout (chat history/notifications, chat, catalog), an onboarding screen, voice input via the Web Speech API, and photo upload for visual search.
Everything is hosted on Google Cloud: the frontend on Firebase Hosting, both backend services on Cloud Run.

Challenges we ran into

Cloud Run's buildpack naming quirk — our agent auto-detects its own "app name" from the folder it's running in, which is setsource locally but workspace inside a Cloud Run buildpack container. Took real debugging to catch.
Dependency version conflicts — pinning every package too aggressively caused cascading pip/uv resolution failures between google-cloud-aiplatform and google-auth; the fix was pinning only the packages that actually needed it and letting the rest resolve naturally.
OAuth scope changes require full re-consent — adding Gmail read access after the fact meant regenerating tokens carefully across both local and deployed environments.
ClickHouse's asynchronous mutations — ALTER TABLE ... UPDATE doesn't apply instantly, which we had to account for when checking/updating inquiry status.
Multi-instance session state — Cloud Run can spin up more than one container instance; without pinning to a single instance, an agent session created on one instance wouldn't exist on another.

Accomplishments that we're proud of

A real, working multi-step agent — search → reason → act (email/calendar) — not a single API call dressed up as a chatbot
Genuine, verifiable ClickHouse MCP usage at runtime, satisfying the hackathon's core technical requirement
A fully cloud-hosted, judge-testable product with no local setup required

What we learned

How to build and debug a real multi-tool agent end-to-end with Google's Agent Development Kit, how MCP servers bridge an LLM to a real database, and a lot about the operational realities of running agentic workloads on Cloud Run (cold starts, instance scaling, dependency pinning).

What's next

Per-user Google sign-in (currently blocked by Google's app verification process for our short hackathon timeline)
A seller-facing portal so suppliers can manage their own listings
Expanding the catalog with more real supplier data