Separate firm knowledge from client knowledge in AI context
Keep knowledge about how the firm works architecturally separate from knowledge about individual clients, so each can be brought to the AI only when needed and the resulting traces can be managed.
A firm that sets out to capture what it knows quickly faces a structural question it is easy to answer badly: does the firm’s own knowledge and its client knowledge go in the same place?
The intuitive answer is yes. Both are the firm’s knowledge, both are wanted in context, and one repository is simpler than two. The intuitive answer is wrong, and in a professional services firm it is the first thing a risk committee will ask about.
The rule
Knowledge about how the firm works — method, standards, governance, values, templates — is kept architecturally apart from knowledge about individual clients. Each is brought into an AI’s context deliberately, when the work requires it, rather than both being present by default.
What separation buys
Client material is only ever in context when that client’s work is being done. A single combined store means every query about anything carries every client’s material alongside it. Separation makes the exposure surface a decision rather than a default.
The artefacts become manageable. Conversations, drafts and derived documents that contain client material can be identified as such, retained under the right terms, and deleted when the obligation to hold them ends. Material that has been comingled with the firm’s general knowledge base cannot be cleanly separated afterwards; the practical consequence is that it does not get deleted.
Confidentiality obligations are satisfiable rather than merely asserted. A firm that can describe which contexts carry client material, when, and for how long is in a position to answer a client’s question about it. A firm with a single undifferentiated store is not, whatever its policy document says.
How it lands in practice
The shared firm-level project described in Make the firm itself a Claude project is the natural home for the first category, and that note’s deployment shape assumes it. Client material sits in separate per-client contexts brought alongside it for the duration of the work — which also produces a cleaner answer to the question of what a departing staff member’s access should be.
The companion principle is portability: knowledge should live in a form any model can consume and no vendor owns, so the knowledge base does not have to change each time the model does. That argument is made in full in Architect AI around principles, not vendors; separation is the constraint that note does not cover.
The two principles are usually easier to apply at the outset than to retrofit. Retrofitting separation onto a comingled store is, in most cases, a rebuild.