The Agent Forgot What We Decided at Ten in the Morning

"Don't close that chat. It knows our whole pricing now."

Our CEO said this at 16:40 on a Thursday, leaning on the back of my chair and looking at my second monitor. The session with the agent had been open since 9:15. The scroll bar on the right was a tiny line. He was impressed by it, like by a long whiteboard full of drawings.

I was not impressed. Two minutes before, the agent had suggested something we explicitly decided against at ten in the morning. With reasons. With an example. In the same chat.

A long day in one window

The task was discount rules for our yearly plans. Not complicated in code, but full of small decisions. Lena, our product manager, sat with me for the first hour, and we made the decisions together with the agent open. It was a really good hour, to be honest. The agent read our billing module, asked smart questions, and found an edge case with partial refunds that Lena had not thought about.

By 10:15 we had agreed on three things:

1. Discounts never stack. A customer gets the best single discount, not the sum.
2. We round with HALF_EVEN, because our invoice module already does, and the numbers on the checkout page must match the invoice to the cent.
3. We do not touch the old PriceCalculator. It is ugly, but three other places depend on it. We wrap it, we do not refactor it.

Lena left happy. I continued with the agent. Endpoint, service, tests, admin screen for the discount codes. Step by step, small diffs, I read each one. Until lunch, everything was fine.

After lunch the session became slower and a bit strange. At some point the tool showed a short note that it had compacted the conversation to save space. I saw it, and I did not think about it. That was my mistake, not the agent's.

Then it started to forget

At 16:38 the agent proposed the next step. I still have it in my notes:

"To support combining a referral discount with the annual discount, I will refactor PriceCalculator into a strategy pattern. This also lets us apply discounts sequentially."

Combining. Refactor. Sequentially. Three of our three decisions, gone in one sentence.

Then I opened the diff from one hour earlier, which I had approved in a hurry because it was "just tests". In the new helper for test prices I found this:

fun expectedPrice(base: BigDecimal, discount: BigDecimal): BigDecimal =
    base.multiply(BigDecimal.ONE.subtract(discount))
        .setScale(2, RoundingMode.HALF_UP)

HALF_UP. The tests were green, because the test helper and the new code agreed with each other. Both were wrong in the same way. On most prices you would never see it. On some yearly prices the checkout would show one cent different from the invoice. One cent sounds funny, until a customer's accounting team sends you a ticket about it.

I was frustrated. Not angry, more tired. It felt like explaining something to a colleague in the morning and in the afternoon he presents your rejected idea as his new idea. Except the colleague is not lying. He just does not have the morning anymore.

That is when our CEO came by and said not to close the chat.

A long chat is not a memory. It is a whiteboard, and someone is quietly erasing the left side while you write on the right.

Getting the morning back

I told him: "I will close it, actually. But first I will make it write down what it should remember."

He looked at me like I wanted to throw away a full notebook. So I explained it in his words. The chat has a limited desk. When the desk is full, it summarizes old papers and puts the summary there instead. The summary is shorter than the meeting. Things fall out. Usually the "why" falls out first, and the "why" was exactly what Lena and I spent the morning on.

He thought about it and said: "So it's like when I forward an email thread with 'see below' and nobody reads below."

Yes. Exactly like that.

Then I asked the agent, in that old session, for one last job:

Write a file docs/decisions/annual-discounts.md.
List every decision we made today about discounts, rounding
and PriceCalculator. For each: the decision, the reason,
and what we explicitly rejected. Do not add anything new.
Mark anything you are not sure about with UNSURE.

The file came back clean and well structured. And it had a mistake. It said: "Discounts may stack up to a maximum of two." We never said this. I think it was a mix of my rejected idea from 9:40 and its own suggestion from 16:38. No UNSURE marker either.

So I fixed it by hand, five lines, and added one sentence to our CLAUDE.md that points to the decisions folder: "Before working on billing, read docs/decisions/. If a task conflicts with a decision there, stop and ask." I also sent the file to Lena on Slack and asked her to check it. She found nothing else wrong, and she added a line about refunds I had forgotten.

Then I closed the session. Our CEO watched, a bit sad.

Forty minutes in a fresh window

I started a new session and gave it a short brief: read the decisions file, read the diff of the branch, list everything on the branch that conflicts with the file. No code yet.

This is where the agent was really good again. Fresh, with a small clear context, it found four conflicts in two minutes. The HALF_UP in the test helper. A second HALF_UP in the admin preview, which I had missed completely. A half-started "strategy" interface it had created before I stopped it. And one place where a referral code and an annual code were both applied in a loop, which was the stacking problem already hiding in the code from 15:00, before it even proposed it.

Then it found something that was not in the branch at all. It compared the decisions file with the invoice module and asked a good question: the invoice module rounds per line item, but our new code rounded only the total. With HALF_EVEN on both sides, the numbers can still be different by a cent on orders with several seats. Nobody had thought about this in the morning, not Lena, not me.

We fixed all of it in about forty minutes, with small diffs. I added one test that I wanted from the beginning: take 500 random real prices from our database, calculate them with the checkout code and with the invoice code, and assert they are equal. It found nothing. Good. That is the job of that test.

On Friday the feature went live. No one cent tickets so far. I know, it's only been a few weeks.

What I do differently now

1. Decisions go in a file, not in the chat. After any meeting where we decide things with the agent open, I ask it to write a decisions file with reasons and rejected options. Then I review it like code, because the summary can be wrong too.
2. Ask for UNSURE markers, and still don't trust the absence of them. The agent made a confident mistake in its own summary. A human reads the file before it becomes the truth.
3. When the tool compacts, I treat it as a new colleague. If I see the compaction note, I re-check the important constraints before the next step. Often I just start fresh with the file.
4. Start fresh with a narrow job. "List conflicts between this branch and this file" is a great first prompt in a new session. Small context, clear question, and the agent is suddenly the smart one again.
5. Tests should not agree with the code by accident. My test helper and my code had the same bug. Now money tests compare against a different source of truth, like the invoice module, not against a helper written in the same session.

I still don't know what the right session length is. Some days one long session works fine. Some days the agent forgets the morning by 14:00. I am experimenting with closing it after every finished step, and so far I like it.

How do you keep decisions alive when the conversation that made them is gone?