{
  "source_file": "0930",
  "source_platform": "Dev.to",
  "author": "Edward Izgorodin",
  "title_listed": "Agent Memory: Everything It Remembers Has the Same Authority, and That Is the Bug",
  "keywords": "",
  "domain": "大模型算法",
  "content_type": "深度技术解析",
  "is_paid_flag": "否",
  "url": "https://dev.to/izgorodin/your-agent-doesnt-need-more-memory-it-needs-to-know-what-its-allowed-to-believe-22j7",
  "publish_date": "2026-08-19",
  "corpus_stage": "",
  "notes": "",
  "id": "0ad9618a7f9a",
  "collected_at": "2026-10-02T14:03:36",
  "title": "Why does my LLM agent keep suggesting outdated library patterns after being corrected? - DEV Community",
  "body_markdown": "Every team that wires long-term memory into a coding agent hits the same wall about three weeks in. The agent remembers plenty. It remembers the migration you abandoned, the library you replaced, the convention one person suggested once in a thread. It recalls all of it with the same flat confidence, and now you are debugging your memory instead of your code.\nThe instinct at that point is to store less, or to store better. Both are the wrong axis. The problem is not how much the agent remembers. The problem is that\neverything it remembers has the same authority\n.\nShort-term versus long-term is not the useful split\nThe common framing separates the conversation you are in now from facts you keep forever. It is a real distinction, and it will not help you, because it says nothing about what the agent should do when two remembered things disagree.\nA more useful split is\nevidence versus policy\n.\nEvidence is what happened.\nThe agent tried a fix and it failed. A user rewrote a function. A test went red. Evidence is cheap to produce, it accumulates fast, and any single piece of it can be wrong or unrepresentative.\nPolicy is what should happen.\nUse pnpm. Tests mirror the src layout. Never touch the legacy billing module. Policy is expensive to produce, because a human usually decides it, and it should be hard to change by accident.\nHold those apart and a lot of confusing behaviour becomes obvious. An agent that treats one observation as policy overfits to a single incident. An agent that treats a merged architecture decision as mere evidence keeps relitigating it. Most memory systems collapse both into one undifferentiated bucket of \"things we know,\" which is exactly why they feel unpredictable.\nThree layers, ordered by how easily they should change\nIn practice the split works better as three layers, because evidence and policy live at different scopes.\nShared project truth.\nArchitecture decision records, API contracts, naming conventions, the deployment runbook. This is policy: versioned, source-linked, and the same copy for every agent on the project. If your agent invents its own answer to \"which database do we use,\" that is not a memory problem, it is a missing shared layer.\nRole memory.\nHeuristics that belong to a job rather than to a project. What a frontend reviewer usually checks. How the QA pass is structured. Which failure modes a migration tends to hit. This is the layer most systems skip entirely, and it is why teams re-teach the same review standards to every new session.\nEpisodes.\nWhat happened on a task: what was attempted, what failed, what feedback followed. Evidence in its rawest form, the layer that grows fastest and rots fastest.\nThese are not ranked by importance. They are ranked by\nhow easily something should change\n. Episodes are written constantly. Role memory shifts slowly. Shared project truth changes only when a human decides it does.\nThe two time axes, and the bug you get free without them\nThis is the part worth stealing even if you ignore everything else.\nSay your codebase used Redux, and last quarter you moved to Zustand.\nWith one time axis, the agent learns \"we use Zustand\" and the older note is overwritten or decays away. Now ask why a component written in March is structured the way it is. The agent cannot tell you. The fact that explains that code has been deleted, because it is no longer current.\nBut \"recorded at\" and \"was true from / until\" are different questions. \"Use Redux\" was\ntrue from January to June\nand was\nrecorded in February\n. It is not wrong. It is\nclosed\n. An agent that keeps closed facts with their validity window can still explain old code, warn you that a pattern you are copying belongs to a superseded era, and avoid confidently rewriting history.\nReplacing a fact instead of closing it is the most common destructive operation in agent memory\n, and it stays invisible until someone asks about the past.\nNone of this is new engineering, by the way. Separating when a fact was true from when the system learned it is bitemporal modelling, standardised in SQL:2011 as application-time and system-versioned period tables (\nISO/IEC 9075:2011\n; Kulkarni and Michels,\nTemporal features in SQL:2011\n,\nDOI:10.1145/2380776.2380786\n). The database people solved this before agents existed.\nEvidence should have to earn its way into policy\nIf evidence and policy are different things, there has to be a path between them, and it should be explicit rather than accidental.\nAn agent observation starts as low-authority evidence. It becomes policy through one of a few events: a\nhuman correction\n, which is the strongest signal there is; a\nmerged ADR or pull request\nthat puts the decision in the repository; or a\nrepeated successful outcome\n, where the same approach has worked often enough to stop being a guess.\nThe important word is\nearns\n. Systems that let a single agent observation write straight into shared knowledge will drift, and the drift is hard to spot because every individual step looks reasonable.\nDemotion matters too and is rarer to see implemented. If a policy keeps producing failures, something should notice. Not delete it automatically: mark it disputed and surface that to a human.\nRetrieval should hand you contradictions, not resolve them quietly\nThis is where most implementations go wrong, and it follows from everything above.\nThe default behaviour of a vector store is to return the nearest matches. If two stored items contradict each other, the one that happens to sit closer in embedding space wins, silently, and the agent proceeds as though there was never a disagreement.\nThat is backwards.\nA contradiction is information.\nIf the store holds \"we use Redux, valid until June\" and \"we use Zustand, valid from June,\" the right move is not to pick one. It is to return both with their validity windows and let the reasoning step deal with it. Same for a policy that a recent episode contradicts: an agent that sees \"convention says X\" next to \"X failed twice last week\" can raise it with you. An agent that sees only the closer embedding match cannot.\nPreserving contradictions costs context budget. That is the honest trade. Losing them costs correctness in a way you cannot detect from the outside.\nThe practical gap nobody mentions\nHere is the thing that surprises teams most, and it has nothing to do with architecture.\nConnecting a memory tool does not make an agent use it.\nYou can wire up a perfectly good backend, expose it over MCP, watch the tools register, and then watch the agent go an entire session without calling any of them. Tool availability is not tool usage. The model has no standing incentive to check memory before acting, and no habit of writing anything down afterwards.\nWhat closes the gap is boring: a standing instruction. Something in the system prompt or the project rules that says, in effect, recall before acting on anything project-specific, and save durable decisions and corrections when they happen. In Cursor that is a rule file. In Claude Code it is the project instructions. The exact mechanism matters much less than the instruction existing at all.\nIf you take one thing from this piece, take that one. It is the cheapest fix on the list and the one most often missing.\nDisclosure: I work on\nMnemoverse\n, a memory engine for AI agents. This article is adapted from the original in our library, which carries the FAQ and the mechanics in more depth:\nAgent memory: evidence versus policy\n.",
  "metadata": {
    "title": "Why does my LLM agent keep suggesting outdated library patterns after being corrected? - DEV Community",
    "description": "Every team that wires long-term memory into a coding agent hits the same wall about three weeks in.... Tagged with ai, agents, architecture, llm.",
    "keywords": "ai, agents, architecture, llm, software, coding, development, engineering, inclusive, community",
    "author": null,
    "og:type": "article",
    "og:url": "https://dev.to/izgorodin/your-agent-doesnt-need-more-memory-it-needs-to-know-what-its-allowed-to-believe-22j7",
    "og:title": "Why does my LLM agent keep suggesting outdated library patterns after being corrected?",
    "og:description": "Every team that wires long-term memory into a coding agent hits the same wall about three weeks in....",
    "og:site_name": "DEV Community",
    "og:image": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fkbvcv8lbfyq95vb9yhp9.png",
    "twitter:site": "@thepracticaldev",
    "twitter:creator": "@",
    "twitter:title": "Why does my LLM agent keep suggesting outdated library patterns after being corrected?",
    "twitter:description": "Every team that wires long-term memory into a coding agent hits the same wall about three weeks in....",
    "twitter:card": "summary_large_image",
    "twitter:widgets:new-embed-design": "on",
    "twitter:image:src": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fkbvcv8lbfyq95vb9yhp9.png"
  },
  "paywall": {
    "listed_paid": false,
    "detected": false,
    "marker": "",
    "public_only": false,
    "policy": "付费/会员内容只保留页面公开可见部分，不绕过付费墙"
  },
  "crawl": {
    "success": true,
    "status_code": 200,
    "error": ""
  },
  "code_blocks": [],
  "images": [],
  "audio": [],
  "videos": [],
  "links": [
    {
      "href": "https://www.iso.org/standard/53681.html",
      "label": "ISO/IEC 9075:2011",
      "type": "a"
    },
    {
      "href": "https://doi.org/10.1145/2380776.2380786",
      "label": "DOI:10.1145/2380776.2380786",
      "type": "a"
    },
    {
      "href": "https://mnemoverse.com/",
      "label": "Mnemoverse",
      "type": "a"
    },
    {
      "href": "https://mnemoverse.com/docs/library/agent-memory-evidence-vs-policy",
      "label": "Agent memory: evidence versus policy",
      "type": "a"
    }
  ],
  "repair_version": 2,
  "repaired_at": "2026-10-14T10:49:34Z",
  "source_url": "https://dev.to/izgorodin/your-agent-doesnt-need-more-memory-it-needs-to-know-what-its-allowed-to-believe-22j7",
  "papers": [],
  "actual_video_files": [],
  "body_chars": 7460,
  "expected_body_images": 0,
  "discovery_status": "ok",
  "delivery_status": "ok",
  "missing_reason": "",
  "raw_html": "attachments/0ad9618a7f9a/pages/source.html",
  "local_html": "attachments/0ad9618a7f9a/pages/article.html",
  "body_base_path": "attachments/0ad9618a7f9a/pages/",
  "body_markdown_path": "attachments/0ad9618a7f9a/pages/article.md"
}