Named Assets: Reusable Characters and Products Across Scenes

The usual response to a character who looks slightly different in scene four than in scene one is to write a better description — more detail on the face, more specificity on the outfit, hoping the extra words pin things down. They don't. Nothing carries between generations by default: every job a model runs starts fresh, and a face described in words gets re-invented each time, close enough to feel deliberate and different enough that a viewer watching three shots in a row notices someone else arrived. Padding the description doesn't fix that — it narrows the range of what the model might invent slightly, but it never pins an identity down the way an actual reference does. Drift isn't a wording failure. It's the predictable result of never having given the model anything but words in the first place.

The fix is pixels, not adjectives

The reliable version of consistency runs on reference images — a picture supplied alongside the prompt that the model copies an identity, product, or style from, rather than reinventing it from a paragraph. A viewer forgives small drift in a face and won't forgive a product label with the wrong number of words on it, which is why packaged goods need reference support even in cases where a character could arguably survive on prompt alone. The practical version of "supply pixels instead of adjectives" is: build one canonical reference for the subject once, and derive every subsequent scene from that reference rather than from a fresh redescription each time.

That's straightforward advice for one shot. It gets harder to hold onto across a real production — a workflow with six, ten, or eighteen scenes, a cast of two or three characters plus a product plus a location, built over several sessions rather than one sitting. Redescribing "the same" character correctly in scene fourteen, from memory, without a system tracking what scene one actually locked in, is exactly where drift creeps back in even for someone being careful. The fix at that scale isn't discipline. It's an asset system that remembers the reference so nobody has to re-describe it.

How registration actually works

Versely's agent handles this through a small, specific set of tools rather than a general-purpose upload button. request_asset_upload is the normal path — asking the agent to set up an asset for a character or product opens an upload card in the app where reference images actually get attached, one asset at a time (or several at once, for a full cast, via the batch version of the same tool). The tool itself doesn't store anything; it's the UI signal that makes the upload form appear at all, and the frontend handles the actual save once you've picked the images.

The second path exists for a narrower case: if reference images are already hosted somewhere — already-uploaded URLs rather than files sitting on a device — create_workflow_asset registers them directly without going through the upload-card flow. Both paths converge on the same underlying record, and both scope that record the same way: an asset attaches to exactly one of a workflow_id (a video scene workflow) or a slideshow_schedule_id (a recurring slideshow series), never both and never neither. That scoping is what keeps a character built for one production from leaking into an unrelated one — assets belong to the build they were registered for, not to a general pool that every workflow can silently draw from.

What the scene director actually does with a named asset

Registering a character or product isn't the end of the job — it has to actually get used correctly once scene prompts are being written, and this is the step that's easy to get wrong even with a clean asset already saved. Versely's scene-authoring step, direct_scenes, is built specifically to close that gap: it loads each referenced asset's images and reads them inline while writing a scene's prompts, so wardrobe, location and product traits end up grounded in the actual pixels of the reference rather than in whatever adjectives happen to survive from scene to scene in a running description.

That's the concrete mechanism behind "register once, point later scenes at the name." A skeleton for scene nine doesn't need to redescribe what the spokesperson is wearing or what the product label says — it references the asset by its key, and the scene director pulls the real reference image and writes prompt language grounded in what's actually in that photo, not in a memory of what scene one's prompt said. The name is doing the job a paragraph used to do less reliably.

The naming discipline that makes this hold

The system does the heavy lifting, but it still depends on one habit: naming an asset once, clearly, and then never redescribing that subject from scratch in a later scene's prompt. A skeleton that says "the character from the spokesperson asset, now in the kitchen" is doing this correctly — pointing at the registered reference and adding only what's new about this specific scene (the kitchen). A skeleton that re-describes "a woman in her thirties with brown hair wearing a blue cardigan" for scene nine, even if that's an accurate description of the same registered asset, has quietly reopened the door to drift, because now there are two competing sources of truth for what she looks like: the reference image and a fresh paragraph that may not match it exactly.

The same applies to products. If a spokesperson holds a product across five scenes, register the product as its own asset separate from the character, rather than folding "holding the branded bottle" into the character's own description. That keeps the two traits independently anchored — a wardrobe change in scene six doesn't risk the product's label drifting along with it, because the product's reference is doing its own job, not riding along inside the character's.

Walkthrough: registering a cast before writing scenes

1. Before drafting any scene skeletons, ask the agent to set up reusable assets for everything that recurs — a spokesperson, a product, a location. For a full cast known up front, ask for all of them at once rather than looping through one at a time.
2. Upload clean, well-lit reference images for each — a face or product shot with minimal occlusion, since this is the pixel source everything downstream traces back to.
3. Write scene skeletons that reference each asset by name or key, not by redescribing it. "The [asset] in [new setting/action]" is the correct shape; a fresh physical description competing with the registered reference is the pattern to avoid.
4. Let direct_scenes author the actual img_prompt and video_prompt for each scene — it reads the registered reference images inline, so wardrobe and product traits come from the asset, not from whatever the skeleton happened to restate.
5. Review the full set of scenes together before saving, checking specifically for the subjects that recur most — a character across every scene, a product across every scene featuring it — since that's where a missed reference or a skipped registration shows up first.
6. Reuse the same registered assets across a workflow's full lifetime, including future re-runs. An asset registered once for a saved workflow stays available for every scene added to it later, which is the entire point of building it as a name rather than repeating a description.

Treat character drift the way this system already treats it: not a writing problem to solve with better adjectives, but a registration problem, solved once, that every later scene just points at.