The day I copied my best workspace to a new client and watched it drift in six weeks taught me a structural rule I should have known from day one.
What Happened
I had a workspace running well for one client. Multi-agent, full session logging, status reports, the works. New client came on, similar industry, similar processes. The obvious move: clone the existing workspace, swap names, hand over.
Six weeks later, the new client’s workspace had:
- Three agents that no longer matched the master because their PRDs had updated and the client copy didn’t
- Two hooks that referenced paths from the original client’s repo (with the original client’s name in them)
- A goals YAML pointing at the wrong company’s URL
- Session logs that auto-categorized work into project buckets named after the source client
The client never noticed (the work still got done) but I noticed. The agents had drifted. Updates to my master workspace stopped reaching this client. The whole system was now an orphan branch.
The Rule
Never source a new workspace from another client’s copy. Always source from a master.
The master sits in its own repo. It contains exactly what every client should have. Updates flow one direction: master -> clients. Never client -> client, never client -> master.
This sounds obvious. The reason it doesn’t happen in practice: when you have a working workspace, cloning it feels easier than maintaining a clean master. The clean master is more work to keep current. The temptation is always to use whatever already works.
What the Master Looks Like
The Alcanah master is workspace-setup/. It contains:
agent-library/- every distributable agent, with a manifesthooks/- distributable hooksrules/- distributable rulestemplates/- CLAUDE.md template, status template, goals templatesetup.sh- the install script that copies these into a fresh client repo
No client-specific data ever lives here. No project names. No people. No URLs.
Distribution works by setup.sh reading the manifest and copying files into a new repo, substituting placeholder values for client specifics. The client repo gets the files but never a reference back to any other client.
When the master gets updated, the rollout-runner agent re-runs the install across every client repo (with diff review per file, so client customizations don’t get clobbered).
Why “One-Way Propagation” Matters
Two-way propagation seems convenient. Client A discovers a useful pattern, you backport it to master, master flows to all other clients. In practice, this never works:
- The pattern Client A discovered usually has Client A specifics baked in
- Stripping those specifics is more work than rewriting from scratch in the master
- Other clients don’t want it (their workflows are different)
- The act of accepting a backport invites the next backport, and the master accretes complexity nobody asked for
The fix is to treat client-discovered patterns as inspiration. If Client A’s pattern is genuinely good, you redesign it for the master from first principles. You don’t merge the client’s version.
The Smell Test
If you ever find yourself looking at a client workspace thinking “I should just copy this file to the new client we’re onboarding,” stop. That file should live in the master, or be derived from a master. Copying client-to-client is the path that makes every client repo a one-off snowflake you can’t update.
The boring version of the rule: workspaces are distributable infrastructure, not artisanal handcrafts. Treat the master like a product and the clients like installations. Updates flow downhill. Never up.