Skip to content

Video Specialization

When a workflow goes viral on a specific account, that workflow becomes specialized for that account. All future versions are built single-tab for the winning account. The workflow is no longer fanned out to the others.

This is the inverse of fan-out: instead of taking a working format and shipping it everywhere, you take a proven-on-one-account format and double down on that one account.

Why it exists

When a video goes viral on one account, the energy, avatar, voice, and audience of THAT account are what made it work. Re-running the same format on four other accounts dilutes attention and tends to produce flat copies — the format works because the winning account has the audience for it, not because the format is universal.

Specialization keeps follow-up work focused on the proven format-account fit instead of forcing it onto accounts where it underperforms.

When to specialize

Judgment call, no hard threshold. The signal is one account's tab clearly outperforming the others — a video goes viral and the others fall flat. The decision is: "this format works for THIS account. Double down here instead of trying to make it work for the others."

You make the call. There is no metric the agents will trip on automatically.

What changes after specialization

Aspect Before specialization After specialization
Tabs in new .nbflow versions One tab per target account Single tab — the winning account only
Fan-out protocol (Step 1-7) Required for every variant Skipped entirely
Variant levels (Lvl 1-4) Apply same as normal Apply same as normal, but always single-tab
Old multi-tab versions — Stay archived as-is — do NOT delete or strip other tabs from them. The rule applies to NEW versions going forward, not retroactively

How specialization is tracked

A single field in reference/version-registry.json on the workflow's entry:

{
  "salvora": {
    "SALG7": {
      "current_version": "V2",
      "status": "approved",
      "specialized_for_account": "ES-2"
    }
  }
}

When specialized_for_account is set, every agent that builds, patches, or fans out a version of that workflow reads this field and skips multi-tab fan-out. The Stage 0 brief intake check also reads it — when a brief lands for an already-specialized workflow, the variant is built single-tab.

Where to look

Always check the registry first. The specialization is in the registry, not the filename. SALG7-V3.nbflow looks identical to a normal workflow filename — only the registry tells you it's single-tab.

Building a new version of a specialized workflow

  1. Read the registry first. Find specialized_for_account. If set, this is a single-tab build.
  2. Take the most recent version of the specialized workflow as the source (e.g. SALG7-V2 if specialized after V2). If that version still has multiple tabs (because it pre-dated the specialization), take only the winning account's tab as the starting point.
  3. Build / patch single-tab. Apply the variant level rules normally (Lvl 1-4) but only on that one tab.
  4. Save with normal version progression. A Lvl 1 variant on SALG7 (specialized to ES-2) goes from V2 → V2-1 per the variant version rules. The filename is still SALG7-V2-1.nbflow — the specialization is in the registry, not the filename.
  5. No fan-out step. Skip the entire 8-step fan-out protocol.

Unspecializing

If a specialized workflow needs to be opened back up to other accounts — rare, but happens when the winning account stops performing and the format is worth re-testing on others:

  1. Remove the specialized_for_account field from the registry entry.
  2. Add a history note in the registry explaining why.
  3. The next version goes back to multi-tab and follows the normal fan-out protocol again.

Currently specialized workflows

  • SALG7 → specialized for ES-2. Original V1/V2 had EN-1/EN-2/EN-3/ES-2/ES-3 tabs; ES-2 went viral, so V3+ will be ES-2 single-tab.

(Check reference/version-registry.json for the current authoritative list — any entry with a specialized_for_account field is specialized.)