Agents drift because each session starts blank, long chats lose their early instructions, and nothing checks their changes against what you decided. Write decisions down in the repository, make every agent read the same file, tell agents to ask before going against one, start fresh sessions from a handover, and review each change before it lands.
What drift looks like
Drift is an agent slowly moving away from what you asked for. It brings back a library you removed. It renames things to its own taste. It follows your rule for the first hour of a chat and forgets it in the second. Each change looks reasonable on its own; together they pull the project somewhere you didn’t choose.
Published research found it often. In a study on 20,574 real coding-agent sessions, 38% of agent failures were an instruction the developer had already given, and not followed. That study didn’t test any tool’s fix, Codee3’s included; the sources are on the evidence page.
Why do AI coding agents drift?
- Every session starts blank. What you agreed yesterday lives in yesterday’s chat.
- Long chats lose their start. As a chat fills up, early messages get summarised or fall out, and your first instructions go with them.
- The rules disagree. A README, an old doc and a chat each say something different, and the agent picks one.
- Nothing checks. If no one compares a change with what was decided, drift only shows up later, as a bug or a rewrite.
1. Keep decisions in the project, not the chat
Write each decision down once, in a file the repository tracks, with an id and the reason. Then it survives the end of the chat, a new agent, and a new day. The decision log guide has the format.
2. Make every agent read the same file
Claude Code reads CLAUDE.md, Codex reads AGENTS.md, Gemini CLI reads GEMINI.md. Point all three at the same rules and the same decisions, so no agent works from an older copy; the Claude Code and Codex guide shows how with one file. Retire any doc that contradicts them, or say at its top that the decision log wins.
3. Tell agents to ask, not to override
Add one line to the instructions, and keep it near the top:
An agent that asks gives you the choice. Answer it, and if you change your mind, record a new decision that replaces the old one, so the next agent sees it too.
4. Start fresh instead of letting chats run long
A short session that starts from a written handover holds your rules better than a long one carrying everything. When a job is done, or a chat has grown long, write down where things stand and start a new session from it. It costs fewer tokens as well: see starting fresh without losing context.
5. Check each change before it lands
Read each change against the decisions before you merge it, one branch at a time. If several agents are working at once, give each its own worktree so you can review them separately, as in running agents in parallel.