Say you run brand voice for three clients. Each one gets roughly the same kind of prompt: tone rules, formatting instructions, a content brief, with just a small slice that's actually specific to them. If you're opening a blank document for each one and retyping the part that's identical every time, you're not doing three different jobs. You're doing the same job three times.
The hidden cost of rewriting the same prompt for every client
The cost isn't just the minutes spent retyping. It's what happens when something needs to change.
Say you improve your tone-of-voice instructions: tighten a rule, drop a line that wasn't working. If that instruction lives inside three or four separately-typed prompts, fixing it means finding every copy and editing each one by hand. Miss one, and that client quietly gets the old version until you notice, which might be weeks later, in a piece of content that already went out.
There's a smaller cost too: decision fatigue. Every time you open a blank prompt for a new client, you're re-deciding things you already decided: how to phrase the tone rule, what order the instructions go in. None of that is a new decision. It's the same one, paid for again.
Where the rewriting habit comes from
The habit isn't carelessness. It's usually a workaround for a real constraint: most tools give you one text box per prompt. If most of that text is shared and only a small part is client-specific, duplicating the whole thing looks like the only option. Copy, paste, edit the client name, done.
The workaround makes sense for one client. It stops making sense at three, because now every future edit to the shared instructions has to happen in three places, not one.
None of this comes from having too many prompts. It comes from asking one prompt to do two different jobs: hold the part that's always true, and hold the part that changes, with no built-in way to keep the two apart.
Parameterize once: variables instead of duplicates
Separating those two jobs is what a variable does. In PAL, you write a Blend once with a placeholder like {{client}} or {{brand_voice}} inside the shared text. PAL scans the Blend and finds every {{token}} automatically, so you don't maintain a separate list of what's fillable. When you generate (Brew, in PAL's terms), a form appears asking you to fill in the current value, and the rest of the prompt renders exactly as written.
The shared instructions exist in exactly one place: the Blend itself. Client A and Client B use the same Blend; only the variable values differ at generation time. If you need something fast and don't want to build a full Blend for a one-off request, Quick Brew does the same fill-in-the-variables step without creating a saved Blend at all.
Once the prompt is generated, the output goes where it's actually used: you copy it into ChatGPT, Claude, or Gemini, whichever model you're running that client's work through. Nothing about the variable step depends on which model comes next.
Override without duplicating: global vs. project scope
Variables solve the part that's identical across clients. What's left, the part that's genuinely different per client, needs a different mechanism, because it isn't a value you fill in each time. It's a standing difference that should stay different.
That's what scope handles. A Blend can live at global scope, available to every Project, or at project scope, visible only inside one client's workspace. Most teams build the shared instructions as a global Blend, then reference it from each client's Project. When one client actually needs a different rule, a stricter tone or an extra formatting requirement, that override lives in their Project, not in the global Blend, and not copied into a new document.
The result: one edit to the global Blend reaches every client that references it. One override stays scoped to the client it belongs to. Nothing gets duplicated to make either of those true.
If you haven't yet set up the underlying structure (Projects, Blends, and how they reference each other), How to Organize AI Prompts walks through building that system from the ground up.
For a working example built around exactly this problem, the multi-client assistant base in the gallery shows a shared Blend with client-specific overrides in place, ready to open and inspect.