Compared
Agent memory remembers the conversation. spec-editor builds and maintains the system.
Several kinds of tools hold what an agent needs to know. Each solves a real problem. This page says what each is built for, what it is not built for, and what spec-editor adds. As of October 2026.
Agent memory
What a memory layer is good at
A memory layer, such as Mem0, Zep and Hindsight, keeps what was said. A model extracts facts from conversations, stores them in a vector store, a graph or both, and brings back the ones that look relevant to the next question.
Continuity
Preferences, earlier decisions and context carry over between sessions, so a user does not repeat them.
Almost no set-up
It learns from the dialogue itself. Nobody has to write anything down.
Measured recall
Public benchmarks such as LoCoMo and LongMemEval measure how well facts are recalled from long conversations.
The gap
A memory of the conversation is not a description of the system
Ask an agent to change a real product and it needs more than what was said. It needs to know what should exist, whether it is built, and how anyone can tell. A memory layer is not built for these questions.
| Question | A memory layer | spec-editor |
|---|---|---|
| What is stored? | Facts a model extracted from dialogue. | Requirements you can read: one Markdown file each, with an id, a type, a parent and a status. |
| How do I find one? | By similarity to the question asked. | By its address: a stable id and a place in the tree of the system. |
| Is it still true? | A model decides, as the conversation goes, when a new fact replaces an old one. | The model describes the system as it is now. A change is a diff in git that a person reviews. |
| Who approved it? | There is no review step by design. | Statuses: draft, reviewed, confirmed. |
| How do I know it is done? | Not what it is built for. | Acceptance criteria inside the requirement: a command with an expected result, or a judged check with the evidence named. |
| Which code implements it? | Not what it is built for. | @implements markers link code and requirement both ways, and spec-editor validate checks the links. |
| What did the system actually do? | Not what it is built for. | Operation events and hierarchical logging show which requirements ran. |
| Who writes and tests the code? | Not what it is built for. | A delivery team of agents. A coder writes against the requirement, and a tester runs the acceptance on a test stand, with screens checked by screenshot. |
| Who deploys it and watches it run? | Not what it is built for. | Devops deploys to a stand, promotes and rolls back. Repeating errors in the logs become incidents that come back as sources. |
| Where does it live? | Usually in a store behind an API. | In files in your repository, reviewed in the same pull request as the code. |
| What is measured? | Recall of facts from long conversations. | Whether what was built passes the acceptance of its requirement. |
Together
Use both
They answer different questions. A memory layer is for the dialogue: who the user is and what was agreed last week. spec-editor is for the system: what exists, what should, the proof, and the work of building and running it. spec-editor does not replace a memory layer for conversation.
Memory is enough when
your agent needs to remember preferences and earlier conversations.
You need spec-editor when
the question becomes what exactly should exist, who builds it, and how you know it works.
Other families
Where other tools stop
The same question, asked of five more families of tools.
spec-editor is more than memory for agents. It is a system for writing and maintaining software, from the requirement to the running product.
Requirements
The system described as it is now, with the acceptance written into each requirement.
CodePro
A coder writes it against the requirement and links it back with @implements.
Visual testingPro
A tester runs the acceptance on a test stand and checks every screen by screenshot.
Debugging
The log follows the tree of requirements. Turn up the detail for one element and see what it did.
DeploymentPro
Devops builds, deploys to a blue/green stand, promotes and rolls back.
MonitoringPro
Repeating errors in the logs become incidents, and an on-duty role sends them back as sources.
The model, the links to code and the logging are in the open core. The delivery team comes with spec-editor Pro.
| Item | What it does well | Where it stops | What spec-editor does instead |
|---|---|---|---|
| Requirements management systemsDOORS Next, Jama | Ids, statuses and traces to tests. Long use in regulated work; vendors now expose requirements to agents. | The model usually lives in a system apart from the code, and it describes what should be, not what ran. | Keeps the model in the repository as files, and links requirements to code and to run-time events. |
| Trackers and wikisJira, Confluence, Notion | The common home of requirements; agents can be assigned a ticket. | A ticket describes a change. When it closes, the system as it is now is not written down. | Describes the system as it is now; a Jira or GitHub Issues item arrives as a source. |
| Instruction filesAGENTS.md, CLAUDE.md | Plain text the agent reads first. Simple and portable. | Prose without structure, with no status, no test and no address for one requirement. | Serves an agent only the elements it needs, over MCP, instead of one growing file. |
| Spec kitsSpec Kit, Kiro, OpenSpec | Puts the spec before the code: requirements, design, tasks. | The spec is a plan for one feature, and acceptance is often a checklist that the same agent ticks. | Keeps one model for the whole system, with acceptance written into each requirement. |
| Autonomous coding agentsDevin, Codex, Jules | Carry one task from a description to a pull request. | A task goes in and code comes out. What was learned about the system is not kept for the next task. | A team of roles with review stages and cost control, and a model of the system that stays after the task is done. |
Try it
Start with one module
Describe five requirements of one module, give each a check, and mark the code that implements them. Then let your agent read the model through MCP and see the difference for yourself.