We built our own SDK. Then we threw it away.
Before our footage pipeline was a system, it was three Python files we wrote ourselves. This is the story of how they grew into ninety-eight loose scripts, why that pile collapsed under its own weight, and what replaced it.
Three files, one discipline
The first version was honest engineering. A hand-rolled client for the image model with exponential backoff and a polling loop. A batch processor that ran parallel jobs from JSON and dropped a cost report at the end. A reference manager that cataloged every image and refused to let one into a prompt until it had been looked at in full resolution.
One rule from that era survived everything since: never compose references into a single image, never downscale, always preserve full quality. Reference fidelity was the whole ballgame, and we knew it from day one.
Every new model meant a new manual
The toolkit could not just plug in a new model. Each one needed its own hand-written prompting conventions, so five prompting skills became ten. Each client needed a knowledge file, so one became sixteen.
And every big production run meant a new throwaway script. A sixty-shot run fired at ten concurrent workers was its own bespoke file: hardcoded aspect ratio, reference URLs pasted straight into the code, three prompt files stitched together by hand, a hand-rolled progress bar. It worked. And none of it was reusable.
What actually broke
Context lost between sessions, because nothing persisted a project's state. Prompts lost on rework, because nothing tied an output back to what made it. Versioning by folder duplication, so one shot series ended up as three sibling folders named v5, v6, and v7.
Ninety-eight loose scripts sat in the workspace root, each one a single job's orchestration frozen in time. And four different stores all claimed to be the memory: a global JSON blob, sixteen per-client knowledge files, an upload cache, and the session memory of the agent itself. Four places to check to answer one question: what has this project already learned?
The scripts worked. The operating model did not.
Not a rewrite. A different operating model.
The rebuild started with a forensic pass over the old workspace and two real productions, and the architecture was agreed in a design doc before a line of code. The new system did not rewrite the scripts. It deleted the reasons they existed.
One project tree instead of scattered folders. Eight commands instead of one-off scripts. Chained single-purpose skills instead of a flat pile of manuals. One unified generation engine instead of a client per model. And the big one: a sidecar record on every single output, holding the prompt, the references, the model, the cost, and the full history, plus one living status document per project. Four memories became one place to look.
Version one
Each production carried its own orchestration. Prompts disappeared on rework. Folders became version control. Four places could answer one question differently.
Version two
8 commands, 8 chained skills. One living status doc per project. Provenance sidecar on every output. Nothing forgets.
What the rebuild produces
Two versioned start frames from an internal production on the new system. Each file carries its full recipe in a sidecar, so version two knows exactly how version one was made.
The discipline was the deliverable
The code was disposable. The rules it taught us were not. Prompts never get dumped into chat, they live in the provenance record. Video never generates from a blank text prompt, it always starts from an approved image. No pipeline step gets silently skipped because it is tedious.
That is the real story of the rewrite. The tools we outgrew were never the product. The discipline they forced on us was.
Fighting your own pile of scripts?
If your AI workflow is held together by one-off scripts and four kinds of memory, we have been exactly there. Fifteen minutes and we will tell you what the way out looked like.
Book a 15 minute call