Memory without lore: agents need reviewable continuity
Agent memory is useful only when the user can inspect, scope, approve, reject, and clean it up. Otherwise it becomes invisible lore that bends every future session.
Memory is where AI products get spooky fast. A model remembers a preference, a repo convention, a release habit, or a workaround. Great. Then it remembers the wrong version of that fact for three months and every future session starts slightly poisoned.
The answer is not “no memory.” The answer is memory with provenance, scope, review, and cleanup. Agents need continuity. Users need control.
Memory is dangerous
Bad memory does not fail like a broken test. It becomes background pressure. The agent stops asking because it thinks it knows. It picks the wrong convention because one branch used it once. It turns a correction into doctrine. That is not intelligence; that is lore.
Memory has blast radius
People treat memory like a convenience feature, but it has blast radius. A memory can change which commands the agent prefers, how it interprets user tone, which files it avoids, what release flow it assumes, and whether it asks before doing something risky. That means memory is closer to configuration than conversation history.
The blast radius gets worse when scopes blur. A project convention should not become a global habit. A global user preference should not be rewritten because one repo needed a weird exception. A temporary workaround should not survive long enough to become architecture.
Memory scope is a safety feature
| Scope | Good use | Bad use |
|---|---|---|
| Session | Temporary plan, branch-specific workaround, current investigation | Long-term preference or repo rule |
| Project | Release flow, test command, package policy, architecture decision | Personal writing style across all repos |
| Global | Stable user preference or recurring security posture | One-off project hack |
Continuity is the prize
The point of memory is not to make the agent feel alive. The point is to stop wasting human time. A project has naming conventions, security rules, release rituals, package preferences, local scripts, and decisions that should survive across sessions.
Memory done wrong vs memory worth keeping
| Pattern | Bad version | MendCode direction |
|---|---|---|
| Preference | Silently assumed forever | Proposed, scoped, approved, editable |
| Project convention | Mixed with global user lore | Stored where the project can own it |
| Correction | Buried in transcript | Extracted into a reviewable memory proposal |
Review gates
MendCode treats memory like a change to the operating context. The agent can propose; the user approves. Project memory stays in the project. Global memory follows the user only when it genuinely applies across repos.
Before a memory becomes durable
- Can the user point to evidence for it?
- Is it project-scoped, global, or only useful for this session?
- Would it mislead a future agent if the repo changes?
- Does it encode a preference, a fact, or a temporary workaround?
What deserves memory
The best memories are boring and operational. They save repeated explanation without adding mythology. “This repo uses pnpm.” Good. “Never commit .mendcode/memory.” Good. “The user likes Spanish technical summaries.” Good. “This bug was weird and maybe related to auth.” Not good enough.
A memory should either prevent a future mistake or remove a repeated clarification. If it only summarizes what happened, it belongs in the transcript or a handoff, not durable memory. The distinction matters because durable context competes for attention with every future task.
Memory candidates
Repo convention
Commands, package managers, generated file rules, release flow, source of truth, branch policy.
User preference
Stable communication style, preferred review level, language, or approval posture across projects.
Architecture decision
A durable choice with rationale: why this data store, route pattern, or package boundary exists.
Never memory
Secrets, temporary guesses, unverified root causes, or one-off hacks that should expire with the branch.
Dream is maintenance
Dream mode should not be mythology. It is maintenance. It reviews what happened, notices repeated corrections, finds stale entries, and proposes cleanup. The value is not that the agent dreams. The value is that the context stops rotting silently.
Workflow diagram
Session produces evidence
Dream consolidates patterns
User approves what becomes durable
Loops need continuity
Loops make memory more important because work can wake up later. A loop that audits docs every night should remember the project documentation rules, but it should not invent new ones. A loop that watches release readiness should know the release checklist, but it should not silently expand its authority.
That is the difference between continuity and drift. Continuity lets a recurring workflow get better at the same job. Drift lets yesterday’s assumption become tomorrow’s policy without a human noticing.
loop.gates = [
"Use project memory for known repo conventions",
"Do not create durable memory without a proposal",
"Report stale or conflicting memory instead of resolving silently"
]Side chat
Memory review is a different conversation from feature work. Side chat gives that conversation a place to live: why should this be saved, what scope should it use, does it conflict with another memory, and should it be rejected?
That matters because memory is not content. Memory is future behavior. It deserves a smaller, sharper review loop.
What good memory feels like
Good memory feels boring. The agent remembers the release rule, asks fewer repeated questions, avoids the known footgun, and does not invent permanent mythology from one weird task. The user can see it, edit it, reject it, and move on.
Agent continuity is useful only when the human remains the editor of what gets remembered.