There is a specific kind of frustration that comes from starting a new AI coding session on a project you worked on yesterday. You pick up roughly where you left off, but the model has no memory of the conversation that shaped the current state of the code. You explain the constraints again. You re-justify the approach you settled on after thirty messages of iteration. You watch the model suggest the exact alternative you already ruled out, for reasons the previous session fully worked through.
Context Anchoring, explained by Rahul Garg in a piece hosted on Martin Fowler’s site, names this problem precisely and proposes a structured remedy: externalize the decision context into a living document that persists across sessions. The idea is deceptively simple. Its implications are broader than they appear.
The Actual Problem Is Attention, Not Just Memory
The naive version of this problem is that AI sessions have no memory. Start a new conversation and the model knows nothing about the previous one. That framing is accurate but incomplete, because the same degradation happens within a single long session.
This is a known property of transformer-based models operating over long contexts. Content near the beginning of a conversation receives less attention weight as the context window fills. A constraint you established in message five, buried under two hundred subsequent exchanges, is not as salient to the model as the same constraint would be if stated in message one of a fresh session. The effect is well-documented in research on lost-in-the-middle phenomena in long-context LLMs: retrieval accuracy degrades for content positioned in the middle of long inputs, even when that content is technically within the context window.
So the problem has two distinct failure modes. Cross-session amnesia is the obvious one. Intra-session attention decay is the subtler one, and it means that even a perfectly persistent AI assistant would still benefit from re-anchoring decisions at the start of each major task.
What ADRs Got Right, and What They Left Out
Architecture Decision Records, popularized by Michael Nygard’s 2011 post, addressed a similar problem in a pre-AI context. Teams make decisions, people leave, new engineers join, and nobody can reconstruct why the codebase looks the way it does. ADRs provide a lightweight format: context, decision, status, consequences. One file per decision, committed alongside the code.
Context Anchoring inherits this instinct. Both practices recognize that the decision without the reasoning is nearly worthless. A comment that says // use polling not webhooks communicates what was done. An ADR explaining that webhooks were rejected because the deployment target blocks inbound connections communicates why, and that why is what prevents future engineers from reopening the question without new information.
But ADRs are retrospective by design. You write them after the decision is settled. They accumulate as a historical record. Context Anchoring is operational. The document is not an archive of past decisions; it is an active input to the current working session. Garg frames it as a living document, which means it gets updated as decisions evolve, and it gets read at the start of each session to bootstrap the model’s understanding of where things stand.
The distinction matters because it changes who the document is for. ADRs are written for future human engineers. An anchor document is written for the model you are working with right now, plus future sessions of that same workflow. The audience shapes the format. An anchor document needs to be scannable by a model operating at the start of a context window. Dense prose with historical narrative is less useful than structured, explicit statements of current constraints.
The Structure That Makes It Work
A useful anchor document tends to answer four questions clearly:
What is being built. Not the marketing description, but the operational scope: what the system does, what it deliberately does not do, and what the key constraints are (language, framework, deployment environment, external dependencies).
What decisions have been made and why they are closed. This is where the ADR instinct applies directly. Any decision that could plausibly be re-opened by a model making reasonable assumptions should be explicitly marked as settled, with the reason. If you are using a particular ORM because the team already has expertise with it, say so. The model will not infer organizational context from code alone.
What is currently in progress. The active branch of work, the immediate goals, and any in-flight constraints that have not yet been codified into the codebase itself.
What to avoid. Patterns that were tried and rejected, approaches that seem obvious but do not fit the context, third-party libraries that are off the table for reasons the code does not make visible.
This is not dramatically different from what many developers have been assembling informally under filenames like CLAUDE.md, .cursorrules, or copilot-instructions.md. These tool-specific context files have proliferated across codebases as developers discovered that models perform better with explicit project context at the top of the conversation. What Garg’s framing adds is a practice layer on top of the artifact: the document is not written once at project setup and forgotten. It is updated actively, treated as a deliverable of the session rather than a precondition for it.
Writing It Down Changes the Decision
There is a secondary effect that Garg touches on and that deserves more emphasis. The act of writing an anchor document is itself a useful thinking exercise, separate from whatever benefit it provides to the model.
When you write down why you made a decision, you sometimes discover that the reasoning does not hold. The constraint you thought was hard turns out to be soft. The alternative you dismissed actually fits better now that the requirements have shifted. This is the same dynamic that makes rubber duck debugging work. Externalizing a mental model into language forces a precision that internal reasoning does not require.
Teams that have adopted RFC and ADR practices report this phenomenon consistently: the discipline of writing the decision down often changes the decision, because writing requires committing to a level of specificity that thought does not. Context Anchoring inherits this benefit, and arguably amplifies it, because the document is read frequently rather than archived and forgotten.
This also addresses a failure mode that is common in AI-assisted development: decisions made implicitly through accumulated conversation that nobody would endorse if asked to justify them explicitly. A model and a developer can iterate their way into an architectural corner through a sequence of individually reasonable steps, with no single moment of decision to point to afterward. Writing the anchor document creates those moments of decision. It forces the question: is this actually what we want, or is it just where we ended up?
Where This Sits in the Broader Workflow
Garg’s piece is part of a larger series on reducing friction in AI-assisted development, which also covers Generated Structured Documents, a methodology that treats the specification itself as a first-class input to the AI workflow. Context Anchoring is complementary to that approach: GSD is about how you structure the work before the model touches it; Context Anchoring is about maintaining coherence as the work progresses through multiple sessions.
Together they address a gap that most AI coding tools leave open. Tools like Claude Code, Cursor, and Copilot provide excellent session-level assistance. They do not provide a session management layer. That layer, the practice of deciding what context the model needs, structuring it appropriately, and keeping it current, has to be built by the developer. Context Anchoring is a lightweight framework for doing that.
The investment is modest. A well-maintained anchor document for an active feature branch is probably two to four hundred words. The payoff is a model that starts each session already oriented, that does not re-litigate closed questions, and that proposes approaches consistent with the constraints you have already worked through. Over a multi-day or multi-week engagement, that adds up to something meaningful: less re-explanation, fewer course corrections, and a written record of the reasoning that shaped the code, available to every engineer who works on it afterward.
The practice does not require a new tool or a new workflow category. It requires the discipline to write down what you are doing and why, which is a skill developers have always needed and which AI development has made newly urgent.