How to Organize Agency Context for AI
An agency runs on context
An agency runs on context. Every client has a different positioning, a different voice, different constraints, a different set of decisions made across the engagement. Your team uses AI tools across all of them at once. And the context for each client lives in a mess of files, Slack threads, call transcripts, and someone's head — until it gets lost, contradicted, or applied to the wrong client.
Organizing agency context for AI is a specific problem, different from a single company's. Here's how to think about it.
What's different about organizing context for an agency?
A single company organizes one context. An agency organizes many — one per client — plus its own.
That changes the problem in two ways. First, isolation matters: client A's confidential information must never surface in work for client B. Second, your own methodology is a layer of its own: the way your agency approaches every engagement — your strategy framework, your process, your standards — applies across all clients and has to stay consistent even as each client's context stays separate.
So it's not one big knowledge pile. It's many isolated client contexts, sitting under one shared company brain.
Why does client context get messy with AI tools?
Because the context arrives as a flood, changes constantly, and lives in too many places.
Picture a typical engagement. At kickoff the client dumps everything useful: pitch decks, sales call transcripts, old offers, brand guidelines. Your team extracts more in discovery calls — the things the founder says out loud that aren't in any document. You assemble it into a working source of truth, often as a pile of Markdown files, maybe visualized in Figma or a doc.
Then it starts to drift. The client gives feedback in a Slack thread and now the source of truth has to change in several places at once. A single new file from the client — one important call — reshapes the whole positioning, and propagating that by hand across every document is painful. Run five projects at once and the file count explodes. Someone joins a call, the transcript lands in Notion, and a teammate who needed it never sees it. A designer building a testimonials section needs the key metrics the client mentioned once — and has no way to ask, so the detail is lost.
None of this is a discipline problem. It's that static files don't update and scattered knowledge doesn't circulate. The collection step works fine; the keeping-it-current-and-shared step is where it breaks.
How should an agency structure client context?
Two levels: a separate context vault for each client, and a company brain above them.
A separate vault per client. Each client gets its own isolated context — its files, its calls, its decisions, its brand. Physically separate, not just tagged or filtered. This is the part that prevents contamination: there's no path for one client's data to appear in another's work, because they're different vaults, not one vault with access rules.
A company brain on top. Your agency's own layer — your strategy framework, your process, your standards, your firm-wide knowledge — sits above the client vaults. It's the methodology you bring to every engagement, maintained once and applied everywhere, without getting mixed into any single client's context.
The result is a clean hierarchy: shared agency approach on top, isolated client contexts underneath. Exactly the structure agencies converge on once they feel the pain — not one giant company brain, but context divided per project, under a common method.
How do you keep client contexts separated?
Through isolation by design, not permissions after the fact.
The reliable way to separate clients is to give each its own vault and connect only that client's sources to it. Connect the client's Slack channel, their files, their call recordings — and nothing else. The vault for client A draws from client A's sources only, so it can't be polluted by client B, because client B's data was never in it.
This also fixes the team-knowledge problem. Because each client vault is reachable through MCP, everyone on that client's team — strategist, designer, project manager — pulls from the same current context, instead of depending on whoever happened to be on the call. The designer who needs a client's key metrics can finally ask and get an answer, because the context is one place, shared, and current.
How does a context layer deliver the right client context?
You set up a vault per client, connect each client's real sources, and add your company brain on top. Your AI tools — Claude, Cursor, whatever the team uses — connect to the relevant client's vault through MCP. When someone works on client A, their tools see client A's context plus the company brain, and nothing from any other client.
The everyday payoff is concrete. When a client asks "why did you design it this way?", the reasoning is in the vault, sourced from the actual call where they said it — not lost in three hours of searching Slack and recordings. When a new file reshapes the strategy, you add it once and every tool reflects it. When someone new joins the project, they inherit the full context instead of starting cold.
That's the difference between an agency drowning in per-client files and one where each client's context is isolated, current, and available to the whole team — with your own method consistent across all of them.
→ How context reaches each tool: How to Deliver Personal Context to AI Tools
→ The same problem inside coding tools: How to Give Claude Code Context
→ Set up isolated client vaults with Unabyss →
