Workflow assets reused across every scene

The Lunchwell Hospital Visit recipe runs eighteen scenes and registers three assets: a wife, a husband, and the product itself. The wife's reference is pulled into fourteen of those eighteen scenes. The lunchbox appears in ten. The husband, four.

Three uploads, twenty-eight scene-level references. That ratio is the point of the asset system — you are not attaching an image to a scene, you are registering a thing once and naming it wherever it appears. What follows is how the published recipes actually model that, and the specific ways a badly managed asset breaks a run.

What an asset is, structurally

A workflow asset is a named record with a type, a description, and one or more reference images. It lives in its own table rather than inside the scene, and the workflow carries an asset map from short keys to those records.

Each scene then holds a list of reference keys rather than a list of image URLs. Scene four of Lunchwell does not contain the wife's photo; it contains the key wife, which resolves through the asset map to the registered record.

That indirection is the whole point. Change the reference image on the record and every scene naming the key gets the new one. Store the URL in twelve scenes instead and you have twelve edits and eleven chances to miss one.

The typed field matters too. The published recipes use three types in practice: character, product, and scene. That is not decoration — the scene director reads each asset's actual reference images inline when it authors the prompts, so wardrobe, packaging and location details end up grounded in the pixels rather than in whatever adjectives you happened to write. A product registered as a product and a person registered as a character get handled as the different things they are.

Three ways published recipes model a cast

Three distinct patterns show up across the library, and choosing the wrong one is the most common structural mistake.

A small reusable cast. Lunchwell is the clean example: three assets, eighteen scenes, heavy reuse. Viral Panel Reaction Reel is the same shape at small scale — an expert, an influencer, and a product across four scenes, each key used twice. This is the pattern you want by default. Few assets, each appearing many times.

One character, multiple states. Lumee Glow Cat Glow-Up registers four assets across twenty-eight scenes, and two of them are the same character: rocky_before and rocky_after. Rocky's before state carries eighteen scenes, his after state carries nine. That is the correct call, not a duplication. A transformation story needs the two states to be visually distinct and internally consistent, and one asset cannot be both. If your recipe has a before and an after, register two assets.

One asset per scene. Neura Coffee vs Brain has eighteen assets across eighteen scenes, typed scene, each referenced exactly once. This is a storyboard rather than a cast: every shot is pinned to its own frame. Legitimate for a tightly boarded animated sequence, but it gets you none of the reuse benefit and means eighteen uploads for one video. People drift into it by accident, registering a new asset every time they write a new scene instead of asking whether an existing key already covers the shot.

The diagnostic: divide scene-level references by asset count. Lunchwell is about nine per asset. Neura is one. Under about two, you are storyboarding, and you should be sure that is what you meant.

Creating them: scope first

Assets are bound to a workflow, and the order of operations matters more than it looks. Create them with no workflow to bind to and they float in your general library, so listing your assets later returns everything you have ever made across every build — which is how a reference from an unrelated project ends up on the wrong recipe. Reserve the workflow first, then onboard against it: a draft exists before the upload cards open, and every asset created in that session is scoped to it.

The upload itself happens through Asset Builder cards in the app. Two things are worth knowing:

• Cards are the normal path. Reference images are collected through the upload card, not described in chat, and asking for a photo in prose without opening a card produces nothing. The one exception is an image that is already hosted somewhere, which can be registered straight from its URL.
• Batch when you know the full cast. If you need a spokesperson, a product shot and a logo, all three cards can open at once rather than serially, which saves several round trips on a cloned template. You fill them in any order.

Uploading reference assets does not use generation credits. The credits go on the run, not on the cast. The full walkthrough is at set up reusable characters and products.

One writing note that pays off later: the description field is not a label. The digestive explainer's character is described as "messy light brown hair, bright blue eyes, light freckles across his cheeks, yellow t-shirt with a red star, blue denim jeans," plus a note on which scenes he appears in. That text gets read when scenes are authored. A description that says "the main guy" contributes nothing.

Updating without breaking a run

Updating an asset is an in-place edit: name, type, description, or the reference images themselves, changed on the record, with everything you do not pass left alone. Every scene that names the key picks up the record as it stands.

The unsafe moment is doing this while a run is in flight. Scenes in a run are dispatched by a scheduler rather than all at once, and a completed scene already has its rendered image and video. So an edit mid-run lands on some scenes and not others, and the run view will not tell you which side of the edit each scene fell on. You end up with a video where the product packaging changes at scene nine and no clear record of why.

The safe sequence:

1. Check whether a run is active before touching an asset at all.
2. If one is, either wait for it to finish or stop it deliberately. Stopping is terminal, so make that a decision rather than a reflex.
3. Edit the asset record, not the individual scenes.
4. Start a fresh run. The completed scenes from the stopped run still exist as usable footage if you want them.

If the change is purely cosmetic on your side — a better description, a clearer name — it is low risk. If it is a new reference image, treat it as a new look and give it a clean run.

Retiring an asset: two traps

The dangling key. Deleting an asset does not clean up after itself. Any workflow whose asset map still points at that record is left with a key that resolves to nothing. The scenes still name it; there is just no longer anything there. This is why deletion is the wrong retirement move in almost every case. If a character is written out, the better options are to update the record in place with the new reference, or to leave the asset registered and remove the key from the scenes that no longer need it. Delete only once no recipe references it.

Inert legacy assets. There are two asset models on the platform, and a workflow can carry residue from the older one. A scene-based workflow that used to be a step-based workflow can still have inline media assets attached to its row, and those are ignored when the workflow runs. They look present in a listing and do nothing. If a workflow is flagged as carrying legacy media assets, the fix is to register them properly and wire them into the asset map, or accept that they are decoration. Debugging "my reference image is attached but the render ignores it" is a miserable afternoon if you do not know this exists.

The short version: register few assets and reuse them hard, write descriptions a stranger could cast from, scope every asset to the workflow it belongs to, update in place rather than deleting, and leave assets alone while a run is in flight. When a recipe is stable, save it as a reusable workflow so the cast you onboarded carries into every future run.

For the narrower question of why a character drifts across scenes in the first place, named assets across scenes covers that ground; this post is about what happens to those assets afterwards. And the asset list on each page of the workflow library is the real answer to "how many should I have."

FAQ

How many assets should a workflow have?

Fewer than you think. Divide the number of scene-level references by the number of assets: the well-structured recipes land around nine references per asset, and anything near one means you are storyboarding rather than building a reusable cast. Register a new asset only when no existing key covers the thing in the shot.

Should a character's before and after be one asset or two?

Two. A transformation needs both states to be visually distinct and each one internally consistent across its own scenes, and a single record cannot hold both. The published glow-up recipe does exactly this, with the before state carrying eighteen scenes and the after state nine.

What happens if I delete an asset a workflow still uses?

The workflow's asset map is left with a key pointing at nothing, and the scenes that name it still name it. Nothing cleans this up for you. Update the record in place or remove the key from the scenes first, and delete only once no recipe references it.

Do reference uploads cost credits?

Uploading reference assets does not use generation credits. Credits are spent when the workflow runs and generates scenes. That makes onboarding a proper cast up front the cheap half of building a recipe, and it is worth doing thoroughly rather than adding assets ad hoc mid-build.