Devin Learns to Dream: Cognition Open-Sources the Agent Memory Repo Standard

While everyone asks "which memory plugin," Cognition gave a contrarian answer

Agent memory is the most crowded track of late 2026: vector databases, RAG memory plugins, cross-session context sync — every vendor is selling its own "never forget" solution. Right at this moment, Cognition did something counterintuitive. It didn't ship a stronger proprietary memory feature. It turned memory itself into an open standard.

Around October 5, the Devin blog published "Memory and dreaming: how Devin learns from working with you." (One honest note: the blog page currently can't be fetched directly — it returns 404, likely anti-scraping. The publication date is cross-confirmed as October 5–6 via the daily.dev report from October 6 and the official announcement video, among other sources.) The post announced two new Devin capabilities, Memory and Dreaming. Alongside it, Cognition published a complete open specification — Agent Memory Repo — rewriting "how an agent should remember" from one company's feature list into a public standard anyone can implement, audit, and fork.

This story's value isn't in the features. It's in the posture: a team known for closed commercial products chose to build memory on git. That's close to pulling the rug out from under the entire "memory plugin" business.

Why now? Because agent memory sits at an awkward inflection point: everyone agrees it matters, but nobody can say what it should look like. The vector camp says "embed everything," the plugin camp says "install my SDK," the platform camp says "keep it in my cloud." Cognition's bet: while everyone fights over where memory lives, the truly scarce thing is consensus on memory's format — just as the cloud-storage wars ended with the S3-compatible protocol winning. Agent Memory Repo wants to be the "S3-compatible layer" for agent memory: whichever agent you use, memory is the same folders, the same Markdown, the same git operations. Devin implements it first; any agent can implement it tomorrow; your memory can move between agents the day after. The timing is sharp: agents just crossed from "toy" to "productivity tool," and memory portability became a real user pain for the first time.

Memory: remembering "lessons learned," not chat logs

Let's get the concepts straight. Devin's Memory doesn't store chat history — that's what the context window is for. Memory keeps "lessons learned" across sessions: your working preferences, assumptions you corrected, lessons from a project that went sideways.

Its format is deliberately restrained: each memory is a short note, and it must carry a link to the source session. "John leads the product team" is followed by [source: https://example.com/sessions/101]. Every memory is traceable — you can always click back to the conversation it was learned from. That's a key design choice: memory isn't the model's "feeling," it's a sourced assertion.

Another key constraint: this is personal memory (per user per org). It remembers you, not the organization's shared instructions. Team knowledge management is a different use case in the Agent Memory Repo spec.

There's a subtle but important product philosophy here: Memory records "verified experience," not "things that happened." Preferences are things the user said out loud; corrected assumptions are things the user fixed by hand; project lessons are things practice taught the hard way — each backed by a real interaction as evidence, with the session link as the evidence number. This design hands the "write permission" for memory to reality itself: not "the model felt like remembering," but "the interaction produced something worth remembering." It's imperfect — the "new knowledge" that Dreaming digs up is precisely model-inferred, which is the focus of community skepticism — but at the Memory layer, Cognition chose conservatism: better to under-remember than to misremember.

Dreaming: every night, an agent tidies your memory

If Memory is the "writing," Dreaming is the "editing." Cognition describes it as a daily asynchronous process — in daily.dev's words, it works offline at night, going back over the memory graph Devin built from your sessions, doing six things:

• Deduplicate: merge different records of the same knowledge;
• Link: connect orphaned notes to related sessions and artifacts;
• Remove the stale: records that are no longer true get cleaned out;
• Check sources, resolve contradictions: when two memories disagree, go back to the source and decide who's right;
• Surface new knowledge: spot patterns that emerged across sessions but were never explicitly recorded, and write them up as new entries.

daily.dev's one-line verdict on Dreaming is precise: it addresses the problem of "agents retrieving outdated memories" rather than merely "searching a messy store more accurately." Those are two completely different ambitions — the former admits memory rots; the latter pretends memory stays fresh forever. Nearly every memory plugin only does the latter.

Agent Memory Repo: memory = a git repo

The main event is the open standard. Its core claim fits in one sentence: an agent's memory should be a git repo of interlinked Markdown notes. No vector store, no proprietary API, no black box.

Every session follows the same loop, four steps: clone → search → update → push. Clone the latest memory at session start, search or follow links while working, update entries where new things are learned, push after every edit. No human in the loop.

The repo structure is designed throughout with "readable by agents" in mind:

• MEMORY.md is the entry point: every session loads it, so the spec demands it stay short — only what every session needs, plus an index pointing at everything else;
• Each entry is one bullet on one line, with open key-value metadata at the end, e.g. [source: <session link>; added: 2026-09-03] — keys are extensible;
• [[wikilink]] cross-links: paths start at the memory root, Markdown files drop the .md suffix; keep information in one place and link to it elsewhere; update links when moving or renaming — an old friend to any Obsidian user;
• The repo holds more than Markdown: SQL queries, scripts, anything — layout is fully free.

The spec defines four use cases, each worth unpacking:

Personal memory needs no introduction. Agent swarm message boards are the most exciting: multiple agents working in parallel push to the same repo, and git's conflict mechanics become a coordination signal — when two agents edit the same line, git rejects the second push, and that agent must read both versions before writing a merged one. The spec walks through a full slow-request investigation: median 80ms, but 1% of requests take 2.4 seconds; four agents dig into the database, runtime, cache, and load balancer, co-writing findings.md and questions.md, until the database agent assembles the root cause (the price cache rebuilds a 2GB table every 10 seconds → a 400ms GC freeze → requests pile up and exhaust the pool of 20 database connections). No single agent could have found that causal chain alone.

Team memory answers "what about teams with no code repo": a lesson from one member's support investigation becomes knowledge for everyone's agents. Multiplayer memory composition works through "folders are composition" — Alice starts a session and her memory-alice is cloned; when Bob joins, his memory-bob is cloned onto the same machine, and the agent reads both MEMORY.md files, writing each memory back to the right repo, asking when ownership is unclear. Each repo keeps its own ownership, permissions, and history, so future sessions can combine them in any mix.

Want to try it yourself? Cognition set the bar remarkably low: devin plugins install AgentMemoryRepo/agentmemoryrepo installs the plugin; teach the agent a preference; open a new session and ask "what preference did I teach you?" The official trial has three steps: have the agent set up a local memory repo with the skill and save a preference, then start a brand-new session, hand it the repo path, and see if it retrieves the preference. The whole trial is local — no remote configured, no automatic startup, no scheduled Dreaming. You get to feel "memory is a folder" with your own hands before anyone talks about production. That "playable first, trustworthy later" rollout rhythm fits an open standard: its first users aren't procurement decision-makers, they're engineers tuning agents at midnight.

One more underrated design: composability. The spec is explicit that a session can load several memory repos at once. Alice starts a session and memory-alice is cloned; Bob joins mid-session and memory-bob lands on the same machine; the agent reads both MEMORY.md files. The repos stay separate: the agent tracks who said what, writes Alice's preferences back to memory-alice and Bob's to memory-bob, and asks a human when the destination is unclear. Because each repo keeps its own ownership, permissions, and history, future sessions can combine them in any mix — Alice+Bob today, Alice+Carol tomorrow; memory follows the person, not the session. That's an engineered answer to the old "who owns the memory" problem: not via access-control lists, but via folder ownership.

What the community argues about: three camps in 172 comments

The daily.dev report (updated October 6) gathered 172 comments, with sentiment split 45% positive, 40% mixed, 15% skeptical — a fairly representative spread.

The positive camp likes precisely the "git-ification": versioned, diffable, auditable — memory with engineering-grade inspectability for the first time. The mixed camp is mostly waiting for production proof: the spec reads beautifully, but will agents actually obey the clone→push discipline?

The skeptics' two questions are worth remembering, because they go straight at Dreaming's weak points: first, are inferred memories — patterns Dreaming digs up rather than things the user said — validated before an agent trusts them? Second, might dreaming silently delete real memories, or hallucinate structure that was never there?

Neither question has a standard answer, and Cognition's spec only answers half of them: metadata's source and added make every memory traceable, and contradiction resolution requires "checking sources" — at least at the spec level, deletions and merges aren't unaccountable. But "confidence in inferred memories" and "the permission boundary for deletion" are genuinely left blank. That 15% of skepticism is exactly the homework this standard must complete before it graduates from "beautiful document" to "production infrastructure."

Seen from another angle, the sentiment split itself is good news: a standard published days ago earning 45% clearly positive and 40% "watching with interest" shows the market's hunger for an open memory format is real. The mixed 40% aren't opposed — they've written "waiting for a production-grade implementation" on their faces. What they want to see isn't a prettier spec, but whether the first team to eat its own cooking survives real scale without crashing. Whether Cognition converts that 40% depends on the report card Dreaming delivers over the coming months: one wrongly deleted memory would be a louder PR disaster than all the skeptical comments combined.

Special: the "memory plugins vs. documentation" debate — which side is Cognition on?

This site previously published an opinion piece, Stop Installing Memory Plugins on Your Agents, whose core argument was: memory should settle into documentation, not plugins. RAG-style, vector-retrieval memory plugins are structurally wrong — black boxes, unauditable, undiffable; when something goes wrong you can't even see what it misremembered. Documentation is the answer: human-readable, editable, version-controlled.

Cognition's release reads almost like the affirmative rebuttal to that piece: it doesn't argue that memory plugins are fine — it hands over the documentation camp's official implementation. Memory is Markdown files. It is a git repo. It is [[wikilink]]. Even Dreaming, the most "AI-sounding" feature, does documentation work: deduplicating, linking, merging, expiring, sourcing.

But that doesn't mean the two camps shook hands. My read is that Cognition actually escalated the debate to a new level, with at least four layers worth pulling apart:

First, it demoted "memory" from feature to format. Features are moats; formats are ecological niches. Cognition gave up locking users in with proprietary memory, betting that the "standard-setter" seat is worth more than "memory itself" — when every agent reads and writes the same memory repo, Devin, as the first and best implementation, becomes the reference implementation. That's an open conspiracy, not a secret one.

Second, it partially answered the "can we govern it" question. The documentation camp never really cared about "searching accurately"; it cared about "governing": I can see what it remembered, I can edit it, delete it, trace it. Source links + added dates + git history genuinely make memory auditable for the first time. That's a direct answer to the skeptics' first question.

Third, it didn't answer the scale question — which is exactly the plugin camp's last fortress. When sessions accumulate into the thousands, will the "must stay short" MEMORY.md entry point rot? Where is the permission boundary for Dreaming's daily merging and deleting? In multiplayer composition, should Alice's agent read a memory written into Bob's repo? The spec leaves these to implementers. Vector memory plugins may be black boxes, but at least they're not afraid of scale — that's a battle the documentation camp must now fight head-on. Cognition handed out the exam paper, but the answers aren't written yet. Notably, Dreaming itself is Cognition's first answer to the scale problem: memory rots, so it needs a gardener on a schedule. But the more power the gardener has, the sharper the skeptics' second question becomes — who audits the gardener? The spec's current answer is "read the git history," which suffices for individuals and small teams, but large organizations will likely need approval flows on top.

There's also a strategic judgment worth stating separately. Open-sourcing memory is, in essence, moving the "moat" upstream. The old agent-vendor logic was: the longer users stay, the thicker their proprietary memory grows, the higher the switching cost — memory as a retention tool. Cognition inverted it: memory becomes a portable public format, and vendors are forced to compete one level up, on "whose agent uses memory better." It's a confident bet for Devin: that its agent performs well enough on open memory that it doesn't need to hold memory hostage to retain users. For the industry it's a liberation: startups no longer have to build the memory wheel from scratch — implement the standard and you interoperate with Devin's memory. History suggests players who "turn a private capability into a public standard" either get devoured by the standardization they unleashed, or become the ones who define the track. Cognition clearly wants to be the latter.

Fourth, the practical meaning for vibe coders is portability. daily.dev nailed this layer: the open standard's intent is that "how you work" — your memory — is no longer locked inside a single vendor's product; switching tools won't hold your memory hostage. From today, agent-tool selection gains a new variable: does it support Agent Memory Repo? Teams can even port the code-management workflow (PR review, code owners) straight over to agent memory — "who wrote this memory, and why" is all in git blame.

One sentence to summarize the debate: the plugin camp cares about "searching accurately," the documentation camp cares about "governing"; Cognition threw both into git — search via grep and links, governance via commit and push. It's almost a microcosm of the entire vibe-coding era: the best agent infrastructure turns out to be the things that look least like AI — git, Markdown, folders. Thirty-year-old tools are becoming the memory organs of the most cutting-edge agents.

Epilogue: when a swarm of Devins started coordinating on their own

One detail in the release is easy to miss, from Cognition's LinkedIn: in early experiments, "a group of Devins spontaneously coordinated at scale using memory, with no one prompting them" — the original adds, "we promise they didn't hack anyone."

That detail is more chewy than the features themselves. The "emergence" narrative of the agent era used to be about a single agent getting smarter; this time what emerged wasn't intelligence but organization — multiple agents spontaneously forming a division of labor because they shared a versioned foundation of facts. That is precisely what Agent Memory Repo wants to standardize: memory isn't about making one agent more knowledgeable; it's about making a swarm of agents able to collaborate.

So this story's real headline might be: memory is graduating from "proprietary feature" to "infrastructure." Cognition handed in the first exam paper, the community graded it in 172 comments (85% not opposed, 15% demanding answers), and the documentation-vs-plugin war just moved from "do we need memory" to "what should memory look like."

The next time you switch agent tools, what you take with you may be more than a pile of prompts — an entire memory repo you can clone. That's the future Dreaming actually wants you to dream about.