Context Anchoring: The Documentation Practice That AI Development Finally Makes Viable

Context anchoring solves a problem that anyone who has done serious AI-assisted development has hit: the model you’re talking to at message 80 has effectively forgotten what you decided at message 5. Rahul Garg’s article on Martin Fowler’s site names the pattern and describes the fix: externalize decision context into a living document that travels with the session. The description is simple. The implications are worth unpacking.

The mechanics of context drift

Large language models don’t forget in the way humans do. Every token in the context window is technically still present. But attention is not uniform across a long context, and the practical effect is that constraints established early in a conversation carry less weight as the window fills. If you told the model at the start of a session “we’re using PostgreSQL and avoiding ORMs,” that constraint might hold for twenty messages. By message sixty, you’ll see SQLAlchemy suggestions creeping back in.

This is separate from the cross-session problem, which is harder. Every new conversation starts from nothing. The model has no memory of the architecture you argued about yesterday, the tradeoffs you weighed, or the scope boundaries you drew. The session ends and the context evaporates.

Context anchoring addresses both problems with one mechanism: a document that gets injected at the start of every session and updated as the session produces new decisions. The document is the memory that the model doesn’t have.

ADRs are the prior art, but not the answer

Architecture Decision Records have been the standard tool for externalizing software decisions since Michael Nygard described them in 2011. The format is deliberately minimal:

# ADR-007: Use PostgreSQL for primary storage

## Status
Accepted

## Context
We evaluated several storage options against our consistency requirements...

## Decision
We will use PostgreSQL as the primary data store.

## Consequences
The team will manage schema migrations manually. No ORM will be introduced
without a new ADR.

ADRs work well for big, slow decisions that span multiple engineers and months. They accumulate in a docs/decisions/ directory and function as organizational memory.

Context anchoring operates at a different timescale and a different granularity. Where ADRs capture decisions made in planning meetings, context anchoring captures decisions made mid-session: the smaller ones that don’t rise to the level of an ADR but that absolutely shape the code being written. “We’re keeping this function pure because it feeds into the test harness.” “We’re not abstracting this yet because the shape isn’t stable.” “The retry logic here is intentionally simple; we’ll revisit it when we have real error rate data.”

These decisions live in the conversation and die with it. An ADR log is not the right place for them, and they’re too numerous and too transient to write as formal records. The anchor document is where they go.

What the document actually contains

A useful context anchor document has a few distinct sections, and the structure matters because the model will use it differently depending on how it’s organized.

Standing constraints cover things that don’t change session to session: language version, framework choices, style conventions, performance requirements, security posture. This overlaps with what Claude Code stores in CLAUDE.md and what Cursor stores in .cursorrules. The anchor document absorbs and supersedes these for the duration of a session.

Active decisions are the choices made during recent sessions that are still in effect. These have an implicit expiry: they either get promoted to standing constraints, get superseded by new decisions, or become irrelevant as the work moves on.

Open questions are unknowns the session hasn’t resolved. This section is the most underrated part of the structure. Without explicit open questions, the model will silently pick an answer and proceed, and you may not notice until the code review.

Current scope defines what this session is and is not trying to accomplish. This sounds obvious but does real work. Without a written scope boundary, conversations drift. The model follows wherever the most recent message leads.

A minimal anchor document for a feature in progress might look like:

# Context: User Notification Refactor

## Standing Constraints
- Node 22, TypeScript strict mode
- No new npm dependencies without discussion
- All database access through the repository layer

## Active Decisions
- Notifications are fire-and-forget for now; delivery guarantees come later
- We're keeping the old NotificationService interface until consumers are migrated
- Email templates stay in code, not database, for this iteration

## Open Questions
- Should we batch notifications or send individually? Leaning toward batching but no decision yet.
- Rate limiting strategy is undefined.

## Current Scope
Refactoring the notification dispatch path. Not touching the preference system,
not adding new notification types, not modifying the email templates.

This document is small. It fits in a few hundred tokens. The model reads it, and the session starts with shared context instead of blank slate.

The maintenance problem and why AI changes it

The honest critique of any documentation practice is that people stop updating it. ADRs suffer from this chronically. Decisions get made but the record never gets written. The docs/decisions/ directory goes stale. Nobody trusts it.

Context anchoring has a structural advantage here that ADRs lack: the model can write and update the document as part of the session. When you establish a decision in conversation, you can ask the model to record it in the anchor document immediately. The cost of maintenance drops close to zero compared to the human-only alternative, because the tool that produces the decision is the same tool that documents it.

This changes the incentive structure in a meaningful way. With ADRs, writing the record is an additional task after the decision is made, competing with the next task on the list. With an AI-maintained anchor document, writing the record is part of the same tool loop that produced the decision. The overhead is one instruction: “add that to the anchor document.”

Some teams have started ending sessions with a brief “update the anchor document with any decisions from this session” instruction. Others have built it into their system prompt or CLAUDE.md so it happens at decision points without manual prompting. Either approach works; the important thing is that updating the document is part of the workflow, not an afterthought.

Tool support and the gap that remains

Most AI coding tools have partial, uncoordinated versions of this pattern already.

Claude Code’s CLAUDE.md is designed to hold project conventions and instructions, which covers the standing constraints section well. It gets injected into context automatically and persists across sessions. Its limitation is that it’s manually maintained and has no native mechanism for session-level decisions.

Cursor’s .cursorrules serves a similar function for Cursor-specific behavior. Aider, the open-source terminal-based coding assistant, supports reading arbitrary files into context, which can be used to implement context anchoring manually by passing in a document at session start.

None of these tools have a first-class concept of “decisions made in this session that should be recorded and reinjected next time.” That’s the gap context anchoring fills as a practice rather than a product feature. The tooling will likely catch up; the practice is useful now regardless.

The granularity question

One design choice that matters: one anchor document or several?

A project-level document handles standing constraints and architecture decisions that persist across all sessions. A feature-level document covers the current work item, its scope, active decisions, and open questions. A session-level document captures what happened in a specific working block.

These three levels correspond roughly to CLAUDE.md (project), a design note or spec (feature), and a session log (session). The context anchoring pattern is really about making all three explicit and treating them as first-class artifacts rather than implicit knowledge in someone’s head or buried in chat history.

The risk of multiple levels is conflict and staleness. If the project document says one thing and the feature document says another, the model will resolve the ambiguity somehow, and it may not resolve it the way you intended. The practical mitigation is to keep each level scoped tightly and to promote decisions upward explicitly rather than letting them drift.

Why this matters beyond AI sessions

The underlying problem context anchoring addresses is not new. Any long-running collaboration, whether with an AI or with another engineer, suffers from decision drift. Context gets lost. Constraints get forgotten. Work happens that’s inconsistent with earlier choices.

What’s different with AI sessions is the scale and speed of the problem. A human collaborator has continuous memory within a working session. A model does not, or not reliably. The solutions that evolved for human collaboration, meeting notes, design documents, decision logs, all assume readers with persistent memory. Context anchoring adapts those solutions for a collaborator with a context window.

The discipline of writing down decisions as you make them, keeping the document current, and treating it as the authoritative source of session state is good software engineering practice regardless of whether an AI is reading it. The AI just makes the cost of skipping that discipline immediate and obvious rather than slow and diffuse. You feel the absence of the anchor document within the same session rather than six months later when someone asks why the codebase looks the way it does.

That’s the deeper insight in Garg’s piece: context anchoring is not primarily an AI technique. It’s a documentation discipline that AI makes more necessary and, as a side effect, considerably easier to maintain.