# The intent names what must not change
nool announce intent --intent "Migrate session storage to Redis; do not touch auth middleware" --target-nodes src/session/
# ... the agent works ...
# Check the semantic reach of what it touched before landing anything
nool debug blast-radius src/session/ src/auth/ --compact
# The proposal is checked against the declared intent.
# Reaching outside the envelope needs a justification, or it is refused.
nool propose --path src/session/store.ts --intent "Migrate session storage to Redis; do not touch auth middleware"
nool propose --path src/session/store.ts --path src/auth/middleware.ts --intent "Migrate session storage to Redis" \
--justification "Auth middleware reads the session type; the signature had to change with it"Fast mode defers semantic validation for local iteration. Use --full for changes that cross architectural boundaries; it blocked both real contract breaks in the benchmark workload with zero false alarms.
What context drift looks like in practice
Context drift is the gap between what an agent was asked to do and what it is actually doing by the time the change is ready. It shows up as scope creep, where a rate-limiting task quietly rewrites the auth middleware; as reversal, where a session undoes a decision an earlier session made for a reason it never saw; and as stale execution, where a plan reviewed against Monday's code is applied to Thursday's. None of these are model failures in the usual sense. The agent did competent work against the context it had. The context was wrong, incomplete or out of date, and nothing in the loop checked the finished change against the original ask.
Why prompts and rules files do not fix it
CLAUDE.md, .cursorrules and system prompts are inputs. They shape how an agent starts, but they carry no state about what has changed since, which decisions are current, or which files another agent is editing right now. A larger context window delays the problem rather than removing it, because the drift happens between sessions and between agents, not only inside one long conversation. Research on state-bound execution on this site makes the formal version of the point: a reviewed plan must bind to the repository state it was reviewed against, or the review proves nothing about the code it eventually touches.
How Nool pins the context to the change
Nool makes intent a first-class object. Before work starts, the agent announces its intent and takes a lease on the scope it expects to touch. When the change is proposed, Nool compares what was actually touched with what was declared. A change that stays inside its declared envelope lands on the fast path. A change that reaches outside it, into files or symbols the intent did not cover, needs an explicit justification or it does not land. That is the Semantic Impact Envelope, and it is checked at proposal time, before the change reaches Git. On the input side, nool context and nool ground assemble ranked, budgeted context with prior findings and the causal chain of the most relevant earlier knot, so the agent is oriented by the ledger rather than by whatever it happened to read first.
Finding drift after the fact
When something is already wrong, Nool reads the ledger backwards. nool debug blame walks the causal chain from a failure to the knot that introduced it. nool debug bisect binary-searches the knots between a good state and a bad one. nool why explains any knot with the intent recorded on it and its ancestors. nool log with a fuzzy query finds the session that touched a subject. Because every knot carries the intent it was proposed under, drift is visible as a mismatch between what was asked and what landed, rather than as an unexplained diff.
A drift checklist for the next agent task
Five habits remove most drift before it starts. State the intent with what must not change, not only what should; the negative clause is what the envelope check enforces. Take a lease with --target-nodes so the scope is explicit and other agents are fenced out of it. Read the context packet from nool context before the agent reads the code, so prior findings and the blast radius arrive first. Run nool debug blast-radius on the touched paths before proposing, and compare it with what you expected. Use --full whenever the blast radius crosses a boundary you did not plan to cross. None of these steps takes more than a few seconds, and together they turn drift from something you discover in review into something the proposal refuses.
Frequently asked questions
- Is context drift the same as scope creep?
- Scope creep is one form of it: the change grows past the ask. Context drift also covers reversal, where an agent undoes a decision it never saw, and stale execution, where a plan is applied to code that has moved. Nool's envelope check catches the first; the ledger and state-bound execution address the other two.
- Does a bigger context window solve it?
- It helps inside one conversation and does nothing between conversations or between agents. Most drift happens at those boundaries, when the next session starts without the previous session's decisions. A ledger that survives the session is the fix; window size is not.
- How is this different from CLAUDE.md or .cursorrules?
- Rules files are instructions read at start-up. They cannot know what changed yesterday, who holds a lease on a file right now, or whether a decision was superseded. Nool records that state and checks the finished change against the declared intent, which a rules file cannot do.
- What is the Semantic Impact Envelope?
- The set of files and symbols a change is expected to affect, declared through the intent and computed as blast radius at proposal time. Changes inside the envelope land; changes outside it need a justification. The envelope page explains the mechanics.
- How do I catch drift in CI rather than in review?
- Let CI attest the landed knot. nool test select picks the tests a knot's changes actually affect from the same dependents closure the proposal used, nool verify --all runs the structural invariants, and nool attest record publishes a signed pass or fail as a ref. A task cannot be verified done from attestations until every obligation on its paths has a trusted pass.