Warum AI-Coding-Agenten nach fünf Sessions widersprüchlich werden

Disclosure: this article was drafted with an AI assistant (Claude). #ABotWroteThis

An AI coding agent starts every session knowing nothing about the last one. That one fact explains most of the "the agent contradicts itself" complaints. It is not a bad model. It has no memory, and you are the only thing connecting session 1 to session 5.

Here is a setup that moves that memory out of your head and into files the agent reads. It is three small files, one short prompt, and one rule for risky work.

Context loss. You open a new session and retype the project background from memory. You drop a constraint without noticing, so the output is wrong in a way you only discover later.

Reopened decisions. Picture a pricing page. You settled on three tiers after thinking it through. A fresh session sees an unfinished page, proposes two tiers, and has no way to know why you chose three. You either re-argue it or accept the regression.

Both come from the same place: the reasoning behind the project lives in your head or in a chat that is now closed.

The master prompt is the stable background you paste or reference at the start. The session line is one sentence: the scope for today, plus "read PROGRESS.md first". The middle layer is where most of the value is, so the rest of this article covers it.

Claude Code reads CLAUDE.md automatically at the start of a session, so every line in it is read every time. That is the reason to keep it short. Put in it only the conventions that differ from the agent's defaults.

# Harbor Lane Tutoring Marketing site and community bot for a one-person tutoring business. ## Commands - Dev: `npm run dev` Test: `npm test` Lint: `npm run lint` ## Conventions that differ from defaults - Public copy never promises grades, scores, or admissions. - Price identifiers live in `config/prices.js`; never hard-code them. - `src/lib/api-types.ts` is generated; never hand-edit it. ## Where state lives - Status and next action: PROGRESS.md. Decisions: DECISIONS.md. ## Rules - Plan, then wait for written approval, before touching payments or data. - Never read or print.env* files. Reference secrets by variable name only. - Run test and lint before declaring work done. Enter fullscreen mode Exit fullscreen mode (Harbor Lane is a made-up example project.)

Good entries are surprises: a generated file, an unusual tool, a rule about public copy. Bad entries restate defaults ("write clean code") or hold things that change ("we are working on the webhook"). If a line only repeats what the agent would do anyway, delete it. A rule of thumb is to stay around 40 lines.

Every real decision gets a dated entry in a fixed format:

### D-004: Map payments to roles through a config table - Date: 2026-03-11 - Decision: Price identifiers map to tier roles in config/prices.js. - Why: Prices will change; the logic should not. - Alternatives considered: hard-coded if/else on amount (breaks when prices change); a database table (more machinery than three tiers justify). - Revisit if: tiers exceed six, or non-developers need to edit them. - Status: Active Enter fullscreen mode Exit fullscreen mode Each field does a job:

Never delete an entry. When you reverse a decision, add a new one that supersedes it and mark the old one Superseded by D-NNN. The history is the point.

This file answers three questions: where are we, what is blocked, what is next.

## Status board | Phase | State | Gate | |---|---|---| | 1. Website | In progress | npm test passes; pricing page renders | | 2. Payment-to-access | Waiting on Phase 1 | Test-mode payment creates a role and channel | ## Next action Wire the Standard tier payment link into the pricing card; run the render check. ## Blocked - Live payment links: waiting on account verification. Enter fullscreen mode Exit fullscreen mode Three habits keep it useful:

For anything that touches money, customer data, going public, or deletion, split the work into three steps:

Today: the payment webhook handler. Plan first. List the files you will touch, the events you will handle, and the failure cases. Wait for my approval. Enter fullscreen mode Exit fullscreen mode One detail matters here: an approval you gave in conversation does not exist for the next session. Record it in PROGRESS.md ("Phase 2 webhook plan: approved 2026-03-12 with one change, 7-day activation expiry"). If it is not written down, treat it as not given. And approving a plan is not approving going live.

Open: paste the master prompt, then add the session line (scope, "read PROGRESS.md first", and the gate if there is one).

Close: have the agent update PROGRESS.md (status, next action, blockers). Any new decision gets a DECISIONS.md entry. Ask it to state what it changed and what it did not verify.

Reading is reliable; remembering is not. Five minutes of closing routine saves the time you would otherwise spend reconstructing context next time.

If a decision keeps coming back, the entry is missing its "why" or its "revisit if". What does your agent keep reopening?