## Definition **Auto-memory** is the harness behaviour where the agent observes the conversation and writes durable memory files on its own initiative. Used well, it's a force multiplier; used badly, an entropy generator. ## When It Helps - User explicitly asks: *"remember that we always use the `slim` Docker image."* - User **corrects** the agent's approach: *"no, don't mock the database — we tried that and got burned."* The correction becomes a memory. - A non-obvious decision is reached after deliberation; write it down. ## When It Hurts - Writing memories for every passing detail. Files balloon. - Writing contradictory memories without reconciliation. - Paraphrasing the code. The code is its own memory. ## Discipline - **Reviewable.** Every auto-memory write should be visible. Don't hide them. - **Editable.** Memory is a directory of files; treat them as code. - **Decay-aware.** When a memory is contradicted, **delete or update**. Never let two contradictory memories coexist. ## Anatomy of a Useful Entry ```markdown --- name: tenant-isolation description: Decision and operational rules for tenant isolation metadata: type: project --- Tenant isolation is enforced via Postgres row-level security. All tenant-scoped tables must include `tenant_id` and an RLS policy. **Why:** We picked RLS over separate DBs at ~3k tenants; see ADR-0042 for the full reasoning. **How to apply:** When generating migrations touching tenant-scoped data, add the RLS policy template from db/migrations/_template_rls.sql. ``` The explicit `Why:` and `How to apply:` lines let the model *generalise* the memory to new situations instead of just quoting it. ## Audit Cadence Quarterly: have an agent read the memory directory and list entries it believes are no longer applied in the codebase. Delete what's dead. ## Related - [[Layered Memory Architecture]] - [[Context vs Memory]] - [[Architecture Decision Record]]