Coding assistants
Memory for coding assistants
Your assistant reads the code every session and the reasoning behind it never. Give it the decisions, the rejected approaches, and the reason that odd function exists.
Today
The assistant can read every line in the repository and knows nothing about why any of it is that way. It suggests the approach the team tried and abandoned in March, because the abandoning happened in a pull request comment and a Slack thread. It rewrites the careful thing as the obvious thing, because the reason for the care is in a postmortem it has never seen. Every session you re-explain the same three constraints.
With a memory
Decisions, constraints and rejected approaches live in a store the assistant queries over MCP. The reason a function looks strange is retrievable next to the function. New people get the same context the assistant does, from the same place, which is usually the first time that has been true.
What that looks like
Rejected approaches stay rejected
The thing that was tried and did not work is remembered along with why, so it is not proposed again next quarter as a fresh idea.
The constraint outlives the person
Why this service cannot use a background worker, why that column is denormalised. Written once, available to everyone and to the assistant.
Review comments become durable
A connector reads the discussion where decisions actually happen, so the reasoning in a pull request does not disappear when the branch is deleted.
The shape of it
{
"mcpServers": {
"persistmemory": {
"url": "https://mcp.persistmemory.com/mcp",
"transport": "http"
}
}
}What this does not do
It does not read your codebase for you. The assistant already does that well, and duplicating it would mean a stale second copy of something that is accurate by definition. This holds what the code cannot say about itself.