Cognition has given Devin a long-term memory that you can actually read. Memory and Dreaming, announced October 5, 2026, store what Devin learns across sessions as markdown files in a git repository, and a background agent called Dreaming tidies that repository on a schedule. Alongside the Devin feature, Cognition published Agent Memory Repo, an open spec for the same pattern, with a public GitHub repository under the MIT license.
The interesting part is not that a coding agent remembers things. Most harnesses already do something like that. It is that Cognition chose plain files plus git as the memory substrate, then published the format so that Claude Code, Cursor, and other agents can share it. That is a bet that agent memory should look like a codebase, not like a hidden vector database.
TL;DR: what shipped and the questions people ask
| Question | Short answer |
|---|---|
| What is it? | Persistent cross-session memory for Devin, plus an open spec called Agent Memory Repo |
| Where does memory live? | In a git repository of markdown files, with MEMORY.md as the entry point |
| What is Dreaming? | A dedicated agent that runs periodically to add patterns and clean up stale entries |
| Is it Devin only? | No. The spec is tool-agnostic; a Devin plugin and an agent-memory-repo skill exist |
| License | MIT |
| Cost | Reported as no additional cost for existing Devin users, via the Customize menu |
| Can I try it without a server? | Yes. Cognition says a local trial needs no remote configuration |
| Main risk | A memory the agent writes itself can also store wrong or stale beliefs |
What Cognition announced
According to AlphaSignal's coverage, Cognition shipped Memory and Dreaming for Devin together with the Agent Memory Repo spec. The memory system persists lessons across coding sessions as markdown files in a git repository, so an agent can retain discoveries about project structure, naming conventions, and deployment quirks instead of rediscovering them every time.
The practical point: the second time you ask Devin to touch your deploy script, it should already know the quirks it found the first time.
The same coverage says the feature is available now to existing Devin users through the Customize menu. We could not verify pricing beyond that report, so treat the "no additional cost" detail as reported rather than confirmed on a pricing page.
How Agent Memory Repo works
The spec page describes a four-step memory loop that any agent can follow:
- Clone the latest memory repository.
- Search it for what is needed, or follow links between entries.
- Update entries as the agent learns something.
- Push the changes after edits.
Memory entries are markdown bullets with optional metadata such as a source link or the date added. Entries link to each other with a double-bracket path syntax, so the repository behaves like a small wiki rather than a flat list. A MEMORY.md file is the entry point and is loaded at the start of a session.
The GitHub spec is deliberately loose about layout: organize files and folders however you want, and the repo can also hold SQL queries, scripts, and other files. It leans on git for everything hard. In the spec's words, "Git gives memory a history, a way to merge, and permissions."
Three consequences follow from that choice.
- History. Every change to what the agent believes is a commit. You can diff yesterday's memory against today's, blame a bad entry, or revert it.
- Merging. When a swarm of agents works in parallel, git merges their changes and surfaces conflicts instead of silently overwriting one agent's notes with another's.
- Permissions and composition. Multiple memory repos can load into one session. Each keeps its own ownership, permissions, and history, so a personal memory repo, a team repo, and a project repo can coexist without being flattened into one blob.
What Dreaming actually does
Dreaming is the maintenance half of the system. The spec describes it as a dedicated agent that runs periodically with two jobs:
- Add new memory. Spot patterns across sessions and save them as new entries.
- Clean up memory. Merge duplicates, remove outdated entries, and resolve contradictions.
Launch coverage describes it as a daily background pass that reviews past conversations alongside the current memory repository, consolidates overlapping notes, drops transient details, captures lessons the working agent missed, and deletes records that are no longer used while keeping source references and user preferences intact.
The name is not an accident. Anthropic's Claude Managed Agents dreaming feature uses the same metaphor for offline memory consolidation. The convergence on one word tells you where the field is heading: working sessions are for doing, and a separate offline pass is for deciding what is worth remembering.
How this compares with other memory approaches
explainx.ai has covered several memory designs recently. Here is where Agent Memory Repo sits among them.
| Approach | Who writes it | Storage | Versioned and mergeable | Our coverage |
|---|---|---|---|---|
| CLAUDE.md and similar instruction files | Mostly the human | One markdown file per scope | Via normal git, by convention | What is CLAUDE.md |
| MEMORY.md persistence | Agent and human | Markdown files | Via git if you commit them | What is MEMORY.md |
| Karpathy-style LLM wiki | The agent compiles it | Linked markdown pages | Via git | LLM wiki pattern |
| Local memory stores such as MemPalace | Agent | Local database | Depends on the tool | MemPalace guide |
| Managed memory layers | Platform | Hosted, scoped by agent or user | Platform-defined | Managed Deep Agents user memory |
| Agent Memory Repo | The agent, groomed by Dreaming | Git repo of linked markdown | Yes, as a core design property | This post |
The closest relative is the wiki pattern. Agent Memory Repo is essentially that pattern with a formal entry point, a maintenance agent, and a promise that different tools can read the same repository. It also sits near the argument in Agents don't need memory, they need documentation: if memory is just well-kept documentation, then git is the natural home for it.
Why git is a smart substrate for agent memory
Most agent memory failures are not recall failures. They are trust failures. Nobody can tell why the agent believes a thing, when it learned it, or whether it is still true. Git answers each of those directly.
Auditability. A bullet with a source link and an added-on date can be checked. A vector embedding cannot be read by a human reviewer at all.
Rollback. If Dreaming merges two notes badly or deletes something useful, the previous state is one revert away. That is a much better failure mode than a managed memory service with no history.
Review. Teams already review code. A memory repo can be reviewed the same way, which matters when an agent's notes will steer later runs. The same reasoning shows up in our coverage of Cloudflare Artifacts, which gives agents git repos: git is becoming the shared language for agent state.
Portability. Because the format is plain files, moving from one tool to another does not mean exporting from a proprietary store. The spec lists implementation support for Devin CLI, Claude Code, Cursor, and other agents.
How to try it today
Cognition says a local trial needs no remote configuration, and it points to two entry routes: a plugin for Devin installed through the CLI, and an agent-memory-repo skill distributed via npm for other agents. Skills are the same packaging idea we explain in what are agent skills.
A sensible first experiment, independent of which tool you use:
- Create an empty local git repository for memory, separate from your project repo.
- Add a MEMORY.md with a few bullet entries about your project: build command, test command, deploy gotchas.
- Let your agent follow the clone, search, update, push loop for a week of normal work.
- Review the commit log at the end of the week. Which entries are useful, which are noise, which are wrong?
- Only then consider automating a consolidation pass like Dreaming.
Step four is the one most people skip, and it is the one that tells you whether automated memory is helping or quietly polluting your context. For the general discipline of keeping agent loops honest, see our loop engineering guide for coding agents.
What can go wrong
An agent that writes its own memory can also write its own mistakes into it. A few failure modes are worth planning for.
- Confident wrong lessons. If an agent concludes something from one flaky run, Dreaming may promote it to a pattern. Source links on entries help, and a cleanup pass that resolves contradictions targets the same problem.
- Over-pruning. Removing outdated entries is only safe if the agent can tell outdated from rarely used. Keep memory in git so deletions are recoverable.
- Context bloat. MEMORY.md is loaded at session start. If the entry file grows without discipline, every session pays for it in tokens. Use links to deeper notes rather than inlining everything.
- Prompt injection through memory. Anything an agent reads while browsing or reading issues could end up as a memory entry and then be loaded into every future session. Treat memory repos like code that gets executed: review what lands in them. This is the same class of risk as MCP tool poisoning.
- Shared-memory leakage. Composing a personal repo with a team repo is powerful, but the permissions live in git. Make sure private notes never land in a shared repository.
We have not run Devin's Dreaming pass ourselves, so everything about its behavior in this post comes from Cognition's published description and launch coverage. Judge it on your own repositories before trusting it with anything important.
Why this matters beyond Devin
There are two reasons to pay attention even if you never use Devin.
First, interoperability. Today each harness invents its own memory format, and switching tools means losing what the agent learned about your codebase. A shared, file-based spec that several agents can read lowers that switching cost, the same way MCP lowered it for tools.
Second, the maintenance agent is becoming a standard part of the stack. Anthropic's managed agents, open-source harnesses, and now Cognition all describe an offline pass that consolidates what happened. Expect memory hygiene, not just memory storage, to be the differentiator in the next round of agent products.
The caveat is that a spec published by one vendor is not yet a standard that the whole ecosystem has agreed on. The repository is young, and adoption by other tools is what will decide whether it becomes common. Watch how many harnesses ship native support rather than relying on a plugin or skill.
Bottom line
Cognition's launch is a practical answer to a real complaint: coding agents forget everything between sessions. Storing memory as a git repo of markdown, grooming it with a Dreaming agent, and publishing the format under MIT makes the memory inspectable, reversible, and portable. It does not remove the hard problem of deciding what deserves to be remembered, but it gives you the tools to audit the answer.
Related reading
- Claude Managed Agents dreaming and multiagent orchestration
- What is MEMORY.md and agent persistence
- What is CLAUDE.md persistent memory in Claude Code
- Karpathy's LLM wiki pattern for agent memory
- Managed Deep Agents 0.8 user memory
- Agents don't need memory, they need documentation
- Cloudflare Artifacts: git for agents
- Official: Agent Memory Repo and the GitHub spec
Details are accurate as of October 5, 2026. Product availability, pricing, and the spec itself may change; check Cognition's pages for current information.