Prime AI

Prime AI, a Studio Director and six specialist agents that plan the shoot, then re-plan it when the shoot falls apart.

Comment

Inspiration

Pre-production is where films quietly die.

A screenplay has to become a scene breakdown, a cast list, a location plan, a shooting schedule and a budget, and every one of those depends on the ones before it. Move a single day and the whole structure shifts. In practice this work is done by people under deadline pressure, in spreadsheets, at night.

That is exactly the shape of problem a team of agents should be good at: many separate specialisms, one shared body of state, and a human who has to stay in charge of the consequential calls. So we built the studio, not the chatbot.

What it does

Prime AI is an autonomous film studio. You give a Studio Director an objective in plain English. It decides which specialists the job needs, calls them, and reconciles what they report into one assessment.

Give it a screenplay and it will:

  • break it into scenes, characters and locations
  • derive production requirements, complexity and risks
  • research permits, locations and weather on the live web, with real citations
  • build a shooting schedule grouped by location to minimise company moves
  • cost that schedule into a budget
  • report a readiness percentage and the blocking issues behind it

Then the crisis demo. A real disruption is injected: the lead actor becomes unavailable, the location is released early, severe weather is forecast, all landing on a day the schedule actually uses. The agents re-plan, re-cost, check continuity against established facts, and put a recommendation in front of you. Nothing changes until you approve it.

On a real 17 scene screenplay, one run produced a nine day schedule across eight locations, an $870,375 budget, five risks and three researched findings with live citations, in 234 seconds.

How we built it

Seven agents on Google ADK's graph Workflow engine.

START -> director_planner -> script_ingest -> persist_breakdown
                                   |
                   +---------------+---------------+
                creative       production       research   (concurrent)
                   +---------------+---------------+
                                   v
                          analysis_done (JoinNode)
                                   v
                      scheduling -> finance -> director_synthesis
  • Gemini 2.5 Pro for the Director's planning and synthesis, Gemini 2.5 Flash for the specialists. Eight Pro agents in sequence is far too slow to demonstrate live.
  • Parallel's Search API for research. It is load bearing rather than decorative: the Research Agent refuses to save a finding with no real source URL, and reports "I could not check" instead of answering from memory when the key is missing.
  • FastAPI and Server Sent Events, because the agent collaboration is the product. It streams into the UI as it happens rather than appearing once everything finishes.
  • React 19 and TypeScript, with SQLite locally and Postgres in deployment behind one repository interface.
  • Cloud Run, a Neon Postgres in the same region, and a Netlify frontend.

The honesty principle

If the interface says an agent found something, that finding is in the database. Agents mutate state only through tools, and read endpoints return persisted state and nothing else.

Prompting alone does not achieve this, so the runner cross checks what agents claimed against what they actually stored and posts a visible warning when the two disagree. It fires in practice:

Finance reported $41,800 but the saved budget is $39,600. The figure was not persisted, so the saved budget is authoritative.

Most demos would have shown the $41,800 and nobody would ever have known.

Challenges we ran into

Agents were starved of the data they were asked to analyse. An ADK LlmAgent returns its result through session state rather than as a node output event, so the runner could only persist the screenplay breakdown after the whole graph had finished. Measured on a real upload: scheduling ran at 07:17:28, finance at 07:17:36, the Director synthesised at 07:17:55, and the scenes were not written until 07:18:06. All three queried an empty database and truthfully reported having no scenes. Persisting is now a graph node, sitting where the data dependency actually is.

A slow agent killed the entire run. ADK enforces a node timeout by raising, and that exception aborts the whole graph. Finance timing out took the objective with it, in one run out of three. Each agent now runs under its own deadline and degrades to partial work, and the report says which specialist did not finish.

The Director could not see what it was asked to verify. It reported "we have no schedule, locations, or cast" while a three day schedule sat in the database, because nothing in its toolset could observe one. Same state, before and after: 5% ready and wrong, then 40% ready and right.

A free container could not run the agents at all. Deployed to a 0.1 CPU instance, an identical single Gemini call took 2.3x longer than local and the planner blew past its 90 second budget, so the platform recycled the container mid analysis. Memory was the obvious suspect and the wrong one: resident memory held flat at 142.7MB of 512 throughout. Moving to Cloud Run, where the same call takes 1.14s, fixed it outright.

What we learned

That the hard part of a multi agent system is not the agents.

It is making sure they are looking at the same, real, current state, and that when one of them is wrong the system notices instead of narrating confidently past it. Every significant bug above was a variant of that one problem.

The second lesson was about diagnosis. Three separate theories for why the deployed analysis kept dying were all plausible, and all wrong. What settled it was instrumenting the container to report its own memory and timings, and the answer turned out to be the one thing nobody had measured.

Using it with other people

The hosted demo is a single deployment that several people open at once. Each browser gets an anonymous workspace id, so uploaded screenplays stay private to whoever uploaded them, with no account to create. The bundled demo film stays shared, and one analysis runs at a time, which is honest on a single vCPU where two concurrent runs would make both too slow to finish.

Try it

samples/the-drowned-bell.txt in the repository is an original screenplay written for testing, so you can exercise the whole pipeline without supplying your own. It also carries a deliberate continuity error for the recovery flow to catch.

The backend scales to zero, so the very first request after a quiet spell takes a few seconds to start the container. The interface says so while it happens rather than looking broken.

What's next

Casting and crew availability from real scheduling data, a proper diffing view between schedule versions, and multiuser review so a producer and a first AD can work the same board.

Built With

Share this project:

Updates

Submission history