The annoying part of AI video for me was never getting a clip.

It was what happened when clip #2 broke.

The character drifted, the motion was wrong, or one prop randomly duplicated itself. Then I’d start changing prompts, regenerate things that were already fine, and eventually lose track of which version was supposed to be the “good” one.

So I wanted to try something different: treat AI video less like one giant generation and more like an actual production pipeline.

I cloned the open-source OpenMontage repo, used Codex to work through the pipeline, and tested it on a small 20-second story about a stray cat that keeps waiting outside the same door after its owner is gone.

The story ended up as four beats:

WAIT → MEMORY → ONE YEAR → SEEN AGAIN

No subtitles or on-screen text. Just four motion shots and two very short English voice lines.

\[Image 1: four-act keyframes — WAIT / MEMORY / ONE YEAR / SEEN AGAIN\]

The useful part wasn’t really the cat film though. It was finally separating the different jobs.

Codex handled the creative reasoning: turning the brief into a story, deciding what each shot needed to communicate, writing the scene plan, and figuring out what should be regenerated when something failed.

OpenMontage handled the production state: research, proposal, script, scene plan, assets, edit, compose, publish. Each stage had its own files and checkpoints instead of everything living inside one giant prompt.

Atlas Cloud sat underneath that as the model layer.

And the final timing, sound mix, transitions, render, and QA stayed local in Remotion + FFmpeg.

So instead of:

prompt → video → hope

it became something closer to:

brief → proposal → script → scene plan → assets → edit → compose → QA

\[Image 2: simple architecture diagram — Codex → OpenMontage → Atlas Cloud → Remotion/FFmpeg\]

One thing I liked about this setup was that we made the creative decisions before burning the expensive generation calls.

The proposal already defined the four-beat structure, target runtime, continuity rules, and what the ending was supposed to mean.

For example, the red scarf and the food bowl weren’t random visual details. They became continuity anchors so the final scene with the granddaughter didn’t just feel like “some new person suddenly appears.”

\[Image 3: proposal / scene-plan screenshot\]

For generation, I also stopped going straight from text to four unrelated video clips.

First I used Nano Banana 2 through Atlas Cloud to generate a visual anchor for the cat and doorway. That locked things like the tortoiseshell coat, chipped ear, old teal door, steps, and food bowl before doing the more expensive motion generation.

Once that anchor looked right, OpenMontage uploaded it and used Seedance 2.0 for the four image-to-video shots.

The two narration lines were generated separately with xAI TTS v1:

She waited through every season.

Until someone finally saw her.

All three remote model types went through the same ATLASCLOUD\_API\_KEY.

That didn’t magically remove the engineering work. OpenMontage still had separate image, video, and TTS adapters, and Codex still had to decide which model to use.

What it did remove was having to maintain separate auth, accounts, request formats, polling logic, and result handling for three different model providers.

\[Image 4: asset\_manifest screenshot showing model IDs / generated assets / cost metadata\]

The part that changed how I think about retakes was scene-level isolation.

Scene 02 had a duplicated food bowl in one version. Another attempt later produced an extra hand.

But that didn’t mean restarting the whole 20-second film.

The bad versions stayed in history, we kept the usable section, and the final selected asset became its own scene-02-memory-select.mp4.

Everything else stayed untouched.

That sounds obvious, but it’s a very different mindset from repeatedly asking one model to regenerate “the video.”

The generative layer can be probabilistic. The delivery pipeline doesn’t have to be.

After asset approval, the cloud generation part was basically done.

Remotion put the four shots onto a deterministic 480-frame timeline at 24fps. FFmpeg handled the native ambience, voice placement, ducking, loudness normalization, and final media checks.

The final output was \~20 seconds, 1280×720, four real motion shots, no subtitles, and no on-screen text.

\[Image 5: OpenMontage production-proof / terminal summary\]

The Atlas Cloud account ended up showing about $5 in cloud-generation spend for the project. Video generation was by far the expensive part; the image anchor and TTS were comparatively tiny.

That reinforced another thing I’d keep if I build this again:

approve cheap, inspectable assets before triggering expensive ones.

A rough frame is cheap to reject. A completed video generation isn’t.

The other lesson was that “one API key” is useful, but not for the reason marketing copy usually makes it sound useful.

It doesn’t turn the whole production into one request.

It just gives the workflow one consistent inference layer while the planning, approvals, asset history, selective retakes, editing, and QA stay explicit.

\[Image 6: final QA / render summary or final-film still\]

So for me this ended up being less of an “AI made a film” experiment and more of a workable way to structure AI video production:

plan first, generate second;

approve cheap assets before expensive ones;

keep failures local instead of rebuilding the whole project;

and separate probabilistic model output from deterministic delivery.

It’s obviously not replacing a full production team, but for a solo builder or small team it felt a lot more controllable than one-prompt-one-video workflows.

This setup is built around the open-source OpenMontage project. If agentic video pipelines are your thing, the repo is here:

https://github.com/calesthio/OpenMontage

I stopped asking one model to make a short film and built a real production pipeline instead