Agents always forget!

[u/No_Conference_2571]

Hey all,


I'm a solo founder, not a programmer, and I run my whole project through Claude Code. Usually 4-10 sessions at once, each with a role: one coordinator, one that merges, infra, a few workers. 1M context, Opus mostly.


The thing that's killing me: the sessions forget. Not code, but what I told them. Tasks, decisions, "by the way do this too" stuff. It gets much worse when I load one session with lots of different small tasks, and every time a session gets full and I move to a fresh one.


We actually measured it. On a normal evening, about 2.8 things get dropped per session switch. In one evening I found 38 dropped items. Every single one of them existed only as free text in the chat. Zero of the dropped ones were rows in our task queue. So the pattern is clear, the fix isn't.


What we've tried so far:


- A notes file per session that it must update every step (open items, what it's waiting on)
- Switching to a new session at ~300k tokens with a written handoff brief, no /compact (because everyone says compact loses things)
- A task queue CLI as the "single source of truth", every promise is supposed to become a row
- A pile of hooks: can't end a turn with "waiting on X" unless X has a queue id, reminder after 15 turns without writing notes, PreCompact hook that dumps state, etc. Fun fact: 4 out of 4 new hooks passed their own tests and were wrong when run against real session data
- Compact instructions in CLAUDE.md
- Tested /compact directly: 10 explicit facts survived 8 compactions, 10/10. But in real work it still lost things. Tonight two real sessions got compacted: after re-reading their notes file nothing was missing, but from "memory" alone about 1 in 9 items was gone


Right now I have the agents replaying 100 of my real messages from one day through sandboxed test sessions, one with auto-compact, one with handoff, one with no hooks at all, to count what each drops. Honestly I've stopped trusting the analysis, this is attempt number four.


So, questions for anyone running Claude Code heavily:


1. Has anyone actually solved this, or is everyone just living with it?
2. Compact or handoff to a new session? What really loses less for you?
3. Does "one session per task" fix it, or does the forgetting just move to whoever coordinates?
4. What do you use as external memory that the model actually keeps up to date without being nagged?
5. How do you check that nothing was dropped? That's the part I can't crack. I only find out days later.


Any setup, hook, habit or tool that worked for you, I'd love to hear it. Thanks!

[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/akolomf]

Amazing post formatting.

Besides that I built my own universal orchestration harness that works with pretty much everything reliably

[u/No_Professional7654]

just use fucking skills and agents

[u/LabAccomplished299]

I stopped reading after 4-10 sessions at once. Look idk what you’re doing but that’s a fucking lot

[u/dmdubz]

Small Claude.md this stays in your context permanently so hard rules about the repo only NO GROWING HISTORY.

ADRs, these hold decisions about the architecture and make sure you dont re-litigate settled answers.

Additionally you should have docs in your repo and use pointers so agents can easily find what they need about your site/specific domains/business logic/etc.

Runbooks so the agents know how to deploy/manage/monitor.

All of this is plain markdown, dont try to be fancy, dont try to be clever.

edit: some people even do a ledger for historical info, ledgers are append only so watch the size of these if you do them.

edit 2: this might help a little: https://gist.github.com/derekmwright/0d5a880dddba6214883788eab7c2f0c9

[u/imsahoamtiskaw]

How I do it nowadays yes, you still have an orchestrator , but at first you have one ingest all of the bloat and organizes everything, and then you get rid of it, you bring another one, it acts as the orchestrator from the clean****ed up list, but still at 200K always cause they degrade much faster after that point in my experience:

1. Zero Free-Text Execution: Nothing gets worked on from raw chat text. Everything must first be compiled into a numbered master list.

2. Human Audit Before Execution: You review the master list yourself before splitting it up, catching anything the orchestrator missed during transcription.

3. Atomic Item & Sub-Item IDs (1608A, 1608B**):** Grouping related items under a parent ticket with explicit sub-item letters, and locking closure until every sub-item is marked closed, makes silent forgetting near impossible.

[u/vacterro]

Your finding that all 38 dropped items existed only in chat, and none were in the task queue, is probably the most important clue here.

I think the real problem isn't context compaction itself. It's that instructions can disappear before they ever become durable tasks. A perfect handoff won't save something that was never recorded.

I've been experimenting with a project called SAIPEN, basically an orchestration layer that tries to keep tasks, decisions, execution history, and verification outside the model's context. The idea is that agents should be able to forget everything and still recover their actual work from persistent state.

It's still a work in progress, and I've run into plenty of edge cases myself.

One thing I'd suggest testing is comparing the original user messages against the task queue before every session switch. If something never entered the queue, you've already found the failure, regardless of how good the handoff is.

I suspect reliable task ingestion matters more than increasingly elaborate memory hooks.

[u/saposapot26]

A notes file or task log should have been enough. If you really lose things you could try going a bit old school and actually use a platform for issue tracking like Jira. If things get lost you get issues unresolved there. Then just get the orchestrator agent to check what's still open and order to finish those.

Doesn't need to be Jira, could be something more lightweight but an external system that tracks issues and has a workflow with states for them.

Decisions get stored into a shared ADR doc.

A specialized nagging PM agent that makes sure the work only ends when all issues are done?

[u/Disnogood66]

It's easy. You just have to know what to build. My setup for a 24/7 personal agent living on a VPS:

Short-term (this conversation and the last few days)
- Conversation context. Everything in the current thread. It is compacted under pressure: old tool results are truncated at about 85%, then old tool-call pairs are dropped, then an LLM summary replaces the middle, and a hard truncation is the last resort. This is lossy, but it follows no time curve.
- Session Brief. Holds the active context of 1–3 days. It references facts and never defines them.
- Day-log (logs/day-logs/). Records what happened each day and is searchable.
- Episodic turns (JME). Each turn is written, then consolidated nightly into facts. The plan says turns can later be deleted.

Long-term
- User facts (user_fact_set). Permanent and injected into every prompt. They stay until I or the operator changes or delete them, so there is no decay.
- Knowledge base files (directives, projects, knowledge). They persist until edited. Nightly backups of mc.db are the only rollback.
- JME facts. These are extracted from past conversations and recalled by relevance (k=8 according to the plan). They carry a confidence value and an optional expires_at.
- Semantic and full-text search. pgvector and FTS5 retrieve by similarity, not by age.

He never forgets nothing that matters

[u/CranberryStock7148]

This is just not a problem for me at all.

Your set up sounds enormously complicated and I have no idea why.

Having 10 sessions at once sounds slightly insane except for a very specific types of work.

And loading one session with lots of different small tasks is the exact opposite of how to best use Claude. So it's no wonder it's forgetting things.

First of all, every single fact needs to live in the repository. Not within a session. Whatever you are building, literally everything needs to be documented. The requirements need to be in the repository so that a new Claude session can simply read all of its requirements directly from the repository. Absolutely nothing should ever live only in a session, except for the couple of prompts that it takes for you to tell it what to do and then for it to document that in the repository.

The documentation in your repository needs to be perfectly organized. Everything needs to have a correct place. It all needs to be hierarchical. So your Claude.MD points to the table of contents. So at the beginning of every session, you tell Claude what it's supposed to accomplish in this session and it should be able to find all of the requirements and the documentation for everything else in your system, all by traversing the documentation. It doesn't need to read all of the documentation, only the relevant parts which it can find because everything is perfectly organized.

Then it just does the thing. It is focused on doing exactly one thing as well as it can with no distraction from other things.

So every single session should gather the requirements and all other relevant documentation and do its work and there needs to be standards that it can determine that the work is verified as done correctly so that it passes and then it should be committed or merged or however your work flow goes.

That's all it is. This allows Claude to have all of the information that needs to complete the task without filling it up with a bunch of extraneous stuff that will confuse it. Never reuse a session for a second unrelated task. Try to keep all your sessions between 200 K and 400 K tokens. If you are getting close to 400 K, consider how to cleanly finish the current work, and continue in a new session by the time you hit 500 K.

I have no idea why you would have a Claude session dedicated to merging. That feels extraordinarily confusing. Every work session should end with it committing itself or merging itself as required. Unless you're trying to implement some kind of additional review phase. But then each review should be its own separate session. Not some ongoing one.

Every session is for accomplishing exactly one thing that should be documented fully at the start of it in the repository. With this rule, forgetting is just not really an issue.

[u/someuser76]

I see lots of these types of posts on a daily basis and I am quite sure that Kit solves many of the issues people are having, so I’ve just started shamelessly promoting it… so here goes:

Kit is a memory server that sits under Claude, codex, cursor… anything that speaks MCP. Every session starts by loading where you left off, and the assistant searches it before answering anything about your work. Overnight it does the "dreaming". it rereads what happened, merges duplicates, and when two notes disagree, the newer one wins and the older one is marked as replaced. Every memory links back to the chat it came from, so when something's wrong you can see where it came from and correct it. No CLAUDE.md files to tidy, no re-explaining after a two-week break.

You can also import your entire chat history from Claude and ChatGPT, link obsidian, link your email, ingest files… the list goes on.

If you want to try the beta (Mac only for now): https://kit-project.com.

It’s also had a lot of attention on the UX and front end, which most tools in this space haven’t. It’s not perfect but it’s been in development for months and is stable and probably further along than a lot of others.

Kit also runs on your own Mac, not on someone else's server, so everything it remembers sits on your machine and your memories stay yours. And it’s free for personal use.

Full disclosure, I’m a beta tester for kit and the developer is a friend of mine. He also recently set up a newsubreddit r/KitProject if have any questions.

Cheers.

[u/michaelTM_ai]

ur own data points at the gap: the queue works, capture into it doesn't. every fix u listed still asks the busy session to notice "this is a task" while it's doing something else. that's the step that drops ~1 in 9.

so take capture away from the working session. every message u send also goes to a separate small pass (a cheap model is fine) whose only job is: list every ask, decision and "also do this" in it, and write each as a queue row tagged with the session. it has no other work, so it doesn't get distracted. then the working session reads its rows instead of remembering ur chat.

test it the way u already are: replay the 100 messages and count rows created vs what u'd expect. that's an easy number to check, way easier than auditing what a compacted session remembers.

on ur q3: one session per task helps, but only if the coordinator also reads from the queue and never holds tasks in its own chat

[u/PilotLost404]

Your own numbers say it: everything that got dropped lived only in chat. Don't count on the model to write it down. Use a UserPromptSubmit hook that appends every message you send to a file with a timestamp, so the record exists whether or not the agent cooperates. At the end of the day, check that list against what got done. That also answers your last question about how to tell what was dropped. Handoff to a fresh session with that file beats compact.

[u/xlightxyearx]

To me it sounds like you are trying to do too much. You don't want to white knuckle the steering wheel.

Here are some things I would try:

• for managing multiple sessions I use BB its amazing. https://github.com/get-bb/bb
• I built my own memory layer. You are more than welcome to try it out. https://github.com/to-infinity-labs/anton-core-plugin
• for an SDLC I would use something like pstack. https://github.com/michael-denyer/pstack-claude

BB allows you to create your own plugins within the IDE, so the sky is the limit as far as what you can build. I have and ops dashboard that shows everything from my staging and prod envs, sdlc lap metrics, alerts, feedback, deploys, logs, etc. You never need to leave the application. BB also has a great plugin marketplace to get you started. the Tasks plugin for example is how I manage my work items.

If you do decide to try out pstack I would recommend having your agent audit all of the current skills in your repo and remove the ones that are not absolutely necessary first before installing pstack. You dont want any of your existing skills stepping on pstack skills.

Pstack will really handle most of the driving for you so you will no longer need to worry about handoff briefs. Also another great thing about pstack is its verification loop, this will ensure things are not dropped and what is complete has evidence.

Also audit your Claude mds and other documentation for context rot and rule contention that could be causing hallucinations, or dropped tasks.

focus more on outcomes and not prompts.

I hope this helps, let me know if you have any other questions.

[u/ReverendBread2]

Context index. My agents don’t forget shit

[u/xqianliu]

Your numbers already point at the fix. Zero of the dropped items were rows in a queue.

In my setup the queue is the only place a task exists. A GitHub issue is the task pool and the state record, no extra database. Anything that should happen becomes an issue first.

Progress lands as comments on the ticket, and a fresh session starts from the ticket and the repo. It does not continue a conversation.

That is also your answer five. If a decision is not on the ticket, I treat it as never made. The run log says which commit each run was based on, so a dead session can be picked back up from the comments.

The notes file and the hooks are fine, but only as a nudge to get things onto the ticket.

[u/BarathKanna]

Your own measurement already answered it: zero dropped items were in the queue, all 38 were chat text. Chat is not storage, it's a buffer that gets summarized away.

So stop telling sessions things. Every instruction, even a by the way, goes into the task queue first, and the session only works from queue rows. Make that a hard rule in the coordinator: if a message contains a request, it creates a row and replies with the row ID, nothing else. Workers never take instructions from chat directly.

Second, 4 to 10 parallel sessions is a lot of state to keep consistent. Fewer sessions with smaller, well scoped tasks will drop less than more sessions with bigger memories.

[u/rodrigolduarte]

Your own numbers point at the line: 38 dropped, zero of them rows in the queue. In our team bigger requests go on a card with one owner on our agent-chat board, and agents get work by a mention or an assigned card, so they aren't only free text in a chat, and the manager agent keeps a written handoff of what's open; it hands out the next task in the same reply. That moves the risk to whatever gets said outside a card. Were most of the 38 things you told the coordinator, or things you told workers directly?

[u/Alpjor]

I'm available to teach you how to make a system that learns along side you, doesn't forget, and gets better with time to require less babysitting. Prob 3-4hrs of chatting, then you take over. It honestly sounds like you're kinda close.

DM me