Why Prompt Adherence Collapses Around Keyframes

The instinct when a keyframe-conditioned generation ignores your instructions is to write a more precise prompt. Add a constraint. Specify what should not happen. Lock down the parts that keep drifting. It's a reasonable instinct, and it's backwards for this specific failure — prompt adherence tends to get worse, not better, the more restrictive the prompt gets when the thing it's fighting is a supplied keyframe, and there's a documented public case that shows exactly this pattern escalating in real time.

The documented case: escalating restriction, escalating failure

A bug report filed against Adobe Firefly's video generation is worth reading in full for exactly this reason: the person filing it didn't give up after one failed attempt, they iterated methodically, and documented every step. Across roughly twenty prompt variations, each one more restrictive than the last — geometric constraints, explicit negative instructions forbidding specific unwanted motions, "keyframe lock" commands emphasizing interpolation only, pseudocode-style formatting — the model kept producing the same category of failure: the subject rotating or spinning when it shouldn't, materials transforming into something else entirely, parts of the object hallucinated that were never in the source keyframe. Twenty attempts, all trending toward more restriction, and the failure mode never resolved.

That trajectory is the interesting part, more than any single failed attempt would be. If a longer, stricter prompt were simply a stronger version of a weaker fix, escalating it should have worked eventually. It didn't, and the reason has to do with what's actually competing for control at that specific point in the generation.

What's actually competing for control

A keyframe and a text prompt are not the same kind of instruction, and they don't carry equal weight by default. A keyframe is a hard, literal, low-level constraint — actual pixel and structure information the model is conditioned on directly. A text prompt is a soft, high-level, semantic nudge, filtered through however the model's training data associates those words with visual outcomes. Near the keyframe itself, the model's dominant pressure is object constancy — staying visually continuous with the anchor it was just handed — and that pressure is strongest exactly where the keyframe's influence is most direct: right at the seam, before the generation has had any distance to drift into open-ended interpretation.

When the prompt asks for something that conflicts with the model's own trained sense of "what plausibly continues from a frame like this," the keyframe isn't just one more instruction in the mix — it's a structurally stronger one, because it's supplying information at the pixel level rather than asking for it through language. Near the seam, the model's own prior about plausible continuation and the literal keyframe data are pulling in a similar direction; the prompt, asking for something different, is pulling alone against both.

Why more words make it worse, not better

This is the counterintuitive part, and it follows from two properties of how these models actually process a prompt — properties Versely's own glossary entry on prompt adherence names directly as known hard cases: negation, and instructions competing for a limited attention budget.

Negation is a genuinely harder representation problem than affirmation. Telling a model what a scene should not contain requires it to first represent the forbidden concept and then work against it, rather than directly representing what you do want — a documented weak point for adherence generally, not something specific to keyframes. The Adobe bug report's progression makes this concrete: the escalation specifically moved toward "explicit negative constraints forbidding unwanted motions" and a "keyframe lock" command, and the failures continued through and past that escalation. Asking a model not to rotate an object is a harder ask than describing the pose you want it to hold, and stacking more negative clauses on top doesn't compound into a stronger constraint — it compounds into more of the harder-to-represent kind of instruction.

A longer, more restrictive prompt also dilutes whatever attention budget the prompt gets, at the exact moment it needs to be concentrated. Every additional clause is competing with every other clause for the same fixed processing budget, and it's competing against a keyframe signal that isn't diluted by any of this — the image conditioning doesn't get weaker because your text prompt got longer. Twenty words of pseudocode-formatted, geometrically explicit, negatively-phrased instruction isn't twenty times the adherence force of a five-word instruction; it's the same limited budget spread thinner, fighting a competing signal that stayed exactly as strong as it always was.

Put together: the fix that feels natural — say it more precisely, forbid the bad outcome explicitly, add more constraints — targets the wrong lever. It adds more of the kind of signal (diffuse, language-mediated, now partly negative) that was already losing to the kind of signal (literal, structural, undiluted) that's winning by default near a keyframe.

The fix that isn't "write a better prompt"

If the prompt is structurally the weaker signal near a keyframe, the actual fix is to stop asking the prompt to do that job at all — hand the keyframe constraint to the part of the model built to hold it as structured input, rather than negotiating it through language. FLUX 3 Video is built around exactly this distinction: explicit control over a start image, an end frame, and multiple keyframes in between, connected by the model while following the prompt's intent for what happens between the anchors — the keyframes are a dedicated input, not a claim you have to keep re-asserting in text until the model listens.

That's a different job for the prompt to do. Instead of trying to pin down object constancy through increasingly restrictive language — the exact strategy that failed across twenty iterations in the documented case — the prompt is free to describe what happens between the anchors, while the anchors themselves do the constancy work structurally. This lines up with what Versely's own first-last-frame guidance already says: the prompt still matters for how the model travels between two given frames, not for whether it holds onto them — asking it to do double duty on both is where the strategy in the bug report went wrong.

A Versely walkthrough

1. Pick a model with explicit first-last-frame or keyframe support rather than fighting for constancy through prompt text. VEO First Last Frame Fast and Flux 3 First Last Frame to Video both take the start and end frames as dedicated inputs, which is the structural fix the section above argues for — the full-quality VEO First Last Frame sits above the Fast tier if the job needs it.
2. Keep the text prompt short and scoped to the motion, not the content of the frames themselves. Don't re-describe what's already visible in the keyframes — that's redundant information competing for the same limited attention budget for no benefit, since the model already has it from the images. Describe the camera move or the action happening between them instead.
3. If a first attempt drifts, don't escalate with negative constraints. Simplify the prompt and check whether the two keyframes are actually compatible in the time available — an end frame that's compositionally unrelated to the start forces a warp instead of a clean interpolation regardless of how the prompt is worded, which is a frame-selection problem a longer prompt can't fix either.
4. Treat repeated adherence failures as a signal to change the input, not the wording. If a model keeps drifting from a keyframe after a couple of straightforward attempts, the wider prompting guidance and the model catalog are both faster paths to a fix than a twenty-first prompt variation — a different keyframe pair, a different model built for explicit multi-keyframe control, or a shorter prompt are each more likely to work than a stricter one.

The general shape of the lesson extends past keyframes specifically: the more a generation depends on a hard visual constraint doing real work, the less a longer prompt can compensate for a strategy problem, and the more a properly supported input type is worth switching to before the prompt gets longer than the model can actually use.