Template-Dispatch Prompts

You have one system prompt that handles four cases. Then six. Then ten. Each case adds a paragraph of "if X, then Y; if Z, then W" rules. The prompt grows past a page. A new case lands and breaks a rule you thought belonged to a different case. Output quality drifts: the LLM picks the wrong rule, applies the right rule weakly, or quietly merges two. When something's wrong, you can't tell whether the LLM mis-selected the case or mis-applied the rules — the diagnosis surface is one giant prompt.

The way out is to stop asking one prompt to do everything. Pre-select the right prompt before the LLM call, based on a typed flag. Each case gets its own short, focused prompt; the LLM never sees the branching logic at all.

That is template-dispatch: typed flags dispatch to different system-prompt variants or different pre-written template strings, rather than one universal prompt trying to handle every case. The dispatch happens in code, upstream of the LLM. Each dispatched variant is small enough to actually read.

The shape

Typed input
  shot.type = "composite"
     │
     └──→ select system-prompt variant: "composite_system_prompt"
              (describes ONLY foreground subject; environment comes from vision)
     └──→ select user-prompt format: "composite_user_format"

Typed input
  product.categoryId = "clothing-shoes"
  product.visualizationId = "on-model"
     │
     └──→ select template: PRODUCT_TEMPLATES["clothing-shoes"]["on-model"]
              (pre-written prompt with placeholders for product details)
     └──→ fill placeholders from product metadata
     └──→ pass to generator (no LLM call if template is fully specified)

Why dispatch instead of one universal prompt

One prompt trying to handle every case becomes:

• Long — every case's rules must live in the system prompt.
• Ambiguous — the LLM chooses which rules to apply based on unclear signals.
• Brittle — adding a new case risks disturbing existing ones.
• Hard to debug — when output is wrong, was it the case-selection or the case's rules?

Dispatch breaks the problem apart:

• Each variant is small and focused.
• Cases are independent by construction; adding a new one doesn't touch existing ones.
• When output is wrong, the dispatched variant is isolated and easy to inspect.
• System prompts are short enough to actually read.

Dispatch axes in practice

Shot-type dispatch (in a video-production pipeline):

• full-ai → describe the full frame
• composite → describe only the foreground subject; environment comes from vision / live footage
• live → still emit editorial prompt as guidance, but do not dispatch an image job

Category × visualization dispatch (in a product catalog):

• 7 categories (clothing-shoes, accessories, food-beverages, cosmetics, electronics, home, other)
• 3–4 visualizations per category (on-model, flat-lay, in-store, catalog-studio, overhead, lifestyle, studio, …)
• ~28 total templates

Templates can be pure string fills (no LLM) for deterministic outputs, or LLM-filled with structured context when creative latitude is needed.

When to dispatch

• When cases differ in what they describe — composite shots describe foreground only; full-ai shots describe the full frame. That's a real difference, not a stylistic variant.
• When cases have independent rule sets — cosmetics studio shots have different composition conventions than clothing on-model shots.
• When catalog growth is expected — adding a new product category should be a local change to one template, not a refactor of a unified prompt.

When not to dispatch

• When the variants differ only slightly. If the rule change is "add one sentence", it's a parameterization, not a dispatch.
• When cases are fluid and user-defined. At which point the cases are better expressed as a typed-reference problem than a template-dispatch problem.

Failure modes

• Template sprawl. 28 templates become 128 as cases proliferate, and maintenance collapses. Counter: catalog review pass every ~6 months; merge near-duplicates back into parameterizations.
• Wrong dispatch. The typed flag is set incorrectly upstream, the wrong template runs, the output is subtly off. Counter: surface the chosen template name in the output for observability.
• Template drift from reality. A pre-written template for "clothing × on-model" doesn't match current visual trends. Counter: templates are versioned and reviewed; rebuild seasonally rather than letting them rot.
• LLM ignores dispatch. If a template is passed as one among several options inside a long system prompt, the LLM may ignore the dispatch. Counter: dispatch happens before the LLM call; the LLM sees only the selected variant.

Generalises broadly

• Tool-using agents. Each tool gets its own micro system prompt when called, not a unified "here are all 200 tools" prompt.
• Domain-specific chat assistants. Legal / medical / financial variants of the same base assistant, dispatched by domain flag.
• Form generators. Each form type gets its own prompt, not one universal form-generating LLM.
• Language-specific content generation. Per-language prompt variants dispatched by locale, rather than one multilingual prompt.

The pattern: when cases genuinely differ, give each its own focused prompt; dispatch upstream of the LLM call, not inside it.