BrightKin Studio Director

BrightKin Studio Director is an auditable production-intelligence system for film and episodic teams. Its Studio Mesh layer coordinates Director, Compliance, Greenlight, and Release specialists over a shared ClickHouse production memory, turning fragmented production events into evidence-backed decisions.

Built with ClickHouse — not a tag, the core of the system

ClickHouse Cloud is not a data store we bolted on for the hackathon requirement — it is the only database in this project, and every specialist's every answer is a live query against it. Specifics, so this is easy to verify against the repo (scripts/schema.sql, frontend/agents/tools.py, frontend/agents/clickhouse_client.py):

Append-only MergeTree log + argMax(x, ts) for "current state." production_events is ENGINE = MergeTree() ORDER BY (item_id, ts) and is never UPDATEd — every stage/status change is a new row. To answer "what stage is this track at right now," we don't maintain a separate mutable status table; we run SELECT item_id, argMax(stage, ts), argMax(status, ts), max(ts) FROM production_events GROUP BY item_id, which uses ClickHouse's argMax aggregate to pick each item's most-recent value directly from the immutable log. Tenant isolation enforced at the query layer, not the app layer. Every read and write is parameterized (clickhouse-connect's {name:Type} binding, never string interpolation) and filtered by a bound tenant_id column on both tables. A test suite (tests/test_tenant_isolation.py, tests/test_no_fstring_sql.py) asserts no query builds SQL via f-string/.format(). ClickHouse reused as the rate limiter, instead of adding Redis. rate_limit_events is a second MergeTree table with TTL ts + INTERVAL 1 DAY, deliberately built to auto-expire old rows. Every SQL statement any specialist runs is shown to the judge, live, in the UI — not simulated. The debug panel renders the exact parameterized query with bind values safely substituted, extracted from the agent's real tool-call trace at request time.

What it does — Studio Mesh, not just a chatbot

BrightKin Studio Director answers real questions about BrightKin (Everlight Chronicles), a fictional animated series production built for this hackathon, by routing through four specialists over one shared ClickHouse production memory:

Director — the entry point. Handles direct production-status questions (stage, schedule) itself by querying ClickHouse, or delegates to the specialist whose decision boundary actually owns the question. Compliance — checks an episode or track against BrightKin's documented standards: cast diversity (recurring characters must include a White, Latino, and Asian friend character), original-music-only policy, and camera-pacing variety (no repeated single camera angle across a scene sequence). Greenlight — combines the current stage and any blocking events into a GO/HOLD decision for whether an item can advance to its next production stage. Release — the final evidence gate: combines Compliance and Greenlight findings to decide whether an episode is actually ready to ship, not just whether one check passed.

Every answer is auditable, not just asserted. The UI shows which specialist handled the question, the Studio Mesh routing (e.g. "Director → Greenlight specialist"), and the exact ClickHouse SQL query executed to produce the answer — all extracted live from the agent's real tool-call trace, not a canned or simulated response. When a question references an item or standard the data doesn't cover, the agent says so explicitly (NO_DATA) instead of inventing a pass/fail or a status — this was verified directly against a request for a nonexistent episode.

Synthetic production snapshot, real query path: the ClickHouse tables are seeded with a dated, fictional production snapshot — RouteNote/Spotify-style distribution status for 11 example tracks, ElevenLabs-style publish status, and one pilot episode's state. This is explicitly example data, verified as a fixture set on 2026-08-01 UTC, not BrightKin operational evidence. What's real is the query path: every answer is grounded in a live ClickHouse tool call against this fixture data at request time, not a cached or invented response.

How it works

Runtime integration: ClickHouse is queried live at runtime via clickhouse-connect from every specialist's tool functions — not just referenced in docs. The agents run on Google's official google-adk package against the Gemini Developer API (gemini-flash-lite-latest), deployed as a Vercel Python serverless function alongside a cinematic Next.js/Tailwind frontend — an animated agent-network visualization, tilting glass panels, a guided onboarding tour introducing all four specialists, and a live chat console with the query-trace shown inline.

Includes a "Bring Your Own Show" mode: a tester can submit a couple of facts about their own fictional show and get the same Studio Mesh experience grounded in their own data, tenant-isolated from BrightKin's fixture tables via the tenant_id column and query-layer filtering described above.

Built entirely on free tiers — ClickHouse Cloud's 30-day trial, the free Gemini API tier, and Vercel's Hobby plan — with zero payment info entered anywhere.

Findings and learnings

Delegation only helps when each specialist owns a real decision boundary — the first two-agent version (Director + Compliance) worked, but "should this ship" questions had nowhere honest to go; adding Greenlight and Release as separate specialists, instead of stuffing more logic into Compliance, is what made a genuine evidence gate possible instead of a single overloaded agent pretending to be four. Showing the actual SQL, not a paraphrase, is what makes "auditable" true instead of a marketing word — early versions summarized the query in English, which meant a judge had to trust the summary; extracting the literal parameterized query from the tool-call trace removed that trust requirement entirely. ClickHouse's argMax pattern replaced what would have been a much more fragile "maintain a separate mutable status table kept in sync" design — worth calling out because it's the kind of ClickHouse-idiomatic choice that's easy to miss if you approach it as "just another SQL database."

Now vs. next — what's honestly not built yet

Compliance scope: today, one item_id checked per question. Next: a slate-wide sweep across every item in one pass. Agent writes: today, read-only — agents report findings, never log them. Next: agent-initiated inserts (e.g. auto-flag "pacing_review_needed"). Tenant isolation: today, a client-generated UUID in localStorage, no login. Next: real authentication gating each studio's rows. Data freshness: today, request/response — query runs once per question. Next: a live view that re-queries as new events land. Standards definition: today, three rules hardcoded as Python functions. Next: studio-configurable rules stored as data, not code.

Eligibility note

This repo's development used Claude Code (Anthropic) as a coding assistant. The hackathon's AI-usage restriction is written as a limitation on what the submitted Project runs at request time (Google Cloud AI + the ClickHouse partner integration only) — our runtime stack is 100% google-adk + Gemini + ClickHouse, verifiable in frontend/requirements.txt, with zero Anthropic (or any non-Google) AI package imported or called anywhere in the running app. Full reasoning, the exact rule text, and our dependency inventory are documented at docs/ELIGIBILITY.md in the repo.

Built With

• clickhouse
• clickhouse-connect
• gemini
• google-adk
• nextjs
• python
• react
• typescript
• vercel