A durable, version-controlled context and governance layer for software development with coding agents.
Русская версия · Adoption guide · Daily usage
AGENTS.md can tell an agent how to start. Memory Bank preserves what the project means, why decisions were made, and how work is verified.
Coding agents are most useful when they share the same understanding of the product, domain, architecture, constraints, and definition of done. Memory Bank keeps that knowledge in Git, next to the code, instead of leaving it in one person's head or a disposable chat session.
It gives humans and agents an authoritative starting point, routes work through explicit delivery flows, and preserves the decisions and evidence needed to resume a task in a fresh session.
Memory Bank is not a wiki, task tracker, or agent runner. It is the control plane around those tools: durable context, ownership rules, lifecycle gates, and verification contracts.
Use it when a project has one or more of these symptoms:
- a fresh agent has to reconstruct product intent from chat history;
- the same rule appears in several documents and drifts;
- implementation starts before requirements, risks, or acceptance are clear;
- a task cannot be resumed without the person who ran the previous session;
- a successful test is reported without a durable link to what was verified.
- Durable project context — product intent, domain language, engineering rules, and operational constraints survive across sessions.
- Clear ownership — Single Source of Truth rules prevent the same fact from drifting across documents.
- Governed delivery — task routing selects the smallest suitable flow for incidents, bugs, research, small changes, epics, refactoring, or features.
- Portable starting point — an agent brings the template into a repository and adapts it from the project's own evidence.
- Optional automation — a companion CLI can later add ownership-aware updates and automated documentation checks.
Memory Bank context and rules
↓
Issue / task
↓
Agent session and delivery flow
↓
Implementation → verification → PR
↓
New durable knowledge returns to Memory Bank
Copy the prompt that matches the repository. It tells the agent to bring in and adapt Memory Bank; the linked protocols define the full lifecycle.
This is a new project. Read the repository instructions, README, and docs, then
follow https://github.com/dapi/memory-bank/blob/main/docs/greenfield-integration-protocol.md.
Bring Memory Bank into this repository, adapt product, domain, engineering, and
ops from confirmed facts only, and create an initial PRD. Do not invent users,
requirements, metrics, architecture, or a delivery plan; do not implement
product features. Finish with changed documents, sources, validation results,
and open questions.
This is an existing project. Follow
https://github.com/dapi/memory-bank/blob/main/docs/brownfield-adaptation-protocol.md.
Before that protocol's installation step, inspect only the existing repository
instructions, docs, code, manifests, CI/CD, configuration, runbooks, and
historical ADRs. Record evidence, sources, confidence, conflicts, and open
questions in an intake PRD; do not invent architecture or a delivery plan. Then
bring in and adapt Memory Bank from the same evidence, validate it, and report
the changed documents, verification, and remaining gaps.
For reproducible use, replace main in a protocol URL with an immutable commit
SHA.
After Memory Bank is adapted, give the agent the task and this prompt:
Read this task, the repository instructions, ./memory-bank/README.md, and
./memory-bank/flows/routing.md. Select the smallest valid route before editing.
If the route is Feature Flow, read ./memory-bank/flows/feature.md; create the
feature package with README.md and brief.md, create design only when required,
and create an implementation plan only after its upstream documents are ready.
Implement the accepted scope, run the validation required by the selected flow,
and update any canonical Memory Bank owner changed by durable new knowledge.
Report the route, artifacts, verification, and open risks. Do not merge, deploy,
or make external changes unless the task explicitly authorizes them.
The daily usage guide explains the task-to-flow-to-verification cycle and its smaller routes.
The dna/ layer defines document governance: source ownership, dependency direction, lifecycle, frontmatter, and navigation. Stable project context lives in product/, domain/, engineering/, and ops/. Requirements and decisions mature through research, PRDs, epics, use cases, feature packages, and ADRs.
For a substantial delivery feature, the context typically develops in three stages:
brief.md design.md implementation-plan.md
what and why → chosen solution → implementation and checks
problem space solution space execution space
(when required)
Documents own intent, requirements, rationale, and contracts. Code owns implementation. A new agent session can therefore restart from the same task and canonical documents without reconstructing the project from chat history.
Every task begins with Task Routing, which selects the applicable lifecycle and its evidence requirements.
This repository is the upstream source. An agent copies the tracked payload in
template/ into a downstream repository: template/memory-bank/ becomes
memory-bank/, while template/init.sh becomes ./init.sh.
| Area | Purpose |
|---|---|
dna/ |
Governance, Single Source of Truth, lifecycle, and document contracts |
product/ |
Vision, customers, metrics, marketing, and roadmap |
domain/ |
Glossary, domain model, rules, states, events, and context map |
engineering/ |
Architecture, testing, coding style, Git workflow, and agent autonomy |
ops/ |
Development, environments, configuration, releases, and runbooks |
research/, prd/, epics/ |
Discovery and initiative-level planning |
use-cases/, features/, adr/ |
Scenarios, delivery packages, and architecture decisions |
flows/ |
Task lifecycles and reusable document templates |
After installation, memory-bank/README.md is the primary index inside the downstream project.
- Adopting Memory Bank
- Using Memory Bank day to day
- Context priming for an agent task
- Optional CLI automation
- Ownership and safe updates
- Repository development
- Detailed overview in Russian
The governance model applies the MECE principle: categories should be mutually exclusive and collectively exhaustive within their declared scope.
The optional CLI for safe updates and automated checks is developed separately
in dapi/memory-bank-cli. This
template is available under the Apache License 2.0.