Most agents reset to zero every session — so the project's real memory ends up living in your head, and you retype it every day. AutoDev agents keep memory across sessions and, at the project level, across each other — in three complementary layers that live as plain files on your own disk. No vector database, no proprietary cloud store, nothing you can't open in a text editor.
Close the tab and it’s back to zero — re-explaining the codebase, the architecture decisions and the gotchas you already walked it through yesterday. The real cost isn’t the retyping; it’s that the only durable record of what the project knows lives in your head, where it quietly decays. Run a team of agents and it compounds: you become the memory for all of them, hand-carrying context from one session to the next — the same mechanical relay work that makes you a meat proxy for your own agents, adding nothing and turning yourself into the bottleneck.
Different kinds of knowledge want different homes. AutoDev keeps three separate stores — the code says so explicitly — so prose notes, a personal knowledge graph, and a shared project record never blur into one lossy blob.
Dated markdown files under .autodev/memories/ plus a one-line-per-entry MEMORY.md index. The agent distills what it learned into a short, typed fact — architecture, decision, bug, convention, gotcha or runbook — every few completed tasks. Before it writes, the harness mechanically de-duplicates the index. This is prose recall for a single agent in its own workspace.
Every agent gets the Memory MCP server by default — a structured graph of entities, observations and relations it can query and grow with tools like create_entities, add_observations, create_relations, read_graph and search_nodes. It is the designated home for things like credentials, which never belong in the plain-text notes. Stored as memory.jsonl.
The most substantial layer: a typed, sourced, versioned work-graph at .autodev/graph/graph.jsonl — one append-only JSON-Lines log per project. It is explicitly cross-session and cross-agent: the agent forgets, the graph does not. Nodes carry provenance (which run, which agent, when); several agents in one workspace simply append their own lines and re-read to see each other's.
Every layer is human-readable at rest. Point a text editor at the workspace and the whole memory footprint is right there.
The Memory MCP store deliberately sits beside the installed server package rather than in the workspace — a relative override once silently wrote it into the npx cache, so the default store is used and the backup collector fetches it from there.
Markdown memory and the project graph are files inside the workspace; the Memory MCP graph is a file beside the installed server on the same machine. No cloud database is the primary store — the system is self-hostable by construction. Your keys, your logs, your memory never have to leave the box unless you choose to send them.
There is a portability path: the CLI can bundle the sanitized .autodev tree — markdown memory, the MCP graph and the project graph together — into a ZIP and upload it to the office. It fires on an explicit export request or an optional daily backup, and secrets like the auth token are stripped before the ZIP leaves the machine. This is opt-in restore/portability, not continuous cloud sync and not a live database.
There are two ways in: open the raw files, or use the MCP tools the agent already has.
Open and edit .autodev/MEMORY.md and the files under memories/ like any markdown. To remove a note, delete the file and its index line — the harness only de-duplicates, it does not garbage-collect. Fully human-readable.
Query with read_graph, search_nodes and open_nodes; write with create_entities, add_observations and create_relations; prune with the matching delete_* tools. Or open memory.jsonl directly.
Read with graph_map, graph_search, graph_query, graph_neighbors, graph_toc and graph_stats; write with graph_add_node, graph_add_edge, graph_pin and graph_rollup. There is no hard delete — history is superseded, never erased. Or open graph.jsonl directly.
Most agents are either stateless — reset every session — or bolt on a vector database that returns fuzzy “similar” chunks you can’t audit. AutoDev takes a different path.
| AutoDev memory | Typical stateless / vector-DB memory | |
|---|---|---|
| Recall method | Vectorless: field-weighted TF·IDF, lifted by recency and graph degree — fully explainable, and search returns the node id and why | Embedding similarity from a vector DB — opaque "nearest chunks", hard to audit |
| Persistence | Cross-session and cross-agent (project graph shared by every agent in the workspace) | Often per-conversation, or reset to zero each session |
| Integrity | Enforced invariants: a claim needs a source, an artifact a version, an evaluation a rubric | Usually none — any string can be written as a "memory" |
| History | Append-only; superseded facts are versioned, never deleted — a full audit trail | Overwrite/delete in place; prior state is lost |
| Where it lives | Local-first files on your own disk; self-hostable; opt-in ZIP backup | Frequently a proprietary hosted vector service |
| At rest | Human-readable markdown + JSONL you can open, grep, diff and commit to git | Binary vectors — not meaningfully readable |
UsageService, usage-service and usage service all resolve to one node.Permanent memory is what turns a pile of agents into a team you can actually direct. Spin up an office and your agents carry what they learn into every future session and task — sharing it with each other instead of routing it through you — in the open, on your own machine.