Unified Agent Memory and Knowledge Management System

Problem to Solve

Agent memory often stops at storing chat history in a vector store, but real agent workloads need to separate current state, durable preferences, past events, procedural rules, and external references. Mixing these lifecycles in one store can cause temporary instructions to become user profiles, outdated facts to contaminate current queries, and cross-session evidence to remain fragmented. This approach treats agent memory as a governed data system: the core question is not what to keep, but what to write, where to store it, when to retrieve it, how to update it, and when to retire it.

How It Works

The skill organizes memory around four responsibilities: R representation and storage, S extraction, Q retrieval and routing, and U maintenance. It also separates working, semantic, episodic, procedural, retrieval, parametric, and prospective memory. A typical flow includes:
- Write gating: decide whether a statement is durable, so temporary instructions do not become stable preferences
- Read gating: filter candidates by scope, validity time, keywords, semantic similarity, and rerank
- Query Planner: choose a path for current-state, history, factual recall, trace, or multi-hop queries
- Maintenance: control cost with versioned facts, supersede, archiving, and local merging

Scope and Caveats

This is useful for long-running agents, shared memory across agents, user preference management, tool debugging, and procedural rule capture. It is not a long-context replacement, and it does not require a knowledge graph or weight training from day one. A lighter build can start with working memory, reliable retrieval, and a clean preference table, then add episodic traces and evaluated procedural rules.