Devin adds persistent memory with overnight cleanup

• Devin now carries preferences, corrections, and project lessons across sessions through Memory and Dreaming, according to Cognition's launch post.
• The storage layer is a personal Git repository of Markdown notes, with MEMORY.md loaded first and deeper notes retrieved only when needed cognition's memory note.
• Dreaming runs daily in Devin to consolidate overlapping notes, remove transient or stale records, and surface lessons missed during live work Cognition's launch post.
• Cognition has open-sourced the underlying standard for personal memory, agent swarms, team knowledge, and multi-user sessions dabit3's launch post.
• Devin's product memory is scoped to the individual user within an organization, a boundary reinforced by imjaredz's reply.

The Memory and Dreaming announcement describes each session as its own Git checkout, with stale writes rejected instead of silently overwritten. The Agent Memory Repo turns the store into ordinary Markdown, SQL, and scripts connected by [[path]] links. Its local installation guide also says automatic startup and scheduled Dreaming are not included in that trial.

The notable engineering choice is making the memory store inspectable and versioned. Devin writes short lessons, not session transcripts: preferences, corrections, project decisions, and environment-specific gotchas, each linked back to the session where it was learned. The official description says those notes live in a personal Memory Drive, a persistent Git repository of Markdown files.

The session path is deliberately narrow:

• MEMORY.md is the entry point. Devin receives it at session start as general context and an index.
• The agent searches or reads linked notes with its normal code-navigation tools instead of loading the whole archive into the prompt.
• Each session gets its own checkout, commits edits, merges updates, and saves back to the persistent drive.
• A revision check rejects a stale write when another session has already changed the drive. Conflicting edits are surfaced for resolution rather than silently overwritten.

That last step gives parallel sessions a shared source of truth without treating any local checkout as authoritative. The Cognition design explicitly describes concurrent sessions as contributors to one drive, with Git handling revision history and conflict detection.

Live capture only creates the raw notes. Devin's daily asynchronous Dreaming process reviews past conversations alongside the existing memory, then improves the index and the notes around it.

Cognition lists four jobs for a dreaming pass in the open standard:

• Consolidate overlapping notes.
• Remove transient details.
• Find useful lessons that were missed during the original session.
• Remove stale records that no session used.

The system preserves source references and explicit preferences while reorganizing the index. The repo specification adds a source-checking step for resolving contradictions, which is more concrete than simply appending new context forever.

That cleanup loop also exposes the unresolved part of inferred memory. [hwchase17's comment] asks how memories inferred by the system are validated before the agent relies on them. Cognition describes source checks for contradictions, but the announcement does not specify a user-facing approval gate for every newly inferred entry.

Cognition released the storage and synchronization model as an open-source standard intended to work beyond Devin. The repo guide defines a four-step loop: clone the latest memory, search or follow links, update entries as the agent learns, and push after every edit.

The format is intentionally broad:

• A repository can contain Markdown notes, SQL queries, scripts, and other files.
• Entries are one-line Markdown bullets with optional metadata such as source and added.
• [[path]] links connect notes and preserve a navigable graph without requiring every fact to live in one file.
• Several memory repositories can be loaded into one session, while ownership and history remain separate.

The standard's use cases extend past a single user's preferences. Personal repositories carry context between sessions; agent swarms write findings and questions into shared folders; team repositories hold customer, process, and tool knowledge; and multiplayer sessions can combine separate users' repositories when they choose to share them. Cognition says early experiments saw multiple Devins coordinate through the memory without being explicitly prompted to do so, as [cognition's swarm note] reports.

Cognition draws a product boundary between memory and skills in its feature explanation. A skill packages a repeatable workflow, while memory records what Devin learned while applying that workflow, including a preference or the reason behind a project decision.

The distinction changes who maintains the artifact. Skills are deliberately packaged for reuse. Memory accumulates from sessions and is revisited by Dreaming, so the user does not have to stop work to maintain a rule file. imjaredz described the feature as a response to repository clutter from manually written skills and said the system had already been used internally.

The privacy boundary is narrower than the open standard's team-memory examples. Devin's announcement says Memory is personal to the user within each organization, and [imjaredz's reply] says memories are stored individually for each person on the team. Team and swarm memory appear in Cognition's open standard as composable patterns, while the announced Devin feature is presented as personal memory.

A separate Devin Desktop documentation page describes a different persistence surface. It defines Memories as auto-generated context for the legacy Cascade agent and Rules as manually defined instructions at global, workspace, or system levels for enterprise teams.

That page says the default Devin Local agent does not persist memories, and directs users to migrate relied-upon Cascade memories into skills. The cloud announcement's Memory Drive and the Desktop page's legacy Cascade memory feature therefore describe different agent surfaces with different persistence behavior.