Correct isn't the same as good: teaching a multi-agent engine some taste

This is the last part of the series on how PromptMotion's engine evolved. In part 1 the engine went from one prompt to a team of specialist agents. In part 2 it got a shared continuity ledger, a checker that sends bad shots back, and a cache to keep the LLM bill under control.

By the end of that, the engine was reliable. This post is about what happened next, which turned out to be the most useful lesson of the whole project.

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

Correct isn't the same as good

Once the engine was reliable, I noticed something I didn't like. Almost everything it produced was correct. Characters stayed consistent, the camera language was sound, the prompts were formatted perfectly. And a lot of it was forgettable.

I had built a system that rewarded playing it safe. Every check and every retry nudged the output toward the most defensible answer. Nothing in the loop ever asked whether an idea was surprising.

I had optimised the engine for consistency, and consistency was quietly killing the ideas.

So I changed the loop. A Vision Card now captures the creator's taste up front, and every agent works from it. Before any story is built, a divergence engine generates several premises using director-style lenses to pull them in different directions, and an idea gate scores them on how far they move from the obvious version. Then there are two critics instead of one. The first checks whether the work is correct. The second ranks the correct options on taste.

Splitting the critics was the change that mattered most. When one critic judged both things, correctness won every time, because it's much easier to be sure about. Now the taste critic only ever sees work that has already passed, so it's free to pick the bolder option.

The part the engine couldn't fix

Not every lesson was about architecture. Even with much better prompts, a lot of users told me they still didn't really know how to turn them into a video. A great prompt doesn't help much if you don't know what to do with it next.

That changed the product around the engine. The results page used to be a flat list of prompts. Now it walks through the work in two stages, Cast first and then Shots, so people can see the structure the agents built. And I started the PromptMotion Creator Academy, with tutorials that take creators from a prompt all the way to a finished video.

Everything I'd tell someone building something similar

Across all three posts, these are the lessons I'd hand to anyone starting a multi-agent system today.

1. If one prompt is doing several jobs, split it. You'll get better results, and you'll finally be able to see which part failed.
2. Keep domain knowledge somewhere agents can look it up, not baked into their prompts.
3. When the output has to stay consistent, give agents shared state they can add to but never rewrite.
4. Judge "is it right?" and "is it good?" separately. They need different critics.
5. Think about cost from the very first version. A clean agent graph is what made caching possible 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.