AI-Native Short Drama Production Factory
The headline
Hand-conforming the rushes for a 30-episode series costs about 90 hours. This pipeline exports the cloud storyboards straight out as an .fcpxml, so the editor opens a DaVinci project and that step is gone.
30 episodes × 3 hours an episode = about 90 hours. The 3 hours an episode is a post-production experience baseline, not our measurement; 30 × 3 = 90 is arithmetic on top of it. This is not "how many times faster" — the step is gone.
What you are buying
ReelForge OS runs one series through five stages — script, assets, storyboard, director, marketing — as a single line: the images and the voice tracks are generated in the cloud, and one local export hands back a DaVinci or FCPX project the editor can refine directly. You are not buying another generation tool. You are buying a line that can carry a long run; 30 episodes is the design capacity, not a measured output.
What this replaces
- Thirty episodes of rushes land and the editor does not cut: they download, sort, rename, and line each shot up against the timeline one by one. 30 episodes × 3 hours an episode is about 90 hours, and 3 hours an episode is a post-production experience baseline rather than a timing we took. None of it is creative work, and the schedule cannot spare a single one of those hours. That is where the air date goes.
- Script to storyboard to image to video is a serial chain: when an earlier step is wrong, everything rendered after it is waste. There is no approval gate in the chain, so the reject rate turns straight into an API bill. A character also loses its face between episodes, and the rework restarts from episode one. The invoice arrives before the progress does.
- The assets are loose, so problems only become visible once they are in the timeline — and fixing one episode means running the whole chain again. Design target, not measured: generation, voice, music and assembly for a single episode moving asynchronously, so a 30-episode run can be produced in batch. This is a design goal. It has not been tested and it is not a commitment.
Architecture
A metro-map wireframe in three segments left to right — Trigger, Brain, Action — with a thin band across the top carrying the state machine spine Story → Assets → Storyboard → Director → Marketing. Two marks are drawn into the chain: the HITL gate, where the main arrow from Trigger to Brain is broken until a human releases the script, and a bypass arrow inside Brain where a CACHE_HIT pulls the cached asset instead of calling the model again.
Guardrails
- Script approval is a mandatory node on the LangGraph graph (AWAITING_PLOT_APPROVAL). Nothing downstream generates until a human releases it, so a bad episode is blocked before it is rendered rather than discovered through the API bill.
- CACHE_HIT reuses assets. search_database_record and RAG retrieval decide whether the scene or the character has changed; when neither has, the cached asset is pulled and the expensive model call never happens. How many calls that saves is countable — this card does not invent a number for it.
- MultimodalAdapter absorbs the API differences. Flux, Midjourney, Kling and Runway differ at the interface; the adapter is the only place that knows it. The layer above speaks standard_ratio and a generic payload, so swapping an underlying model never reaches business code.
- Network failure is expected, not fatal. _download_file retries downloads with exponential backoff, upgrade applies blueprint upgrades offline, and a scan of the local directory rebuilds the mapping — so a dropped connection still ends in an offline remix.
- The export is a project file, not a folder of clips. FCPXMLExporter writes the storyboard — camera instructions and millisecond audio alignment included — out as an .fcpxml project, and AnimaticEngine renders a preview cut first.
What you end up holding
- LangGraph multi-agent orchestration network — the node prompts, the router logic and the checkpointer configuration.
- MultimodalAdapter and skill plugin library — standardised Python SDKs for image generation, TTS, BGM matching and RAG retrieval.
- Forge Local Client — the engine_compiler rendering engine, an interactive CLI, and the DaVinci FCPXMLExporter.
6 to 8 weeks. A planning range, not a contract commitment.
Stack
- Orchestration
- LangGraph (master_graph state machine + PostgresSaver checkpointer) · FastAPI gateway · Celery + Redis async queue · MultimodalAdapter skill plugins · LLMs routed through a gateway (OpenAI / Qwen / Claude)
- Data
- PostgreSQL (Prisma) · Qdrant vector store for character DNA and asset retrieval · Cloudflare R2 object storage for cloud episode assets
- Delivery
- FFmpeg (Ken Burns moves, BGM fades, timestamp-burned subtitles) · Python Rich CLI · DaVinci / FCPX (.fcpxml project) · multimodal engines Flux / ElevenLabs / Kling / Runway, all behind the adapter
The figures, with their arithmetic
- About 90 hours of conforming for a 30-episode series
- 30 episodes × 3 hours an episode. The 3 hours an episode is a post-production experience baseline, an outside value, and 30 × 3 = 90 is arithmetic on top of it rather than a timing we took. Export the .fcpxml and the conform step disappears, so the editor no longer spends those 90 hours.
- One export step — an .fcpxml the editor opens in DaVinci or FCPX
- Not an estimate but a code fact: FCPXMLExporter writes camera instructions and millisecond audio alignment into the file. The deliverable changes from a pile of loose rushes to a project the editor opens and refines.
- CACHE_HIT asset reuse — no repeated expensive model calls
- A code fact: if the scene or the character is unchanged, the cached asset is pulled and the main path never reaches the model. The calls saved are countable — this period we are not filling in a number. What is saved is API spend, and that spend used to grow along with the reject rate.
- 30-episode batch production — design capacity
- A design capacity across the full Phase 1 Story → Phase 5 Marketing chain, and it has not been measured. It is the volume a serial manual process cannot finish.
The same shape, three other problems
This is the part that matters if the featured use case is not yours: the same architecture pointed at three unrelated situations, none of them a variation on the case above, and none of them requiring a rebuild. These are transfer directions rather than delivered engagements — the system above is what we have run, and the three below are what its shape solves next. We label the difference rather than blur it.
Automated audiobooks and motion comics
feed in a web novel, and the line splits the chapters itself, pulls the character dialogue out and assigns each character its own TTS voice, and generates background illustrations to follow the plot.
Corporate training video factory
turn a compliance document or a product manual into shot lists and lines, a digital presenter or TTS narration, and illustrations with BGM.
Game narrative asset pipeline
generate NPC portraits, environment concept art and timestamped voice clips in batch from a world setting and a plot tree, and import them into Unity or Unreal through a JSON manifest.
Have a system that needs building?
Write down the situation. You get a written, specific response: no calendar, no discovery call, no fifteen minutes of introductions.
Status
Built in-house. This is a production line we built for ourselves — not a client case and not a product delivered to anyone, and no external organisation runs it. It proves we can orchestrate a multi-agent system. It is running in our own stack.
Built in-house. Running in our own stack.