Inspiration
Film and TV productions run on razor-thin margins and tight schedules, but the operational problems that can disrupt both are often surprisingly easy to miss: a scene quietly going over budget, an actor accidentally double-booked at two locations on the same day, or a prop changing unexpectedly between takes.
The problem isn't necessarily a lack of data. Production teams have plenty of it. The challenge is that someone has to continuously notice these patterns across schedules, budgets, scene records, and continuity data—and then figure out what they actually mean.
When I saw the Director / Technical Producer / Studio Head framing in the hackathon brief, it clicked. This was exactly the kind of problem where multi-agent orchestration could make sense. Instead of building another chatbot connected to a database, I wanted to build a system that mirrors the structure of a real production team, giving each agent a distinct responsibility.
That idea became StudioGuard: an AI-powered production monitoring and decision-support system that detects operational issues, reasons about their real-world impact, and keeps humans in control of the final decision.
What it does
StudioGuard watches production data for problems that a human team might otherwise discover too late.
It works as a three-agent pipeline:
🎬 Producer Agent — Detect
The Producer Agent queries ClickHouse for raw signals in the production data.
It detects:
- Budget overruns — scenes where spending exceeds the allocated budget by more than 10%.
- Schedule clashes — the same actor booked at different locations on the same date, detected using a SQL self-join.
- Continuity breaks — unexpected changes in a prop's state between takes, such as a prop being present, then missing, then present again.
The Producer Agent focuses on finding evidence rather than interpreting it.
🧠 Director Agent — Reason
The Director Agent takes those raw signals and sends them to Google Gemini.
Its job is to turn database findings into something a production team can actually understand and act on.
Rather than returning generic recommendations like "review the schedule," Gemini is instructed to use the actual scene IDs, dates, locations, and numbers from the dataset to explain:
- What happened
- Why it matters operationally
- How serious the issue is
- What concrete action could fix it
This makes the AI reasoning grounded in the production data instead of being generic LLM output.
🏛️ Studio Head Agent — Govern
The Studio Head Agent provides the governance layer.
It reviews the reasoned findings, routes high-severity issues for immediate attention, and—most importantly—does not allow the AI to resolve issues on its own.
Every finding requires an explicit human decision through the dashboard:
Approve or Reject.
That decision is then recorded in an audit log.
This was an important design choice for me: AI can detect, explain, and recommend, but the human remains accountable for the final production decision.
The Dashboard
I wanted the interface to feel like a production control room rather than a generic admin dashboard.
When the user clicks Run Review, the complete agent pipeline runs and the dashboard displays a live, step-by-step trace showing what the Producer, Director, and Studio Head agents are doing.
The dashboard includes:
- 🔎 Live multi-agent execution trace
- 🚨 Findings categorized by high, medium, and low severity
- 💡 Plain-language explanations and concrete suggested fixes
- ✅ Approve / Reject human-review controls
- 📋 Visible decision and audit log
- 📊 Allocated vs. spent budget visualization
- 💬 AI chat for asking questions about the production data
The chat interface also allows users to ask questions in natural language, such as:
"Which scene went most over budget?"
The answer is generated using the actual production dataset rather than relying on the model's general knowledge.
How I built it
StudioGuard is built with Python and Flask on the backend, with ClickHouse Cloud storing the structured production data, including scenes, budgets, schedules, locations, actors, and prop states.
I used the clickhouse-connect library to query the database and Google Gemini through the google-genai SDK for reasoning and natural-language interaction.
The frontend uses HTML, Tailwind CSS, and Chart.js, with a cinematic dark interface inspired by a film-production control room.
A key architectural decision was keeping the three agents deliberately separated into their own responsibilities:
Producer → queries data Director → reasons about findings Studio Head → governs decisions
This separation means the system isn't one large prompt trying to detect, interpret, and resolve everything at once. Each stage produces an explicit output that can be traced through the pipeline.
I also built a local SQLite fallback with the same function signatures as the ClickHouse client. This allowed me to iterate quickly on the agent logic and dashboard locally before connecting everything to the real ClickHouse Cloud instance.
The demo dataset is synthetic and contains 15 production scenes plus a props/continuity table. I intentionally included a budget overrun, a genuine scheduling conflict, and a continuity break so the system has real anomalies to discover during the demo.
Challenges I ran into
Keeping AI reasoning grounded
One of the first problems I encountered was that the Director Agent could produce explanations that sounded reasonable but were too generic—for example, simply saying "review this scene."
I had to refine the Gemini prompt to require the model to reference specific scene IDs, dates, locations, and financial numbers from the detected signal. This made the output much more useful and helped prevent the AI from inventing context that wasn't present in the data.
Handling concurrent local requests
My SQLite fallback initially shared one database connection across Flask request threads. During local testing, this caused intermittent threading errors.
I eventually traced the issue to SQLite's thread restrictions and configured the connection with check_same_thread=False. That small debugging experience also reinforced how different local development behavior can be from a production database such as ClickHouse Cloud.
Dealing with a changing AI model
During development, the gemini-2.5-flash model became unavailable to new API keys, which I discovered through a live 404 response.
Instead of scattering the model name throughout the application, I made the model configurable in one place. That made it much easier to switch models without rewriting the agent logic.
Making schedule conflicts meaningful
A simple check for "same actor + same date" wasn't enough.
An actor could legitimately appear in multiple scenes on the same day if those scenes were being filmed at the same location. The meaningful conflict was when the same actor was booked at different locations on the same date.
Expressing that distinction cleanly required a SQL self-join and made the detection logic much more representative of a real production scheduling problem.
What I learned
Building StudioGuard taught me that effective agentic systems aren't necessarily about giving an LLM more control. They're about giving AI the right responsibility.
Structured database queries are better at reliably detecting measurable conditions. An LLM is better at interpreting those signals, explaining their impact, and communicating possible actions. Governance logic then determines what the system is actually allowed to do.
That led to the core principle behind StudioGuard:
Detect with data. Reason with AI. Decide with humans.
For me, that's what makes the project more than an AI chatbot. It's an experiment in building an auditable, multi-agent workflow where AI adds intelligence without removing human accountability.
Log in or sign up for Devpost to join the conversation.