Release Command Center

Agents watch a release live in ClickHouse, diagnose freezes or breakout scenes with Gemini, draft a fix, and measure whether it actually worked — not just recommend and forget.

Comment

Inspiration

Streaming and studio teams sit on a firehose of viewership, engagement, and social data, but the actual review process is still manual and slow; someone checks a dashboard once a day, and by the time a problem is spotted, the damage is already done. In film production, "dailies" are the raw footage from a day of shooting, reviewed immediately so a director can catch a problem while there's still time to fix it. Nobody does that for how a release is actually performing after launch, so I built the system that would.

I also looked at what streaming platforms are actually doing with AI right now before designing anything: churn prediction, quality-of-experience anomaly detection (buffering, startup time, error rate), content performance forecasting, and, closest to this project, automated trailer and clip creation, which nearly half of surveyed media executives named as AI's most immediate impact on their industry. That told me the direction was right; the job was building something real enough to prove it, not just a mockup of the idea.

I'm entering solo, against teams of up to four, so instead of trying to out-build a team, I tried to out-verify one. Every feature in this submission was tested with real evidence before I trusted it, and several were caught failing and fixed before they ever reached a demo.

What it does

Dailies is a multi-agent release command center. Synthetic streaming telemetry, viewership events, engagement rollups, and social sentiment stream continuously into ClickHouse for a small slate of titles. From there:

A Watcher agent continuously checks for both risk signals (drop-off spikes, negative sentiment) and opportunity signals (unusually strong engagement, positive sentiment) across every title/episode/region/age-bracket segment, using ClickHouse materialized views and incremental rollups for near-real-time detection rather than repeatedly scanning raw events. A Strategist agent diagnoses why, correlating device type, exact timestamp clustering, and social sentiment to tell a technical playback failure apart from a creative pacing problem, and routes each accordingly. A Producer agent drafts a concrete action: an engineering escalation ticket for technical issues, or for a resonant creative moment, a ready-to-review amplify package, exact clip timestamps, three genuinely distinct social copy variants, and platform-specific notes. Every recommendation carries an expected-impact score computed from real historical outcomes (not an invented number), and a human reviewer approves or dismisses it with a structured reason, note, and their own confidence. An Outcome Tracker then measures what actually happened to the segment afterward, at fixed horizons, and feeds real measured results back into future diagnoses, so the system's confidence in a pattern grows (or shrinks) based on its own track record, not vibes. A Digest agent rolls each period into a plain-language executive briefing, a Forecaster projects a title's trajectory against the rest of the portfolio, and every agent decision is logged to a full, queryable audit trail. The whole thing runs across three titles at once, and, critically, stays completely quiet on the two healthy ones the entire time. That's not a coincidence; it's the actual proof the detection is selective, not noisy.

How we built it

The reasoning layer is Google's Agent Development Kit (ADK) with Gemini, using the official ClickHouse MCP server for read access; agents write through dedicated tool functions instead, since the MCP server is read-only by design. ClickHouse Cloud is the analytics backbone: raw events, per-minute AggregatingMergeTree rollups populated by materialized views on insert, a seed-only baseline reference table, and workflow tables for flags, diagnoses, recommendations, outcomes, human feedback, and decision provenance. The dashboard is Next.js, deployed on Vercel, reading and writing ClickHouse directly.

The full source is public: github.com/Mithilesh71320/cinema-hackathon-agent (MIT licensed). The live dashboard, showing real data from a completed test run and still open to manual approve/dismiss, is at agentic-cinema-dashboard.vercel.app.

One deliberate design choice runs through the whole system: not everything is an LLM call. The outcome tracker and the impact-scoring math are plain deterministic Python, partly because they don't need reasoning, just arithmetic over real data, and partly because Gemini's free-tier quota (500 requests/day) is a hard constraint that shapes real architecture decisions, not just an inconvenience to work around.

Challenges we ran into

Testing this rigorously surfaced real bugs, not just polish items:

A baseline-pollution bug where a rolling comparison window let a live anomaly contaminate its own "normal" baseline, which silently blocked the feedback-loop feature from ever proving itself. Fixed by anchoring baselines to the stable pre-release seed data instead. A genuine precedent-matching contradiction: an impact badge saying "no precedent" right next to recommendation text citing a real prior case with a specific recovery percentage, two features quietly using different matching logic on the same data. Fixed by unifying them into one shared matcher. Windows-specific reliability breaks: a Unicode arrow character crashing the digest agent's console output, and the outcome tracker dying silently on a ClickHouse schema-lock collision at startup, the second one especially dangerous, since it would have left an entire demo beat with no data and no visible error. The most important discovery came from planning the demo shoot itself: the second scripted incident gets diagnosed only ~86 seconds after a human approves the first recommendation, far too fast for any measured outcome to exist yet. That meant the planned "next case cites a measured recovery" beat was structurally impossible on that incident, no matter how the shoot was timed. Rather than fake it, the beat was rewritten around what the system actually, honestly does at that point: cite the human's approval reason and note, not a percentage it doesn't have yet.

Accomplishments that we're proud of

The thing I'm most proud of isn't a single feature; it's that almost every number on the dashboard is genuinely computed and checkable, not decorative. Confidence scores are real: a deliberately constructed weak, ambiguous case scored 0.40 against 0.95 for two clear-cut ones, proving the calibration isn't just habitually high. The outcome timeline shows a real case where the metric got worse before it got better, plotted exactly as measured, unsmoothed. Impact estimates say "no precedent yet" honestly instead of guessing when the data isn't there. And a feature that looked like an easy, impressive win, having Gemini "analyze" a staged video clip of a freeze, was deliberately cut, twice, because the honest answer to "is that footage real?" would have undercut the credibility of everything else.

What we learned

Technically: how to actually put ClickHouse's incremental materialized views and AggregatingMergeTree to work instead of using it as a plain datastore, and how to design an agent's tool access so writes and reads are deliberately separated for both safety and clarity. Beyond that: the biggest lesson was that rigorous, adversarial testing of your own system finds more real problems than adding more features does; five genuine bugs surfaced and got fixed specifically because every claimed feature was checked against real evidence before being trusted, not assumed to work because it was built.

What's next for Release Command Center

Scaling the ClickHouse-native detection layer to production event volumes, where materialized views genuinely outperform raw scans (at this project's demo scale, they don't yet, and that's disclosed honestly rather than oversold). Richer structured feedback taxonomies, a portfolio-level optimizer that reasons across the whole slate rather than one title at a time, and eventually real media-pipeline integration for the multimodal diagnosis this project deliberately held back on until it could be done with real footage instead of a staged one.

Built With

Share this project:

Updates

Submission history