Inspiration
We kept coming back to the same production problem: the screenplay says what should happen, but the plan for making it happen lives everywhere else.
A producer may have scene notes in one document, location research in ten browser tabs, prices in a spreadsheet, permit rules in a PDF, and the latest decision buried in a chat. That setup is annoying on a small shoot and risky on a larger one. Change one location and the schedule, budget, access needs, and paperwork can all change with it.
SceneAtlas started as an attempt to keep those relationships visible. We wanted the screenplay itself to be the starting point, then let every location choice, constraint, source, open question, and team decision stay connected to the scene that caused it.
What it does
SceneAtlas turns a screenplay into a shared, evidence-backed production planning canvas.
A producer uploads a text-based screenplay PDF or pastes screenplay text. SceneAtlas reads it, keeps exact page-linked excerpts, finds the scenes, and asks for missing production details before it starts planning. It asks about facts that can change the result, such as the search area, shoot dates, crew size, equipment, scene duration, access windows, budget scope, and creative priorities. If the producer does not know something yet, SceneAtlas keeps it marked as unknown instead of filling the gap with a confident guess.
The screenplay becomes the root of an infinite canvas. Editable scene cards branch from it, along with saved answers and their scope. Producers can plan the full script or choose a smaller scene set. They can create several plan alternatives, and each one keeps its own budget cap, preferences, location choices, locks, costs, blockers, and schedule. A budget plan and a creative plan can use the same research without sharing the same decisions.
SceneAtlas researches real location candidates with Parallel Search and Extract. Each candidate includes the reason it fits the scene, known restrictions, fees when a source supports them, source excerpts, retrieval details, and anything that still needs a phone call or scout. Published prices, producer quotes, estimates, and unknown costs remain separate. Missing quotes do not become zero, and a research result never claims that a location is available, booked, or approved.
After reviewing the evidence, producers select and lock locations. SceneAtlas checks the chosen locations' requirements and builds a proposed shooting order from confirmed scene durations, allowed windows, daylight needs, location moves, and other constraints. Schedules are generated per plan, so one alternative can be retried or revised without disturbing another.
The canvas is collaborative. Owners can invite editors and viewers. Teammates see presence, cursors, selections, editing signals, and board changes as they happen. SceneAtlas keeps canvas movement separate from content revisions, which matters when two people edit the same workspace. A stale write fails without destroying the person's draft.
Material edits use a review flow. If a producer changes a start time, scene scope, or production answer, SceneAtlas shows the old and proposed input, marks the affected work as stale, generates a staged replacement, and applies it only if the underlying revision has not changed. Unrelated research and decisions stay intact. Undo uses the same revision checks.
At the end, SceneAtlas creates a preparation PDF and a matching JSON manifest. They contain scene-to-location assignments, proposed timing, cost bases, official source links, attachment checklists, unresolved questions, and the record versions used to build the packet. The document says exactly what it is: a preparation draft. It is not a permit submission and it does not claim approval.
How we built it
We used Antigravity as our development environment. SceneAtlas is a full-stack Next.js 16 and React 19 application written in TypeScript. React Flow powers the canvas. Tailwind CSS and Radix UI handle the interface, Zustand manages local interaction state, Zod validates data boundaries, PDF.js reads screenplay files, and ELK helps with graph layout.
Convex is the real-time backend and the source of truth for workspaces, membership, scene and plan records, revisions, dependencies, job state, presence, source metadata, and private file records. Clerk handles sign-in. Authentication alone is not treated as authorization, so every Convex query and mutation also checks board membership and role.
The agent workflow runs on Google Agent Development Kit. A coordinator routes work to focused specialists for screenplay breakdown, clarification, location research, requirements, scheduling, revisions, and packet generation. Gemini on Google Cloud handles screenplay understanding, focused question generation, natural-language constraint interpretation, and explanations.
We deployed the agent to Vertex AI Agent Engine. The web app signs a request to a Cloud Run bridge, which creates a durable Cloud Task for the managed runtime. Results return to Convex through signed callbacks. Google OIDC protects the worker route. HMAC signatures, five-minute validity windows, deterministic task names, separate service identities, and Secret Manager protect the rest of the path. Long research jobs can continue without holding a browser request open.
Parallel is the only web research provider in the application. Search finds candidate locations and relevant authorities. Extract reads useful passages from the public pages and PDFs that Search returns. SceneAtlas stores the request reference, retrieval time, cache state, URL, and bounded excerpt with each source. Generated results may cite only URLs returned by that research. Official pilot requirements must come from California Film Commission guidance or the named location's own official page.
We kept calculations outside the model where deterministic code is a better fit. That includes schedule construction, cost totals, shared-charge deduplication, dependency invalidation, revision checks, and PDF and JSON generation. Python and FastAPI power the bridge and agent-side helpers. ReportLab builds the PDF. The frontend runs on Vercel, while the agent runtime and transport run on Google Cloud.
Challenges we ran into
Grounding took the most work. Location and permit pages often mix useful facts with broad marketing copy, outdated snippets, and rules for several types of shoots. A result can sound completely reasonable and still attach the wrong fee or restriction to a location. We added validation that checks important claims against the saved passage for the applicable source. Monetary amounts, requirement details, addresses, phone numbers, and other precise facts must occur in that evidence. If support is missing, SceneAtlas leaves the item unresolved.
Feature-length screenplays created a second problem. Sending an entire script through one request is unreliable, but publishing half a breakdown is worse. We built page-aware indexing, bounded scene batches, saved-batch retries, and atomic publication. The canvas also switches to a compact scene grid and renders only visible cards on large boards. We tested this with the complete 124-page Big Fish production screenplay. SceneAtlas found all 202 scenes across 34 batches, and it recovered after a deliberate interruption.
Collaboration made revision handling more complicated. Card positions change often, while production choices can invalidate research, costs, schedules, and documents. We split geometry revisions from entity revisions and built dependency-aware regeneration. New output is staged before it replaces current output. An older run cannot overwrite a newer producer decision.
Cost language was surprisingly hard too. A published hourly rate does not prove how many hours will be billed. A quoted charge may cover several scenes. Two currencies cannot be added without an exchange rate. We model published, quoted, estimated, and unknown values separately and keep the basis visible. A plan with missing prices can still be useful, but it cannot claim confirmed budget compliance.
Accomplishments that we're proud of
SceneAtlas now covers the full path from screenplay upload through clarification, scene generation, location research, requirements review, plan comparison, scheduling, revision, and packet export.
The hosted workflow has completed real runs through Vertex AI Agent Engine and Parallel Search and Extract. We verified screenplay ingestion, questions, editable scenes, sourced candidates, selected-location requirements, provisional schedules, and authenticated PDF downloads. Saved evidence includes actual search references and retrieval metadata rather than sample citations.
We also tested collaboration with separate owner, editor, and viewer sessions. Invites, presence, synchronized edits, reload persistence, and server rejection of viewer writes all worked in the hosted application.
The scale result is the part we are happiest about. The 124-page screenplay test produced 202 usable scene records across 34 saved batches. It also proved that the recovery path works when processing stops before publication. That moved SceneAtlas beyond a polished sample and into the shape of a tool that can handle a real script.
What we learned
The most useful agent behavior is often a question. Production planning has too many facts that look inferable but are not. A drone in a scene does not mean the crew will fly one. A park page does not prove availability. A published rate does not prove the final invoice. Keeping script evidence, producer answers, retrieved facts, estimates, and unknowns separate made the product much more trustworthy.
We learned to treat provenance as application data, not decoration added to a final answer. A source needs to travel with the claim through research, selection, scheduling, revision, and export. The same is true for revisions and dependencies. Once those relationships are stored explicitly, the product can explain what changed and avoid throwing away work that is still valid.
We also learned that agent UX depends on durable job state. Research may take time, two plans may run together, and one scene may need an answer while another can continue. Queued, running, waiting, failed, stale, and complete are product states, not loading-message copy. Modeling them directly kept the canvas responsive and made failures easier to recover from.
What's next for SceneAtlas
The current official-source pilot focuses on California state-property permitting. We want to add more jurisdictions and authority-specific form drafts, along with OCR for scanned screenplays, production calendar connections, and better travel-time data.
We also want one downloadable review bundle containing the preparation PDF, JSON manifest, saved evidence, and relevant official forms. Beyond that, the same scene-linked record can support scout follow-ups, confirmed quotes, availability checks, permit preparation, and the handoff to department heads.
SceneAtlas will keep the same rule as it grows: useful planning should not hide uncertainty. A producer should be able to see what came from the script, what the team decided, what a source supports, and what still needs to be checked.
Log in or sign up for Devpost to join the conversation.