On 5 October Cognition announced Dreaming for Devin, and at the time of writing the post has been seen over half a million times, which is quite a lot of attention for what is, underneath the launch video, a folder of markdown files.

I mean that as a compliment. I've spent a silly amount of this year writing about AGENTS.md (the NextJS one, the Claude Code fallback one, the DESIGN.md one), and every one of those posts quietly assumed a human was holding the pen. Agent Memory Repo is the other half of that story, the file the agent writes about you.

Where I've landed, said once:

Memory as plain markdown in git is the right call, but the spec lets the agent write with no human in the loop, and the early evidence says the writes are exactly where memory goes wrong, so any memory your teams share should land through the same review path as code.

The spec page is short and properly readable, which already puts it ahead of most standards I've had to sit through. There's a MEMORY.md entry point that agents load at the start of every session, so it's meant to stay small and mostly act as an index. Everything else is one-line bullet entries with optional metadata on the end ([source: ...; added: ...]), and files point at each other with [[wiki]] style links. Each session clones the latest memory, searches it for what the task needs, updates entries as it learns and pushes after every edit.

Dreaming is a separate agent that runs periodically with two jobs. It adds memory by spotting patterns across sessions and saving them as new entries, and it cleans up by merging duplicates, removing outdated entries and checking sources when two entries contradict each other. Nader Dabit says the standard works across any harness, and the install section lists Claude Code and Cursor next to the Devin CLI, so this isnt just a Devin thing. One caveat if you try it locally, the trial on that page doesn't include automatic startup or scheduled Dreaming, so outside Devin you're invoking the skill yourself for now.

Plain files you can grep, diff, blame and revert are exactly the right primitive for this, and I'm relieved nobody tried to sell me a vector database with a dashboard and a per-seat price. Hashif Habeeb put it better than I would have in a reply to the launch:

The most useful sentence about this launch wasn't in the launch post. It was Adhyyan Sekhsaria, who by the sound of it has been building the thing, being refreshingly honest underneath it:

Sukin Shetty picked out the same line and summed it up as "Retrieval works fine. The write is wrong.", which I think is spot on. It's also a very familiar failure if you've ever watched an agent take one comment on one PR and turn it into a religion.

To put it in frontend terms, say you tell the agent, in one session and on one route, not to reach for a server action because that form posts to a legacy billing endpoint. A careful memory writes that down with its scope attached, whereas a careless one writes "prefers API routes over server actions" and from then on every session in every repo inherits a preference you never actually had.

Both entries have a perfectly good source, which is sort of the problem, because a source tells you where a lesson came from and says nothing at all about how far it's allowed to travel. The spec says metadata keys are open, so there's nothing stopping you adding a scope key today, and honestly I'd love to see it become a recommended key alongside source and added.

Step three of the memory loop on the spec page is, word for word, "Update entries as the agent learns, with no human in the loop." For personal memory I can live with that. It's my memory and my agent, and if it decides I adore bullet points I'll find out soon enough and tell it off.

Team memory is a different animal. The spec pitches it for sharing knowledge about customers, processes and tools, so that "a lesson from one member's support investigation becomes available to everyone's agents". Read that again with the over-generalisation problem in mind, because what it describes is a shared AGENTS.md that any agent on the team can append to at two in the morning, with a second agent following along behind deleting whatever it's decided is stale, and it'd be the only shared file in the repo that nobody reviews.

OCTAMEM made the same point about deletions, that a nightly dream which deletes stale nodes "still needs a record of which entries went away and under which rule". Git gives you the first half of that for free, but the rule is the half you'll have to ask for.

None of this needs Cognition to change anything, which is nice, because it's mostly git you already know and a couple of lines of instruction.

• Read the dream. Personal memory can push straight to main, but skim the diff in the morning the way you'd skim a dependency bump. It takes about a minute and you'll catch the weird ones (yes, I am recommending you read markdown diffs over breakfast, and no, I'm not proud of it).

• Team memory goes through a PR. Let sessions and Dreaming write to a branch and open a pull request, then put MEMORY.md and the team folders behind CODEOWNERS, the same trick I suggested for the instrument files in the Uncle Bob post.

• Make scope mandatory. Every new entry names the narrowest repo, path or project it applies to, and Dreaming doesn't get to widen a scope without a human saying yes.

• Deletions explain themselves. When Dreaming merges or removes an entry, the commit message names the entry and the reason, whether that's a newer contradicting source or a duplicate of something else.

Will the agents follow that every time? Probably not, which is precisely why the PR exists, and I'll happily take a slightly slower memory over one that rewrites itself while I'm asleep.