ScriptOps

Inspiration

A screenplay change is never just a screenplay change. Moving one scene to a rainy night can affect the shooting schedule, budget, locations, crew, casting, permits, safety planning, and child-performer requirements at once. Producers usually manage those consequences by hand across disconnected spreadsheets, documents, and conversations, under deadline pressure.

ScriptOps began with a simple premise: a planning agent is only as trustworthy as the evidence behind it. Rather than generating a plan and asking producers to trust it, ScriptOps grounds production recommendations in current, checkable evidence and keeps a producer in control of every decision.

What it does

ScriptOps is a private, human-supervised pre-production workspace for film and media teams. A producer uploads a PDF or Final Draft screenplay, reviews the extracted scenes, and accepts the source material before any planning begins. From there, ScriptOps builds one connected production baseline made of five linked artifacts: a scene breakdown, shooting schedule, budget band, location recommendations, and casting briefs.

The core workflow is Revision Ripple. A producer selects an approved scene and describes a real change, such as moving an exterior sequence to a rainy night with a child witness and a controlled stunt. ScriptOps proposes coordinated updates across all five artifacts, with retained Parallel research evidence for the production constraints behind the proposal: permits, costs, child-performer rules, night-work limits, and safety considerations.

The approved plan never changes automatically. The producer inspects the full proposal, discards it, or explicitly approves it as the next immutable plan version. Every approved version is retained in history and can be exported as a production PDF.

How we built it

ScriptOps is a Next.js, React, TypeScript, and Zod application hosted on Google Cloud Run. Google Cloud provides the durable production workflow: Firestore stores project state, jobs, proposals, and immutable approved plan versions; Cloud Tasks runs bounded asynchronous planning stages with OIDC-authenticated worker delivery, leases, and retry handling; Cloud Storage holds private screenplay sources and owner-scoped production-PDF exports; Cloud Scheduler runs reconciliation and cleanup; Vertex AI Gemini generates structured planning output through Google's Agent Development Kit and the Google Gen AI SDK; and Secret Manager keeps provider credentials server-side.

For the Parallel track, ScriptOps actively calls the Parallel Search API at runtime through the official parallel-web TypeScript SDK. Parallel supplies current, cited evidence for real production constraints including permits, locations, budgets, night work, child performers, vehicles, and safety. ScriptOps validates and retains that evidence before it can inform a plan.

The build followed the same philosophy as the product: design the decision points before writing code. Before implementation began, we worked through the state machine, concurrency rules, and failure behavior in detail: what happens on a double-click, a dropped connection, a mid-flight reset, or concurrent approval attempts. The difficult consistency rules became architectural decisions rather than patches added after something broke.

Challenges we ran into

The hardest challenge was making the agent workflow safe enough for a real production decision. Screenplays are messy inputs, so PDF and FDX parsing needed source-linked scene review, correction support, and explicit warning acknowledgement before planning could begin.

The durable-execution model also changed shape mid-build. We originally planned to use Next.js's after() primitive to detach work from the request that started it. Closer inspection of how autoscaling infrastructure treats a completed response showed that it was an unsafe place to run a multi-minute, multi-agent job. We moved to Cloud Tasks with leases, retries, and idempotency instead: more infrastructure, but a much more reliable foundation for durable planning work.

Live provider testing surfaced its own quirks. A newer Gemini model did not accept the thinking and temperature configuration we had planned for, and an overly strict structured-output schema produced HTTP 400 responses until we relaxed the transport schema while keeping strict validation in our own code. Rate limits required bounded, deliberate retry behavior instead of simply reissuing requests.

The hardest problem was not getting a model to produce a plan. It was catching where a fluent-sounding plan quietly crossed from fact into assumption. Review runs caught the model inventing details the source script never stated and turning a producer's shoot-length preference into something that read like a legal requirement. That pushed us to separate source facts from generated assumptions explicitly and to require evidence that supports the relevant production constraints, including deduplicating equivalent government-source URLs.

Accomplishments that we're proud of

We are proud that approval is atomic: a producer either approves a complete five-artifact plan version or the existing baseline stays intact. Idempotency, stale-write protection, durable jobs, and immutable version history are enforced at the state boundary rather than left to browser behavior.

We are also proud that Parallel is a meaningful runtime dependency rather than a decorative integration. Its research changes the planning context and is retained alongside the proposal; it is not just named in a README.

Finally, we did not declare the project finished once the demo looked good. We built a verification pass against the deployed environment covering authentication boundaries, multi-version approval, archive and restore, and confirmed data deletion. We are also explicit in our documentation about what is pilot-ready and what still needs further validation before we would trust it with someone else's production.

What we learned

We learned that an agent for production planning needs more than a good prompt. It needs durable state, trustworthy evidence, clear failure boundaries, and a human decision point. Durability has to be designed in from the start for an agentic workflow with real cost attached; retrofitting exactly-once behavior onto a system not built for interruption is much harder.

We also learned that source traceability matters more than we initially expected. Producers need to understand what the system saw, what it assumed, what evidence informed a recommendation, and exactly what will change before they approve it. Most of our hardening effort went into building that visibility rather than making the model's output sound more elaborate.

Good agent UX is making complex work understandable without hiding uncertainty or taking control away from the person who has to answer for the decision.

What's next for ScriptOps

The immediate next step is a small private pilot with production-sized screenplays and additional collaborators. We will expand feature-length ingestion coverage, exercise recovery and collaboration workflows under real use, broaden research coverage by region, and make evidence gaps more visible to producers.

Longer term, ScriptOps can become a production-control layer for the work that follows a screenplay change: schedules, budgets, department handoffs, vendor assumptions, and approval-ready documentation that remain traceable to both the screenplay and the evidence behind the plan.

The standard for a wider pilot remains the same one we held ourselves to for this submission: do not call it ready until there is real evidence that it is.

Built With

• clerk
• cloud-scheduler
• cloud-storage
• cloud-tasks
• firestore
• gemini
• google-adk
• google-cloud-run
• google-gen-ai-sdk
• next.js
• parallel-search-api
• parallel-web
• react
• react-pdf
• secret-manager
• typescript
• vertex-ai
• vitest
• zod