Run a client assistant for five accounts and you'll usually find five prompts that look almost identical: the same tone rules, the same constraints on what the assistant can promise, the same reply format, with one paragraph of real per-client difference buried somewhere in the middle. Most freelancers and small agencies running more than a couple of custom assistants get here the same way: copy the working prompt, swap the client's name and a few details, ship it, move on to the next one. The trouble starts the day you need to fix something in all five at once, and realize there isn't one "all five" to fix. There are five separate documents that happen to agree with each other today and won't tomorrow.
Why one prompt per client assistant stops working past client #5
At two or three clients, keeping a separate prompt file per assistant is manageable. You know where everything lives, and copying a file to start a new one takes a minute. Past four or five, that same habit turns into a maintenance problem: the shared rules now exist in that many separate places, and any edit to them means opening every file, finding the right paragraph, and changing it by hand. Miss one, and that client's assistant quietly keeps running on the old rules until someone notices, usually because it did something the newer version was written to prevent.
Picture the actual failure: a client flags that the assistant promised a delivery timeline it shouldn't have. You trace it to a single sentence in the base instructions, fix it in that client's file, and move on. Three weeks later a different client hits the same problem, because the same sentence is sitting untouched in their copy of the prompt too. The fix worked exactly once, for exactly one client, out of however many were actually running the old text.
The fix isn't a bigger folder or a better naming scheme. It's separating what's actually shared across every client assistant from what's genuinely specific to one.
Two blocks every client assistant shares: base rules and output contract
In PAL, the shared part becomes two global Blends: one holding the assistant's base behavior rules (how it should sound, what it should never claim, when it has to defer to a human), and one holding the output contract (the reply format every response has to follow). Global scope means both are available to every Project, not just one. Fix an inconsistency in either, an assistant apologizing too often, or a reply format nobody's actually following, and every client assistant that references that block inherits the fix the next time you generate from it, which PAL calls Brew.
That's the core move: two blocks, written once, doing the work that used to live inside every single client's separate prompt.
{{client}} overrides: what's actually allowed to change
What's left after the shared rules is small on purpose: domain vocabulary, a tone adjustment, which facts this specific assistant can state without checking, and what always needs to escalate to a human. That's what a per-client Overrides Blend holds, built inside that client's Project and referencing the two global blocks through PAL's Blend-in-Blend composition. {{client}}-style variables mark the values that change per assistant, so the override text stays short: a handful of lines, not a rewritten prompt.
Fifty clients, in this structure, means two shared blocks plus fifty short override files, not fifty independent documents that each happen to repeat the same three paragraphs.
See who depends on a block before you edit it
Editing a block that fifty other things reference is exactly the kind of change you want to see the reach of before you make it, not after. PAL's Usage panel shows the direct parents of a block, meaning every Blend that currently references it, plus a recursive count of how far the effect actually spreads. Tighten a rule in the base assistant behavior block, and the panel tells you up front which client Overrides blends are about to inherit that change, so a fix meant for one client's edge case doesn't quietly land on the other forty-nine. The same mechanism blocks hard deletion of a block while anything still references it, so a foundation another client assistant depends on can't be removed by accident.
Adding client #51 without starting from a blank page
The workflow for a new client stays the same size no matter how many clients came before it: open a new Project, add one Overrides Blend, reference the two global blocks, then write the few lines that are actually specific to this client. Nothing about the base rules or the output contract gets touched or copied. Before calling it done, PAL's Project Map gives you a text export of the whole structure, useful for checking your own work or handing the composition to a teammate who needs to see what the assistant is actually built from without opening the tool.
What this doesn't do
PAL builds the prompt text for a client assistant. It doesn't deploy or run one. There's no connection to a chatbot platform's custom-instructions field, no live runtime, and nothing that pushes an updated block into ChatGPT's or Claude's assistant settings on its own. When you generate, you get finished text, and you paste that text into wherever the assistant actually lives, whether that's a custom GPT, a Claude project, or an internal tool your client uses. Updating fifty assistants still means fifty paste actions. What changes is that each of those paste actions starts from the same current source instead of fifty different half-updated copies. That's a deliberate boundary, not a missing feature: PAL's job is getting the prompt right once and keeping every client's version of it current, not operating the surface where the assistant actually talks to end users.
If you haven't set up the underlying Project and Blend structure yet, What Is a Reusable Prompt System covers the ground rules this pattern builds on, and Prompt Variables goes deeper on how {{token}} values work at generation time. For a working version of this exact base-plus-overrides structure, open the multi-client assistant base in the gallery.