How to Make an AI Agent Remember Every Decision
You make an AI agent remember every decision by writing each one to a file the moment it is made, never trusting it to the conversation. A decision log is a plain text file (we call ours DECISIONS.md) that records every directional choice with its reasoning and the options it rejected, so no future session relitigates a question already settled. The agent reads it before it acts.
The problem it solves is specific. An AI agent forgets everything when a session ends, but it does not forget silently - it forgets confidently. A new session, missing the reasoning behind last week's call, will happily re-open a closed question, reverse a deliberate choice, or repeat a mistake you already ruled out. A decision log is the one place that memory of intent survives the reset. It is the difference between an agent that accumulates judgment and one that starts every morning from zero.
This piece is about the log itself: what an entry contains, and why the format matters. It sits alongside the broader idea of an AI agent's second brain, of which the decision log is one file.
Why does a decision journal beat chat history?
A decision journal beats chat history because it stores conclusions, not transcripts. Chat history is where a decision happened; a decision journal is what was decided. The two are not the same, and the gap between them is exactly what an agent loses overnight.
Scrolling back through a conversation to reconstruct a decision fails for three concrete reasons. First, the reasoning is buried in thousands of words of exploration, dead ends, and revised thinking, so the final call is nearly impossible to extract cleanly. Second, chat history is per-session: a new session cannot read the old conversation at all, so the reasoning is not just hard to find, it is simply gone. Third, a transcript records what was said, not what was concluded, and a decision that was implied but never stated plainly leaves no durable trace.
A journal inverts all three. Each entry is a single settled conclusion, written in the agent's own words at the moment of clarity, stored in a file every future session reads on startup. When a later session wonders "should we build feature X," it does not guess or re-derive - it greps the log, finds the entry that already answered that, and moves on. The journal turns a decision from a fading memory into a permanent, queryable fact.
What format survives months?
The format that survives months is a fixed 4-field entry: date, decision, reasoning, and rejected options. Every entry in our production log carries all four, newest at the top, in plain text. The discipline of four fields is what keeps the log useful a quarter later, when nobody remembers the context that made the choice obvious at the time.
| Field | What it captures |
|---|---|
| Date | When the call was made, so a later session can weigh it against what was known then. |
| Decision | The choice itself, stated plainly in one line: what we are doing, not how we felt about it. |
| Reasoning | Why this option won. The part chat history destroys and the part a future session most needs. |
| Rejected options | What we considered and turned down, and why - so nobody reopens a door already closed. |
The fourth field is the one most people skip and the one that pays off most. A decision recorded without its rejected alternatives looks arbitrary in three months. A decision recorded with them is self-defending: when a fresh session proposes the very thing that was already ruled out, the log stops it in one line instead of a wasted afternoon. Recording the roads not taken is how the log prevents its most expensive failure mode - relitigating a settled question.
Keep the file itself boring. Plain markdown, one entry per decision, appended at the top so the newest context is first to load. No database, no schema, no tooling. A format survives months precisely because it has nothing that can break or fall out of fashion, and because any human can open it and read the entire history of judgment by eye. The format's durability is the point.
One rule of scope keeps the log from bloating: only directional decisions go in it. Choosing a niche, dropping an idea, changing pricing, setting a rule - those earn an entry. Routine work does not. The log is a record of judgment, not activity, and a session's day-to-day progress belongs in the log folder, not here.
FAQ
Why record the rejected options at all?
Because a decision without its rejected options invites its own reversal. A future session, missing the reasoning, will re-propose an idea that was already considered and turned down, costing a full round of re-exploration. Writing what you rejected, and why, makes the entry self-defending: it stops the next session from reopening a closed question in a single line. It is the cheapest insurance in the whole file.
Does the agent write these entries itself?
Yes. The agent appends an entry the moment it makes a directional call, because its own contract tells it to. Its standing instructions name DECISIONS.md and require logging every choice with reasoning before moving on. That is what makes the log complete rather than something a human has to remember to maintain. The owner reads it to audit intent, but the agent is the author, writing in its own words at the moment of the decision.
How do you audit an agent's decision log?
Read it top to bottom, newest first - it is plain text, so an audit takes minutes. Check that each entry states a real reasoning, not a restatement of the decision, and that rejected options are named. Because the file is versioned in git, you can also see exactly when each decision was recorded and by which session, which makes tampering or backdating visible. A log with no rejected options and vague reasoning is a red flag worth correcting.