The stores model

The heart of the method is a fixed answer to one question: "where does this piece of knowledge go?" Get that right and an agent never has to guess, never duplicates, and never loses a decision between sessions.

Knowledge is sorted by two axes:

• Scope — is it universal (true for any project), project-specific (true for this one project), or transient (true right now)?
• Audience — does every tool need it, or only the primary agent you drive the project with?

The four stores (by role)

Two of these are required and two are strengtheners:

• Required: the orientation file + the memory store. Project-specific orientation in a plain file at the Atlas root; universal knowledge in a shared memory store that every agent reaches over MCP. Both are part of the framework — with these two, the method works.
• Strengtheners: skills + hooks. If your primary tool supports reusable cheat-sheets and event automation, use them to make the discipline automatic. If it doesn't, the method still holds — you just apply the same discipline by hand.

On the memory store — the framework requires the role, recommends MCP, and names no tool. The universal layer must live in a store that all of your agents can query live, across tools — and MCP is the recommended way to expose it, so the same universal knowledge is one query away for every agent regardless of which one is running. A memory store of this kind is required; the specific tool is your choice and optional. coco is one MCP memory server that plays this role; mem0 is another; any cross-tool, agent-queryable rule store works.

The method does not use per-tool config files (.cursorrules, GEMINI.md, AGENTS.md, symlinked entrypoints, …). They were rejected as unmaintainable: the memory store covers the universal layer cross-tool, and project orientation reaches other agents through the primary agent's delegation prompt.

What the framework is — and what it deliberately is not

Atlas defines a methodology and a discipline. It is project-agnostic: it says where each kind of knowledge belongs and how work flows from idea to shipped, never what your product is.

So, deliberately:

• The framework is not itself a memory, and it does not store a project's knowledge in a pile of files. Unlike spec-driven-development approaches that accrete a file-based "project memory," Atlas keeps the durable universal layer in a shared, agent-queryable memory store (required, over MCP), and keeps project-specifics lean: orientation + standing decisions in one file, current state in a regenerable digest, and buildable work as specs. The Atlas files are planning and orientation artifacts, not a knowledge dump.
• The framework names roles, not products. A memory store is required; which one is your call. The same holds for the primary agent and the optional strengtheners.

The critical boundary: the memory store is universal-only

This is the rule people get wrong, so it gets its own section.

The memory store holds only cross-project, universal knowledge — patterns, anti-patterns, behavior rules, decisions that would be true for an unrelated project too. It is not a per-project description dump.

Every project has many decisions that are durable and real but project-specific: stack choices, "we use X here," product-specific architecture. These are neither universal (so not the memory store) nor transient (so not status). They live in the project's orientation file. Pushing them into the shared memory store would turn it into a per-project description dump and make it useless to every other project.

The test: Would this be true for a different, unrelated project? Yes → memory store. No → orientation file.

Where new knowledge goes — the decision tree

When something worth persisting appears, route it:

1. Product description (how the system works) → not memory. Lives in code or docs in the member repos.
2. Task-scoped instruction ("for this one case, do X") → apply now, persist nothing.
3. Where we are right now / current work → the project's status digest (STATUS.md) — and every line there must trace to a workitem artifact (see 04-spec-lifecycle.md).
4. A standing project-specific decision or convention (stack choice, "we use X here," product architecture, a footgun) → the project's orientation file. Not the memory store.
5. A universal, cross-project pattern / rule / anti-pattern → the memory store — ideally staged first in an optional candidates file for a dedicated curation session, then promoted (or promoted directly if you don't keep a staging file).
6. A buildable workitem (feature / fix / refactor / a plan handed over by another tool) → a SPEC (shape it as a DRAFT first if still undecided), indexed in the backlog. No coding without a SPEC.
7. A known divergence from a memory-store rule that applies here → the deviations file.

Triaging a candidate — when it turns out not to be universal

The candidates file (step 5) stages things that aspire to be universal. It is not a destination: in a curation pass, each candidate resolves to exactly one home. A candidate that, on reflection, is not universal is re-routed, not left in the candidates file.

The one question: Should this guide future work in this Atlas, beyond the SPEC that introduced it?

The last row is the subtle one: an archived SPEC is the record of the work, not where an agent looks for standing rules — orientation comes from CLAUDE.md + the status digest, never from reading shipped history. A durable convention buried in an archived SPEC is effectively lost; promote it to the orientation file. Only knowledge with no future-guiding character stays in the SPEC.

Worked examples (generic — your real conventions live in your orientation file or memory store):

• "Standardize on the project's existing date library; don't add another." → if it's how any project should behave, memory store; if it's "in this Atlas we picked library X," orientation file.
• "This layer maps errors to typed results, not exceptions." → a standing convention of this Atlas → orientation file.
• "For SPEC_0007 we special-cased the legacy importer; don't generalize it." → scoped to that work, no future rule → stays in the SPEC.
• "A memory-store rule applies here, but a legacy area doesn't follow it yet; new work does." → a known divergence → deviations file.

No autonomous writes

Writes to any persistent store — the memory store, the orientation file, skills, hooks — require explicit human approval. New universal rules are promoted only in a dedicated curation session, never mid-task — optionally staged in a candidates file in between. This is what keeps the stores from drifting out from under you.

If your tool has an autonomous file-memory feature (one that writes its own memory files as it goes), turn it off. It will duplicate the memory store with uncontrolled, autonomous writes — exactly the drift this model exists to prevent. The reference tool exposes a single setting for this (autoMemoryEnabled: false); whatever your tool calls it, disable it and let the deliberate stores be the only memory.