Artificial Intelligence/ ·2 min read
Not All Context Changes at the Same Speed
AI /Context Engineering /Developer Experience /From My Desk
Most conversations about context storage for AI-assisted development begin with tooling: Git versus Obsidian, repository embedding versus standalone wikis.
Effective context architecture begins by identifying how frequently that information changes.
Organizational principles and daily sprint logs serve different audiences, evolve on distinct cadences, and degrade differently when stored incorrectly. Applying uniform storage across all tiers leads to bloated, unmaintained configuration files or central repositories that agents never query.
A structured framework aligns storage media with context lifespan.
Context has a clock speed
Context documentation operates across three distinct rhythms:
Slow-moving context evolves quarterly or annually: organization mission, product principles, design system tokens, architectural tenets, and strategic OKRs. This foundational layer defines long-term constraints.
Medium-cadence context evolves monthly or per development cycle: team conventions, domain patterns, active feature specs, API schemas, and integration boundaries. This layer reflects current implementation standards.
Fast-moving context evolves daily or per session: technical decision logs, spike findings, debugging notes, and session-specific agent prompts. This operational layer captures perishable insights in the moment of discovery.
Storing all three tiers in a single location compromises maintainability: high-frequency changes clutter stable organizational standards, while formal review processes discourage logging quick technical findings.
Slow context requires governance
Organizational principles, brand guidelines, architectural tenets, and security policies require deliberate ownership and structured review.
Where it belongs: A dedicated context repository or governed knowledge base with clear ownership, version history, and quarterly review cycles.
Storage rationale: Organizational standards apply across multiple repositories and teams. Duplicating corporate design principles across several dozen repository configuration files creates immediate synchronization drift.
Governance pattern: Review quarterly alongside organizational planning cycles. When strategic priorities or architectural tenets shift, update central documentation to ensure all agents reference current standards.
Medium context requires proximity
Team-level conventions, feature patterns, API contracts, and domain models live alongside the codebase.
Where it belongs: Within the source repository, versioned alongside application code in CLAUDE.md, docs/conventions.md, and architectural decision records (ADRs).
Storage rationale: Implementation context couples directly to code. When refactoring service boundaries, the corresponding architectural documentation updates within the same pull request, preserving attribution and atomic history.
Governance pattern: Update documentation as part of standard delivery. When a pull request alters an API pattern or architectural decision, the accompanying ADR updates within the same commit.
Fast context requires low friction
Session findings, debugging breakthroughs, and rejected approaches represent perishable, high-value insights.
Where it belongs: Low-friction capture tools: personal knowledge bases, markdown vaults, or lightweight team scratchpads.
Storage rationale: Introducing formal pull request overhead to quick debugging notes discourages documentation. The capture mechanism must operate faster than context decay.
Governance pattern: Capture immediately during execution, curate weekly. Review provisional session notes regularly and promote proven patterns into repository-level decision records.
The layered model
Combining these tiers establishes a coherent context architecture:
Layer 1: Organizational context (slow). Central repository reviewed quarterly. Defines global tenets, security baselines, and design system tokens for all agents across the enterprise.
Layer 2: Team and domain context (medium). In-repo markdown files updated alongside code. Defines repository-specific conventions, ADRs, and schema contracts.
Layer 3: Working context (fast). Personal vaults and session logs captured in real time. Holds provisional findings and exploratory rationale.
Context flows upward: durable insights captured in personal notes promote to repository ADRs, and broad architectural patterns formalize into organizational standards.
What this looks like at different scales
Solo builder: Primary workflows center on layers 2 and 3. A personal knowledge vault holds product thinking and domain models, while repo-level CLAUDE.md files provide execution instructions.
Small team (2 to 5 people): Layer 2 serves as the primary collaboration baseline. In-repo context provides shared truth, while contributors maintain personal notes for rapid capture.
Mid-size team (5 to 20 people): Deploy all three layers. The central organizational layer prevents drift across multiple microservices, while in-repo context remains team-owned.
Enterprise: Formalize governance across every tier. Central context incorporates ownership boards and automated freshness alerts, while repository configurations use CI validation to prevent documentation drift.
The core principle
Store context where its rate of change matches the storage medium.
Slow context requires durability and review. Medium context requires proximity to source code. Fast context requires minimal capture friction.
Matching storage models to update frequencies ensures documentation remains accurate and actionable for autonomous agents.
This is Part 3 of the Context Engineering series. Revisit Part 1: Context Is the New Competitive Advantage and Part 2: Where Should Your Context Live?.
