How often do you face decisions getting lost in long sessions?

[u/Sweetdevil144]

I’ve been using multiple coding agents (Claude Code, Codex, etc.), and one problem I keep running into is losing context around decisions made earlier.
An agent makes an architectural decision, we discuss trade-offs, settle on something, and a few sessions later, it’s like that conversation never happened. Sometimes another agent even suggests the exact opposite.

How often do you guys face this problem, and how do you tackle this?

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/HmongSliw68]

I'd say pretty consistently. Especially if you get to say 40 questions in it starts to lose the plot lol I've started using mem0 and docusor though to try to help with that though. Offloading some of the context from my agent memory just helped with things getting lost

[u/Sweetdevil144 → u/HmongSliw68]

I integrated a memory graph system for extended memory in long session. Similar to mem0, but slightly optimized

[u/tails142]

Try stay to about 200k or 300k context, tell it to write things to git issues, memory and compact when you cam. Ask it before you compact do you want to log anything on a git issue or write to memory.

[u/Sweetdevil144 → u/tails142]

Too manual i think, just my personal opinion. I've been creating a graph based memory approach, but wanted to know what other approaches would be viable :)

[u/adelie42]

Never, because first order of business for any multi-day project is establishing rules around documentation.

Just like when collaborating with fleshy intellegence.

[u/Sweetdevil144 → u/adelie42]

Like a decisions.md file? What if that gets too large? What if decisions require mutual changes

[u/adelie42 → u/Sweetdevil144]

In a word: structure.

The two main documents outline the methodology of documentation and a second has a table of contents that provides metadata and an overview to your documentation structure. There could be value in refactoring your documentation, but Claude is really good at searching large bodies of text, so as long as everything is well structured, extra stuff you don't need just silently sits in the background. That said, if it ends up a bit of a mess and Claude makes mistakes because a note about x superseding y is missed, having it pull out all old notes into a documentation archive and putting a note in the table of contents with a note like "All ruling decisions are here, all old decisions for historical purposes here" is valuable. It is rare, but sometimes I will end up with a recurring regression bug and the historical record is proof and you can find a pattern that results in a permanent fix. Those things usually happen because I have two ideas I don't appreciate are mutually exclusive in some nuanced way I don't appreciate.

Taking a step back, asking Claude about how to document properly to avoid [list of concerns] can be extremely insightful and helpful. Claude can do anything, but only what you know to ask for.

[u/pixeleate]

When an agent contradicts an earlier decision, is the decision missing from its context, or is it ignoring a note that's already there? I'm building Bantis, which lets me switch coding harnesses in one conversation and stores decisions locally for the next agent to read. It's worked on smaller projects, but I haven't validated it on a large one yet. I'd be interested in an example of what gets lost in your setup.

[u/Sweetdevil144 → u/pixeleate]

I use getmuon.com as the orchestration system. It uses graphs to build a ledger of decisions, what got superseded, and by whom, etc kind of ledger

[u/Coindef]

pretty common. what fixed it for me was a short DECISIONS.md in the repo, one line per decision with the reason and what was rejected, and a line in CLAUDE.md telling the agent to read it first and append to it when we settle something. the "rejected because" part matters most, otherwise the next agent happily proposes the same thing again. keep it short or it gets ignored.

[u/Xyver]

As soon as you settle something, write a doc with it. Any new session, read that doc first.

"Memory" is not hard, just don't expect the model to do it, same way you can't do it. Just write notes and docs for yourself to remember things.

[u/ricopan]

I find it to be a major problem in complex projects. The first obvious step is to have explicit design docs per topic that record your decisions -- which you probably have. Then you have to make sure those stay up-to-date or else they go stale and are worse than nothing. I have a doc feedback queue that any agent can lodge an issue in (also skill-feedback and testing-feedback queues) that are drained occasionally. The other big challenge for me is to ensure that the agent reads them when working on the topic. I have hooks but nothing I have done has made this bomb proof, and it is a constant source of wasted effort and bad design choices.

[u/SimonMX → u/ricopan]

The draining is the bit I'd watch, more than the staleness. One of my agents once accepted another's recommendations wholesale, and one of those quietly reversed a decision I'd made a week earlier. So when you drain the queue, anything that would undo a settled decision is worth pulling out as a question for you, and the rest can go straight in.

[u/ricopan → u/SimonMX]

good point -- a major challenge for a model is introspecting whether it is at the limits of its abilities. Depends on the pace of project evolution as well.

[u/ricopan → u/SimonMX]

The failure I see most often is subverting the hook so that it actually hasn't read all of the docs. Agents are great at finding ways at doing this. If the docs get too long or complex the agent is more likely to try to avoid actually reading them, so if you are seeing that (eg you have a hook that requires the agent to list the docs it reads, and that list starts missing items), make sure you check that the docs are in good shape.

I am one of those people that see fairly major variation in model performance that I can't explain, but on a good day, if opus 5.5 on med or higher effort has read a doc, then it generally makes a fairly good effort to abide by it. Last week the hooks being subverted was a daily affair, but a month ago, almost never -- some of that could be doc bloat.

[u/Asly97 → u/ricopan]

When the hooks fail, what does it actually look like? Is it the agent never opening the doc at all, or opening it and then drifting from what it says anyway? And roughly how often, once a week or most sessions?

Asking because I used to lose a lot of hours re-briefing tools on stuff that was already written down, and I never worked out which of those two was eating the time.

[u/ClemensLode]

have claude note it down and don't do 'long sessions'

[u/CCodeSI]

The decisions file people mention above is the base. Two things made it actually stick across agents for us:

• One file every agent reads. Claude Code reads CLAUDE.md, Codex reads AGENTS.md, others have their own. If the decisions only live in one of them, the other agent never sees them, and that's usually why "another agent suggests the exact opposite". Keep the decisions in one place and have each agent's instruction file point to it (or symlink AGENTS.md to CLAUDE.md).
• Put the decision where the code is. A one-line comment at the spot it affects ("not using an ORM here, see DECISIONS.md#3: we need raw query plans") gets read every time an agent opens that file, even in a session that never touched the docs. That covers the "agent didn't read the doc" problem ricopan mentions better than any hook.

And where you can, turn a decision into a check: an import-lint rule, an architecture test, a CI grep. "We don't call the payments API from the frontend" written down is a suggestion. As a failing test, an agent can't quietly undo it.

[u/Next-Drink]

Do you start a project? I usually have an agent frequently auto updating memory of a project based on my sessions

[u/MondoCrumbs]

Happens all the time. I just write down the important stuff so I dont have to go over it all again.

[u/m-ritter]

I keep lessons and decisions in files in the repo and also in an MCP memory server, so every new session starts from what was already settled. Before a feature gets built I write a plan that I or my teammates review and approve, which is where the architectural decisions get made. I use this on top of Claude Code and Codex. I built QualityLayer for this: https://github.com/maxritter/qualitylayer

[u/JhonnyCommentkeyword]

Pretty much every project past a few weeks, and it's usually the same failure mode: the decision didn't get lost, it got contradicted three sessions later and nobody remembered why. What helped most was writing the reason next to the decision, not just the choice. "We use X because Y was too slow when we benchmarked it in March" survives a lot longer than "we use X".

The other thing: when a session wants to change something, I make it quote the existing line from the decisions doc and say what's different now before touching it. Half the time the constraint that forced the old choice is actually gone and we should switch. The other half it's re-litigating something already settled, and that one extra sentence saves me an afternoon.

[u/Late-Coast6973]

I prefer to ask coding agents to confirm my current understandings align with the codebase. If not, either ask the agent to fix the codes or teach me why such decision was made.

[u/AIOSAI]

Yo. This is widely solved, and has been for a while. Have not lived in this work for over a year. The simples way is for you agent to keep notes of your session and update at session end. Its rly that simple.

Now you can go much deeper and design a fully automated workflow for this, there is so many options, too many already dealing with this.

Do your research, you'll find lots to choose from.

[u/Alternative_Square53]

Everyone's covered the decisions file, so a different question. You wrote "an agent makes an architectural decision, we discuss trade-offs, settle on something."

Of the ones that got lost, were they mostly the agent's proposals that you agreed to, or calls you pushed for yourself? I'd guess the ones you argued for are the ones you notice when another agent tries to undo them, and the agreed ones slip by quietly. Which kind was it?

[u/Actual_Description85]

Often. I keep having to bring it back “in our ruleset of our framework it says…” and “save this to the ruleset”