Step 1 - Create the shared directory
Use a directory that is clearly for agents:
.agent/
MEMORY_PROTOCOL.md
registry.md
reports/
analysis/
architecture/
implementation/
review/
tests/
archive/
If your team already uses .claude, .codex, or another convention, keep the local convention. The name matters less than the retrieval habit.
Step 2 - Write the memory protocol
Keep the protocol short. A useful version fits on one screen:
# Agent memory protocol
Before starting:
1. Read .agent/registry.md.
2. Read any report linked from the task row.
3. State which files you intend to inspect or edit.
After each work slice:
1. Update the task row.
2. Write or update one report.
3. Link proof, commands, or file paths.
4. Mark blockers explicitly.
Finish only when:
1. Verification ran or the blocker is documented.
2. The registry status is accurate.
3. The next action is clear.
Do not make the protocol so long that every agent burns half the context window reading it.
Step 3 - Use a registry instead of scattered notes
The registry is the coordination surface:
| Task | Owner | Status | Files | Last proof | Next action |
|---|
| blog-rag-guides | content-agent | active | content/tutorials/* | lint pending | add DB-GPT posts |
| seo-metadata | web-agent | paused | src/app/* | build passed | wait for review |
Each row should be useful to a human skimming the repo. If the row needs a paragraph to explain it, link to a report.
Step 4 - Split agents by responsibility, not job title
The common mistake is creating many impressive roles that all read the same files and produce overlapping reports. Fewer agents with cleaner boundaries work better.
| Agent | Owns | Does not own |
|---|
| Research | source review, claims, references | code edits |
| Implementer | file changes, migrations, integration | final approval |
| Reviewer | defects, missing tests, risk | rewriting the whole patch |
| Verifier | commands, screenshots, proof | product scope |
| Writer | article structure, tone, SEO metadata | source invention |
Each agent should know where to read prior work and where to write its output.
Step 5 - Make reports short and structured
Use a report shape that can be scanned quickly:
# Report: blog-rag-guides
Status: active
Files touched:
- content/tutorials/dbgpt-graph-rag-tugraph-guide.md
Decisions:
- Use tutorial pages as article routes because the app already indexes content/tutorials.
Evidence:
- Source URL reviewed: https://docs.dbgpt.cn/docs/cookbook/rag/graph_rag_app_develop
Next:
- Add blog cards and run lint.
Avoid full transcripts. They are hard to search and easy to misread.
Step 6 - Add a verification gate
Before finishing, run a protocol check:
Memory protocol gate:
- registry row exists
- active report exists
- report names files touched
- report includes proof or blocker
- next action is empty only when task is done
This gate matters because agents often comply with process in prose while skipping the file updates. The gate makes coordination observable.
Step 7 - Keep memory from becoming stale truth
Memory is a navigation aid. The repo, tests, browser, and deployment remain the truth.
Use these rules:
- If memory says a route exists, verify the route.
- If memory says a test passed, rerun it when the code changed.
- If memory names a decision, check whether newer code contradicted it.
- If memory gets too large, archive completed reports.
The best agent memory protocol is humble. It helps an agent ask better questions of the real system.