Keeping AI video clips consistent: a shared ledger, a checker and a cache

In part 1 I covered how PromptMotion's engine went from one overloaded prompt to a team of specialist agents that look up film craft from a knowledge base. That version wrote far better shots.

It also exposed a problem I hadn't thought about properly. Each shot was good on its own, but the shots didn't agree with each other. And every fix I added made each run cost a little more. This post is about solving both.

Throughout the diagrams below, the colours mean the same thing:

V4A shared memory, and someone to check it

This version came straight out of user complaints. Video models generate each clip on its own, with no idea what happened in the one before. So a character's jacket changes colour, an injury disappears, and late-afternoon light turns into night between two shots.

I added a continuity ledger, a record of facts that every clip shares, with one strict rule: agents can add to it but can never change what's already there. Then I added a fifth agent, the Continuity Checker, which reads each new shot against the ledger and sends it back if anything contradicts it.

The add-only rule turned out to be the important part. In an early version agents could edit the shared state, and a later agent would quietly "fix" a fact to make its own shot easier to write. The story broke and nothing flagged it. Once facts could only be added, the first decision stuck and every agent after it had to work with it.

Here's a real example from the case study run. In shot 1 the robot's left arm is damaged. In shot 4 the Scene Writer has it reach for the flower with that same arm. The checker catches it and sends the shot back.

What surprised me is that the rewrite is better than the original. The robot reaching with its good arm while the broken one hangs says more about the character than the first draft did. That kept happening. The ledger's constraints pushed the writer toward more specific, more emotional choices.

In LangGraph this is just a loop in the graph, with a cap on retries so one stubborn shot can't keep burning calls.

V5Caching, because the LLM bill is the business

Every new agent meant more LLM calls, and every retry added another. For PromptMotion that matters more than it would for most products. Around 90% of my running cost is LLM usage. I price plans in rupees for Sri Lankan creators and pay for models in dollars, so the cost of a single run decides whether the business makes sense at all.

A lot of every run repeats. A style the creator has used before, knowledge base results for common emotions, the formatting rules for each model. The caching layer stores those and hands them back instead of paying for them again.

This was only easy because of version 2. You can't cache part of one giant prompt. You can cache a single agent's step when its inputs haven't changed.

What I took from this stage

When the output has to stay consistent, give agents shared state they can add to but never rewrite. If they're allowed to overwrite facts, sooner or later one of them will. And think about cost from the very first version. A clean agent graph is the only reason caching was easy for me.

You can watch the engine run live or read the full PromptMotion case study. If you're building something like this yourself, here's how I approach multi-agent AI development.