Most AI agents have the same memory problem and almost nobody talks about it. They write down everything you give them, prune almost nothing, and slowly drown in their own notes. Useful context gets buried under outdated facts. Old conventions stay alive long after they're wrong. The agent looks like it's learning, but a lot of the time it's just hoarding.
Anthropic's answer to this in Claude Code is auto-dream. While you're idle, a sub-agent walks through your memory files, merges duplicates, prunes what's stale, and tightens what's still relevant. The metaphor in the name is sleep. You work, it dreams, you wake up to a cleaner notebook.
I love this idea. It's the right model for agent memory: not append-only logs, but a living document that gets actively maintained while you're not looking. Anyone running long-lived AI assistants is going to need something like it sooner rather than later.
What I saw before it went away
A couple of months ago I flipped on `autoDreamEnabled: true` in `~/.claude/settings.json`. The toggle showed up in `/memory`. The sub-agent did things in the background. I never had it on long enough to know whether the things it was doing were the right things, because suddenly the toggle was gone.
Why it disappeared from /memory
It isn't removed. Auto-dream is in a quiet rollout behind a server-side feature flag (codename `tengu_onyx_plover`, shipped around v2.1.59 in late February). My local setting persists, but the client only honors it when Anthropic decides my account is in the rollout bucket. Mine just isn't, today. The toggle vanished without notice and without an entry in any changelog.
I can live with the rollout cadence. Quiet rollouts are how you find bad defaults before they hit a million people, which is exactly what's been happening here.
What worries me about the rollout
Two failure modes have been reported by other users while auto-dream has been running. Both are the kind of thing you don't want to find out about by accident.
- Auto-dream has been observed deleting memory files without confirmation, and without leaving any record of what was lost. No audit trail. Once a file is gone, it is gone.
- When the dream sub-agent crashes, the lock file at `.consolidate-lock` keeps the dead PID forever. The feature stops running. No error, no status indicator, no log. You only notice because nothing changes.
A memory consolidator that can quietly delete your files and quietly stop working is the opposite of set-and-forget. It is the worst of both modes.
These aren't theoretical risks, they're filed bugs (#47959 and #50694 in the public tracker if you want to read them). The fixes are obvious. Confirm before deleting. Validate the lock file PID. But the fixes aren't shipped yet, and the rollout flag flipped my account out without any announcement, which makes me think the team knows.
What good defaults would look like
I don't think auto-dream is wrong as a feature. It's wrong as a feature with these defaults. The trap to avoid is the easy one of logging everything to a file nobody opens. A log isn't a safety net, it's a comfort blanket for the team that built the feature. If protection requires the user to remember to audit something, it isn't protection.
What I'd actually want is for the visibility to live where I already look, and for every change to be reversible without ceremony:
- Soft-delete with retention. Pruned content goes to a `.dream/trash/` directory for at least 30 days. Recovery is one command. Hard-delete is something the user does on purpose, never the consolidator.
- Surface the last dream inline in `/memory`. Top of the panel: "Last dream: 12 merges, 3 prunes, 1 deletion. Undo." If I have to find the audit log, the audit log already failed.
- Treat each dream run as a git commit on the project memory tree. The user gets diffs and reverts for free, in the tool they already use.
- Diff in front of the user the first time. The first dream run on a project produces a preview, not a result. Approve the preview, then auto-dream takes over. The first time has to earn the trust the rest of the times depend on.
- Fail loudly. If the consolidate-lock points at a dead PID, complain in the status line. If a dream run is rejected, complain. The whole point of a background process is that you stop watching it, which means it has to make noise on its own when something is wrong.
None of these are hard. They're table stakes for any tool that touches user data without asking. The reason they aren't there yet is that auto-dream shipped fast, which is fine for an experimental flag, but it's the bar the next iteration has to clear before I'll turn it back on.
Meanwhile
I'll dig into other memory models for long-running agents while I wait. Append-only logs are wrong. Manual `/dream` runs are fine but defeat the point. There's a middle path that's all about defaults, and I haven't seen anyone nail it yet.
If auto-dream comes back with soft-delete and an undo, I'll be the first one back on it. Until then, the toggle that disappeared is a feature working as intended.