One pipeline, many brands, without maintaining a separate process for each

Look at what a production run actually involves for any client: choose the product, assemble the prompt, generate, check against the brand's rules, grade for consistency, deliver in the required formats.

That sequence is identical across every brand you will ever work with. What varies is the values fed into each step — and that is precisely the separation that lets one pipeline serve all of them.

Most people build the sequence fresh per client because the outputs look so different that the process feels like it must be different too. It is not, and recognising that is the whole leverage.

1. Select — which product, which slot, from the brand's product list.
2. Assemble — build the prompt from the brand's tone, the product's preserved attributes and the shared craft block.
3. Generate — call the model, requesting the brand's configured variant count.
4. Check — test output against the brand's guardrails and required ratios.
5. Grade — bring the set into one look, together rather than individually.
6. Deliver — export in the brand's formats with the brand's naming convention.

Each stage reads the brand file. None of them contains a brand name. That is the whole architecture.

Prompt assembly is the step that benefits most from being systematic, because it is where consistency is won or lost.

• Craft block — your house standard. Lighting, optics, framing, exclusions. Identical for every brand and every shot you produce.
• Brand block — tone, palette, permitted locations, guardrails. Constant within a brand.
• Product block — the item and its preserved attributes. Changes per shot.

Assembling in that order gives you a prompt that is consistent at the level of craft, consistent within the brand, and specific to the shot — with no opportunity for the drift that comes from rewriting the shared parts each time.

After generation, before anything is presented, check what came out against what the brand file says must not happen. Wrong aspect ratio, missing required count, a location outside the permitted list, anything flagged by the guardrail field.

Failures should stop the run and say why, not warn quietly in a log. The value of the check is entirely in it being blocking.

This is also what makes the pipeline safe to run at volume. Reviewing sixty assets manually is unreliable by the fortieth; a check that refuses the three that break rules leaves you reviewing for quality rather than for compliance.

Three things resist the data-driven approach:

Art direction judgement. Whether a frame is right for a brand is a decision, not a rule. The pipeline produces candidates; a person chooses.

Novel formats. A client asking for something structurally new is a workflow change, not a data change. Extend the pipeline deliberately rather than bending a brand file to describe something it was not built for.

Relationship. How a client wants to be communicated with, what they need to see before approving, how much process to show. This belongs in your head or in a note, not in the production system.

agency run --brand example --slot june --dry-run
agency run --brand example --slot june

A dry run that prints what would happen — which products, how many assets, which prompts — before anything is generated. Then the real run.

Build the dry run first. It is the cheapest way to catch a misconfigured brand file, and it is the difference between a system you trust and one you supervise.

Once this exists, taking on an additional client stops being a question of capacity and becomes a question of whether you want the work. That is the actual point of the whole structure.