From Notion and Obsidian to Agents: Building Context Architecture for AI
Context engineering is information architecture for agents: deciding which source is authoritative, when it should be retrieved and when it becomes stale.
The most expensive agent failure is often not an obviously wrong answer but a plausible answer built from stale or conflicting context. Product decisions, repository reality and old prompts need explicit authority rules.
Good context systems provide the right authority at the right time, not simply more tokens.
1. Separate classes of truth
I separate product truth, code truth, operational truth and temporary working memory. This prevents a desired product behavior from being confused with what the current implementation actually does.
2. Single source of truth is not a single document
Each information type needs one authoritative home. API contracts can live in the repository, product decisions in ADRs, research in a knowledge base and secrets in a secret manager.
3. Build task-specific context packs
type ContextPack = { task: string; authorities: string[]; constraints: string[]; currentState: string[]; decisions: string[]; staleAfter?: string;};A production incident and a brand-writing task should not receive the same context. Smaller packs with explicit authority produce higher signal than dumping an entire workspace into the prompt.
4. Retrieval needs authority metadata
Semantic similarity alone may retrieve an older decision because its wording matches better. I attach source type, status, updatedAt and supersedes metadata so retrieval can rank authority and freshness, not only similarity.
5. Keep a decision log
Architecture decisions trapped inside chat history are not durable context. Short ADRs capture the decision, reason, rejected alternatives and the condition that should trigger reconsideration.
6. Separate prompts from policy
The prompt describes the current task. Persistent policies describe recurring boundaries such as branch strategy, release rules or security constraints. Repeating policy in every prompt creates drift.
7. Treat freshness as first-class data
The most dangerous context can be information that used to be correct. Pricing, deployments, active flags and architecture decisions need freshness or supersession rules.
8. Measure context failures operationally
- How often did the agent use a superseded decision?
- How often did it ask for information already available?
- How often did it select the wrong repo or branch?
- How often did it propose changes that violate current architecture?
A second brain becomes useful to agents when it evolves from an archive into a routing system for authority, freshness and decisions.