{"slug": "how-do-you-design-memory-systems-for-long-running-ai-agents", "title": "How do you design memory systems for long-running AI agents?", "summary": "Michael, in a discussion on designing memory systems for long-running AI agents, advises that the runtime, not the model, should serve as the memory system, with applications making final decisions on durable memory. He recommends using a relational database like SQLite for prototypes or Postgres for serious systems, storing typed records with metadata, and retrieving narrowly based on the current objective while persisting broadly. The approach shifts the prompt from being the memory container to a temporary working view over external state.", "body_md": "Hi Michael, happy to discuss it here.\n\nThe main design rule I use is that the model is not the memory system. The runtime is.\n\nFor question 1, I would split the decision into layers.\n\nThe application should always make the final decision about what is allowed to become durable memory. The LLM can help classify or propose memory candidates, but I would not let it directly write permanent state without rules around it.\n\nA practical flow is:\n\n-\nCapture events from the run.\n\n-\nExtract candidate memories or state changes.\n\n-\nClassify them by type.\n\n-\nApply policy rules.\n\n-\nStore only what is useful, verified, or needed later.\n\n-\nKeep uncertain items marked as uncertain rather than treating them as facts.\n\nFor question 2, persistence does not need to start fancy.\n\nA relational database is enough for many systems. SQLite is fine for local prototypes. Postgres is a good default once the system becomes serious. You can add vector search later for retrieval, but I would not make vector storage the whole memory system.\n\nI usually think of storage as several categories:\n\n-\nEvent log.\n\n-\nCurrent task state.\n\n-\nDurable project state.\n\n-\nUser or operator preferences.\n\n-\nArtifacts and files.\n\n-\nSearchable summaries.\n\n-\nEmbeddings for retrieval when useful.\n\nSerialization can be simple JSON at first, but the important thing is to use typed records. Each record should say what it is, where it came from, when it was written, what confidence it has, and whether it is still active.\n\nFor question 3, the agent should not retrieve everything. It should retrieve based on the current objective.\n\nUseful criteria include:\n\n-\nIs this needed for the current task?\n\n-\nWas it created by this project, user, or run?\n\n-\nIs it recent enough to matter?\n\n-\nIs it still marked active?\n\n-\nIs it verified or only a guess?\n\n-\nDoes it conflict with newer information?\n\n-\nIs it instruction, preference, state, history, or evidence?\n\nThe pattern that worked best for me is:\n\nPersist broadly, retrieve narrowly.\n\nStore enough that the system can recover, audit, and continue later. But before each model call, build a small active context from only the pieces needed for the next step.\n\nThat is where long running agents become much more manageable. You stop treating the prompt as the memory container, and start treating the prompt as a temporary working view over external state.", "url": "https://wpnews.pro/news/how-do-you-design-memory-systems-for-long-running-ai-agents", "canonical_source": "https://discuss.huggingface.co/t/how-do-you-design-memory-systems-for-long-running-ai-agents/175584#post_15", "published_at": "2026-08-24 22:26:09+00:00", "updated_at": "2026-08-24 22:44:27.083338+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-infrastructure"], "entities": ["Michael", "SQLite", "Postgres"], "alternates": {"html": "https://wpnews.pro/news/how-do-you-design-memory-systems-for-long-running-ai-agents", "markdown": "https://wpnews.pro/news/how-do-you-design-memory-systems-for-long-running-ai-agents.md", "text": "https://wpnews.pro/news/how-do-you-design-memory-systems-for-long-running-ai-agents.txt", "jsonld": "https://wpnews.pro/news/how-do-you-design-memory-systems-for-long-running-ai-agents.jsonld"}}