CW-301g · Module 3

Context Access & Segmentation

3 min read

Not everyone should have the same context. The sales team's context includes pipeline data and deal terms. The engineering team's context includes architecture decisions and technical debt. The executive context includes board materials and strategic plans. When context is not segmented, two risks emerge: information leakage (sensitive data reaching people who should not see it) and context pollution (irrelevant information diluting the context window with noise).

Context segmentation follows the organization chart — each team gets access to the organization context (shared), their department context (segmented), and their project context (scoped). Cross-functional projects create shared contexts that pull from multiple department contexts but only the portions relevant to the project. The principle is need-to-know, not nice-to-have.

Do This

  • Segment context by team and access level — sales context stays with sales, engineering context stays with engineering
  • Create cross-functional project contexts that pull only relevant portions from department contexts
  • Review context access when people change roles — context permissions should follow organizational access

Avoid This

  • Give everyone access to everything — it wastes context window space and creates information security risks
  • Duplicate context across departments instead of sharing — duplication causes version drift
  • Forget to revoke context access when someone moves to a different team