Why did my AI agent forget what we decided yesterday?

Your AI agent forgot yesterday's decision because a new session carries nothing from the previous one except what is written in files it reads, and the decision most likely lives in yesterday's chat. Chat history is a transcript, not a memory: it may be stored somewhere, but nothing makes a fresh session open it, and even a resumed session may have summarized the important line away. The agent then infers the project's intent from the code, and if the code still reflects the old approach, it follows the old approach. The fix has two halves. Write the decision as a short record in the repository or your task system, with the reason and what it applies to. Then make reading those records the first step of every session. This page helps you find where the decision went missing, fixes each case, and keeps decisions from drifting again. The general case for durable memory is in AI agent project memory.

Check first: where does the decision live?

Find the decision before rewriting anything. There are four likely places, and each points to a different fix.

Only in chat. You agreed it in conversation and nobody wrote it down. This is the most common case. The fix is to write it now, in the format in the next section.

In a file the agent does not read. It is in a meeting note, a wiki page or a document in another folder. The decision exists but is out of the session's reach. Move it, or link it from somewhere the agent reads at the start.

In a file it reads, but phrased as discussion. 'We talked about maybe moving to UUIDs' is not a decision. Neither is a long thread where the conclusion sits in the eighth paragraph. Rewrite the conclusion as a plain statement.

In a file it reads, clearly written, and still ignored. Then the problem is the code or the session: the code contradicts the decision and is the stronger signal, or the session ran long enough for the record to be summarized away. The last section covers both.

Write a decision record the agent can use

A decision record for agents needs five parts and fits in a few lines. Decision: order IDs are UUIDv7 strings, not integers. Date: 2026-10-29. Reason: integer IDs leaked order volume in public URLs. Applies to: new tables and APIs; existing integer columns stay until the migration task. Replaces: the earlier rule to use auto-increment IDs everywhere.

The reason matters more than it looks. An agent facing a new case can apply a reason; it can only pattern-match a bare rule. The scope line stops over-application, such as rewriting every existing table because it read 'use UUIDs'. The replaces line removes the contradiction with the older rule, which would otherwise sit in the same folder and confuse people and agents alike.

Keep one record per decision in a predictable place, such as a decisions folder, and link it from the tasks it affects. Larger architectural records follow the same idea with more context; architecture decisions for AI agents covers that format. For small decisions, these few lines are enough, and short records are the ones that get read.

The start-of-session read

A record nobody loads is no better than chat. Make the first step of every session a read of what is current, and make the agent show that it read it.

The instruction can be short: 'Before proposing changes, read the task note and the decisions linked to it, and list the decisions that apply to this task.' The list is the useful part. If yesterday's decision is not on it, you find out before the agent writes code against the old approach, not during review.

Keep the read small. Loading every decision the project ever made pushes the important ones down and wastes context. Link decisions to the tasks and areas they affect, and have the session load those plus anything recent. A decision that applies everywhere belongs in the project instruction file; one that applies to the billing module belongs with billing work.

End each session the same way in reverse: if a new decision was made, the session's last step is to write the record. Session handoffs covers what else to carry across the gap between sessions.

When the code or the session wins

Sometimes the record exists, the agent read it, and the old approach still came back. Two causes account for most of these.

The code contradicts the decision. If twenty existing files use integer IDs and one record says UUIDs, the agent editing the twenty-first file sees overwhelming local evidence for integers. Either migrate the old code, or state the exception in the record and repeat the decision in the task text, where the edit happens.

The session ran long. In a long session, early context gets summarized, and a decision read at the start can be compressed out. Shorter sessions are the reliable fix; asking the agent to reread decisions after the tool compacts the conversation is the fallback.

To prevent repeats, review decision records now and then. Mark replaced ones as replaced instead of deleting them, so the history explains why the code looks mixed, and remove records nobody can explain any more. A small, current set gets followed; a large, stale one gets skimmed. Stale project memory covers that cleanup in more detail.

QUESTIONS

Where should I write decisions so my AI agent sees them?

In the repository or task system the agent reads at session start, close to the work they affect. Project-wide decisions can go in the main instruction file. Narrower ones belong in a decisions folder or on the task, linked from the tasks they apply to, so each session loads the few that matter rather than all of them.

Does resuming a session keep yesterday's decisions?

Sometimes, but not dependably. A resumed session reloads the earlier conversation, which may already be summarized, and long transcripts lose early detail. A decision that matters should not depend on a transcript surviving. Write it as a record and have the session read it, whether you resume or start fresh.

How do I stop the agent following old code instead of a new decision?

Put the decision where the edit happens: in the task description, and in the record with an explicit exception for the old code. Better still, schedule the migration so the contradiction disappears. Until then, local code is a strong signal, and a decision stated only somewhere far away will often lose to it.

RELATED GUIDES

• How to read BRAIN FLUID reports and provenance

RELATED HARNESS PAGES

• AI agent project memory AI agent project memory explained: why durable project records beat chat history, and how BRAIN FLUID keeps context with the work.
• Recording architecture decisions for AI agents Recording architecture decisions for AI agents: short decision records an agent will read, where to keep them and how to supersede one.
• How to hand off an AI coding session How to hand off an AI coding session: a short end-of-session routine so the next agent or person can continue without guessing.
• Stale AI project memory Stale AI project memory: how notes and evidence an agent reads fall out of date, how to detect it, and what a freshness check cannot tell you.
• What gets lost when an agent summarizes a long session What gets lost when an agent summarizes a long session: which details survive, which vanish, and how to protect constraints and exact values.