← All posts

AI Project Drift: What It Is and How to Fix It

AI-assisted projects silently accumulate information loss between sessions. Here's the real pattern, why it happens, and the systematic approach we use to stop it.

  • ai-workflows
  • context-management
  • claude
  • best-practices
  • drift

You start a new AI-assisted session. You catch the agent up with a brief summary. It seems to understand. An hour later, you notice it made a decision that contradicts something you established two weeks ago — something it never forgot in isolation, but quietly dropped when new context crowded it out.

This is AI project drift. It’s not a model failure. It’s an architectural one.

What Drift Actually Looks Like

Drift rarely announces itself. You don’t get an error. You get:

  • A decision that “makes sense” but contradicts a constraint established earlier
  • Repeated work because the agent doesn’t know it was already done
  • Conflicting implementations in different parts of the codebase
  • An agent that agrees with contradictory instructions depending on what’s in the current context window

In isolation, each session looks fine. Across sessions — or at scale — drift compounds silently until a hard reset is the only fix.

The Root Cause

Large language models are stateless between sessions. Every time you start a new conversation, the model begins with no memory of prior decisions, constraints, or context — unless you explicitly provide it.

Most teams handle this with “briefing messages” at session start. The problem: briefing messages are written from memory, they’re incomplete, and they degrade over time. A briefing from three weeks ago may actively mislead the agent about the current state.

There’s a second, subtler problem: intra-session drift. Even within a single long session, models operating on compressed or summarized context can silently drop earlier constraints. The longer the session, the higher the risk.

The Anti-Drift Stack

We’ve run AI-assisted development on real projects for months. Here’s what actually works.

Layer 1: A Live State Document

Not a README. Not a wiki. A single, continuously updated file that describes the current state of the project — phases, active tasks, recent decisions, and blockers — in a format the agent can read at session start.

Key properties:

  • Updated at the end of every session, not once a sprint
  • Short enough to read in full (one screen, not a novel)
  • Opinionated: it says what IS true now, not what was decided once
  • Machine-readable: structured headings, predictable sections the agent can grep

We call ours COORDINATION.md. The name is less important than the discipline.

Layer 2: A Session-Start Hook

A single document isn’t enough if the agent doesn’t read it. We use a session-start hook — a short shell script that fires at the beginning of every AI session and injects the live state document (and a few other critical files) into the context before the first task begins.

This makes “read the current state first” not a guideline but a hard constraint.

Layer 3: Explicit F-Step Tracking

Every unit of work is a named step. Not “refactor auth” — F_AUTH_2: JWT middleware refactor. Steps have statuses (OPEN, IN_PROGRESS, DONE, ERROR). The agent knows what step it’s on, what the evidence requirement is, and what comes next.

This prevents “let’s also do X while we’re here” drift — a session can only advance one named step at a time, and the step definition is the authority.

Layer 4: Pre-Commit Validation

Before any commit, an automated gate checks that the work product matches the step definition. If the agent did something outside scope — even helpfully — the gate flags it before it lands in git history.

What Drift Costs

The obvious cost is rework. The less obvious cost is confidence erosion: when you can’t trust that an agent remembered your constraints, you start adding manual checkpoints, over-specifying every prompt, and reviewing AI output as if it were written by a stranger.

That overhead defeats the productivity case for AI-assisted development entirely.

The Compounding Case for Structure

Every team that starts with “we’ll keep it informal and add structure later” discovers the same thing: by the time structure is needed, the cost of retrofitting it is enormous. Drifted state, lost decisions, inconsistent implementations — cleaning these up takes longer than building the structure would have in the first place.

The projects that stay productive at scale are the ones that treated structure as a foundation, not an afterthought.

What This Looks Like in Practice

Our setup — built on the CoveLab Foundation framework — runs this anti-drift stack on every project. Every session starts with a state injection. Every task is a named F-step. Every commit passes a gate.

The result: new sessions can pick up exactly where the last one left off, with no briefing conversation required. The agent reads the state document and knows what’s true.

It sounds like overhead. In practice, it’s the opposite — it removes the overhead of re-establishing context every time.


Running an AI-assisted project and dealing with drift? CoveLab Foundation ships this entire stack pre-built: hooks, state documents, step tracking, and gates — ready to adapt to your project.