per-client-memory-routerlisted

# per-client-memory-router **The problem this solves:** an agency running one agent stack across many clients hits two failures that look unrelated but share one root cause — no separation between "what this agent knows in general" and "what this agent knows about this one client." Global prompts, global memory, and a shared job queue. - **Context bleed.** A preference, a brand voice note, or a fact from Client A's thread surfaces in Client B's output, because the agent's memory has no boundary between them. - **Quota starvation.** One client with a large or slow-running job (a big crawl, a long content run) monopolizes the shared model/API quota, and every other client's job queues behind it or times out. Both are architecture gaps, not model failures. Fixing them takes two separate pieces working together: a memory boundary and a concurrency boundary. > **Global memory answers "how do we work." Per-client memory answers "what do we know > about this client." A job never reads the wrong one, and no client's queue can starve > another's.** --- ## Say this to your agent > "Split our memory into one global store (house style, SOPs, tool configs — shared > across every client) and one isolated store per client (their brand facts, preferences, > history, open items). Every job you run must declare which client it's for before it > reads memory, and it may only read that client's store plus the global one — never > another client's. Then put a concurrency limit in fro