Context Anchoring Solves the Same Problem ADRs Solve, Just Faster

Long conversations with AI are not just long; they are lossy in a specific way. Decisions you made early in a session lose weight as more tokens accumulate after them. By the time you are sixty messages into a feature build, the model is working with a context increasingly dominated by recent exchanges, and your early constraints are competing for attention at a structural disadvantage.

The effect is well-documented. The “Lost in the Middle” paper from Liu et al. (2023) showed that language models perform significantly worse on information placed in the middle of long contexts compared to information at the start or end. The effect holds across model families and task types. It is a consequence of how transformer attention distributes over long sequences, not a fixable bug in any particular model.

Rahul Garg’s context anchoring pattern, published as part of Martin Fowler’s series on reducing AI friction, addresses this directly. The solution is to externalize decision context into a structured living document that travels alongside the conversation, getting updated as decisions are made and re-injected at the start of new sessions. Stop relying on the model’s implicit memory for anything that matters; put it somewhere explicit and bring it back deliberately.

The technique is sound. What struck me reading it was how closely it mirrors a practice software teams already use for an entirely different kind of memory problem.

Architecture Decision Records

Architecture Decision Records, or ADRs, are a lightweight documentation practice that Michael Nygard described in 2011. The idea is simple: when your team makes a significant architectural decision, write it down in a short structured document. The document records the decision, the context that led to it, and the consequences. You commit these files to version control alongside the code they describe.

The problem ADRs solve is drift. Teams change. People leave. New engineers join without context. The codebase reflects dozens of decisions, but the reasons behind them are nowhere in the code itself. Without decision records, teams relitigate old choices, undo deliberate tradeoffs, or introduce dependencies that were previously considered and rejected. ADRs prevent this by making the decision corpus explicit and persistent.

Context anchoring solves the same problem in a different medium. Your AI sessions nominally have a team of two, you and the model, but the context loss is faster and more severe than anything a human team experiences. A human engineer who joined six months late at least has access to git history, Slack archives, and institutional knowledge from colleagues. The model’s memory resets entirely at the end of a session and degrades within a session as context grows. Without an anchor, every long session is effectively starting over.

The Living Document as Lightweight ADR

The anchor document Garg describes is structurally close to a good ADR. It records what was decided, why, and what is currently out of scope. It is maintained explicitly rather than reconstructed from history. The key difference is timescale: an ADR lives for months or years alongside a codebase, while a context anchor may live for a single session or a sprint.

A minimal anchor for an AI coding session looks like this:

# Session Context — 2026-03-17

## Active Constraints
- API auth: bearer tokens, no session cookies
- No new third-party dependencies this session
- All database access through the repository layer

## Current Task
User registration endpoint. Validation only; no email verification this session.

## Deferred
- Email verification (tracked in #47)
- Rate limiting (#52)
- OAuth integration (post-launch)

## Done
- [x] User model and schema migration
- [x] Password hashing utility

This reads like the body of an ADR compressed into fast-forward. The format is intentionally sparse: record the decision and the reason, not the deliberation. The model does not benefit from reading the discussion that led to a choice; it benefits from reading the outcome. Conciseness also matters practically, because every token in the anchor document is a token competing for position in a finite context window.

Static vs. Dynamic Anchors

There is a natural split between context that changes within a session and context that is stable across sessions. Session-specific state, the current task, what is in scope today, what has been completed, belongs in the living document you maintain manually. Project-level invariants, coding standards, dependency constraints, architectural commitments, belong somewhere more permanent.

Claude Code uses a CLAUDE.md file for exactly this: project-level constraints injected automatically at position zero in every session. Cursor has .cursorrules. GitHub Copilot has workspace instructions. Each is a tool-level implementation of the same idea, and position zero matters because attention weight is highest at the beginning of the context window.

The CLAUDE.md file is effectively a long-lived ADR for the AI assistant, covering things that never change session to session. The living document covers what evolves. Using both together closes the gap between stable project knowledge and dynamic session state.

What Happens When the Anchor Goes Stale

The failure mode of context anchoring is the same as the failure mode of unmaintained documentation: the anchor records a past state of the project, and the model faithfully respects constraints that have since been invalidated.

If you add a dependency mid-session but forget to update the anchor, the model continues assuming it is unavailable. If you change a design decision but the document still reflects the old one, the model pulls in the wrong direction. The problem compounds quietly: the model does not flag the contradiction; it just proceeds consistently with what the anchor says.

Maintaining the anchor requires treating it as authoritative rather than advisory, which means updating it whenever something material changes. Teams that maintain ADRs well know this discipline already. Teams that maintain them poorly end up with misleading documentation that creates false confidence, and the same dynamic applies here.

One practice that helps: at the start of each new session, spend a minute reviewing the anchor document before pasting it. Read it as the model will read it. If anything no longer reflects reality, correct it before the model acts on it.

The Agent Dimension

The pattern becomes more important, not less, as AI usage shifts from interactive Q&A toward longer agent runs. In a five-turn conversation, context loss is a minor nuisance. In a 50-step agent task where the model is executing code, reading output, making decisions, and looping, drift compounds with each cycle. A constraint ignored at step 8 can produce cascading problems by step 30.

Several agent frameworks have formalized explicit state management for this reason. LangChain’s memory modules provide structured in-session state that persists across agent steps. MemGPT’s architecture gives agents explicit read and write access to a long-term memory store. These are engineering-level implementations of the same intuition as context anchoring: do not rely on implicit attention over a growing context; maintain explicit state.

Context anchoring sits between these automated approaches and no approach at all. It is manual enough to remain auditable and simple enough to start using without any infrastructure. Automated memory systems introduce their own failure modes: the model’s decisions about what to memorize or forget can be wrong in ways that are hard to inspect. A markdown file you maintain manually is always auditable; you can read it, correct it, and reason about what it contains.

The General Principle

Transformer attention is working memory, not permanent storage. It is bounded and lossy under load. Any process involving more than a few turns of reasoning will accumulate context faster than the model can reliably attend to all of it.

Software engineering has a well-established vocabulary for this situation: stateless components need external state management. An HTTP server does not keep session state in process memory across requests; it externalizes session state to a store and retrieves it on demand. A context window is the same kind of temporary computation space, and the decisions you care about are the same kind of state you cannot afford to lose when the process ends.

Context anchoring is the minimal version of that principle applied to AI conversations. It is not a new idea in any deep sense; it is existing wisdom about stateless systems applied to a medium where the statefulness problem is easy to overlook because conversations feel like they should remember. They do not, not reliably. The pattern from Garg gives you a lightweight mechanism to compensate, and the ADR tradition gives you a decade of prior art on how to maintain decision documents without letting them rot.