{"skill":{"slug":"agent-memory-os","displayName":"Agent Memory OS","summary":"Provides a structured memory system for AI agents with global and project memory, promotion rules, validation, and maintenance to prevent forgetting and conf...","description":"---\nname: agent-memory-os\ndescription: Stop agents from \"forgetting, mixing projects, and rotting over time\" by giving them a practical memory operating system: global memory, project memory, promotion rules, validation cases, and a maintenance loop.\n---\n\n# Agent Memory OS\n\n**Build an agent that gets more organized over time instead of more chaotic.**\n\nTurn an agent's memory from **\"a pile of chat history\"** into a **long-term working memory operating system**.\n\n## What problem this solves\n\nA lot of agents look impressive in short conversations, then collapse under real work:\n- they forget what matters\n- active projects pollute long-term memory\n- useful lessons never become reusable rules\n- the system looks good for a week, then decays\n\nThis skill exists to fix that.\n\nIt helps the agent move from:\n- \"I remember fragments\"\n\nto:\n- **\"I have a stable global brain, project-specific working brains, reusable lessons, validation logic, and a maintenance loop that keeps the whole system healthy.\"**\n\n## What makes this different\n\nThis is not just:\n- note-taking guidance\n- a vector-search recipe\n- a memory dump strategy\n\nIt is a workflow for building an agent memory **system** with:\n- separation of concerns\n- promotion paths for reusable knowledge\n- validation cases\n- operational maintenance rules\n\n## Use this skill when\n\nThe user says or implies things like:\n- \"My agent keeps forgetting\"\n- \"Once projects pile up, everything gets messy\"\n- \"I want long-term memory for my AI agent\"\n- \"I need project memory separated from global memory\"\n- \"I want reusable lessons, not just logs\"\n- \"I want to share or standardize an agent memory setup\"\n\n## Example trigger prompts\n\nThis skill should feel natural on prompts like:\n- \"Help me design long-term memory for my coding agent.\"\n- \"My AI assistant keeps mixing projects and forgetting context.\"\n- \"I need a reusable memory architecture for multi-project agents.\"\n- \"How do I separate durable agent memory from active project memory?\"\n- \"Help me turn chat history into a reusable working-memory system.\"\n\n## What the user gets\n\nBy the end of this workflow, the user should have:\n1. a memory architecture that separates global and project concerns\n2. a minimum project-memory structure\n3. routing and promotion rules\n4. validation cases to prove the system works\n5. a maintenance runbook so it does not decay immediately\n\n## Privacy and publishing rule\n\nWhen using this skill for sharable/public output:\n- never expose real user names, private IDs, workspace-specific secrets, session paths, internal message IDs, or private document URLs\n- rewrite examples into generalized patterns\n- replace personal/project-specific references with neutral placeholders\n- do not bundle private memories, raw chat excerpts, or personally identifying workflow traces into the skill\n\nIf the user explicitly wants a public/shareable version, treat **privacy-preserving abstraction** as mandatory, not optional.\n\n## Recommended workflow\n\n### Step 0 — Decide whether to use a full memory system\nNot every agent needs this full setup.\n\nRead `references/architecture-decision-guide.md` when the user is unsure whether they need a full global / project / bridge system, or whether a simpler setup is enough.\n\n### Step 1 — Diagnose the real memory problem\nClassify the user's issue before proposing architecture.\n\nTypical failure modes:\n- **single-brain overload**: everything is dumped into one place\n- **project pollution**: local project state contaminates long-term memory\n- **retrieval confusion**: the agent doesn't know where to look first\n- **knowledge stagnation**: lessons never graduate into reusable rules\n- **maintenance decay**: the structure exists but slowly becomes stale\n\nRead `references/failure-modes.md` when you need a sharper diagnosis rubric.\n\n### Step 2 — Choose the architecture\nDefault recommendation: a **three-part system**\n- **global memory** for durable rules, preferences, SOPs, stable principles\n- **project memory** for local complexity and active work\n- **bridge/promotions** for candidate → promoted → canonical evolution\n\nRead `references/architecture.md` when you need the design rationale.\n\n### Step 3 — Create the minimum working structure\nFor each project, start with 5 files:\n- `PROJECT.md`\n- `STATUS.md`\n- `DECISIONS.md`\n- `ASSETS.md`\n- `LESSONS.md`\n\nUse the bundled templates in:\n- `assets/project-templates/`\n- `assets/bridge-templates/`\n\n### Step 4 — Define routing and promotion rules\nMake sure the agent knows:\n- what belongs to global memory\n- what stays project-local\n- what becomes a candidate for reuse\n- what evidence is required before promotion\n\nRead:\n- `references/routing.md`\n- `references/promotion.md`\n\n### Step 5 — Validate with concrete cases\nDo not stop at design. Test the system with at least 3 case types:\n- **continuous project execution**\n- **interruption and recovery**\n- **cross-project reuse**\n\nUse measurable criteria: recovery accuracy, unnecessary follow-up questions, reuse success, structure completeness, etc.\n\nRead `references/validation.md` for a compact validation model.\n\n### Step 6 — Add a maintenance runbook\nA memory system is not done when designed. It is done when it can be maintained.\n\nDefine:\n- when to update daily logs\n- when to update project status\n- when to record lessons\n- when candidates get promoted\n- when to deprecate outdated rules\n- how often to review global/project/bridge memory\n\nRead `references/maintenance.md` when writing or reviewing the runbook.\n\n## Minimal success path\n\nA good first run of this skill usually looks like:\n1. identify the dominant failure mode\n2. choose the global/project/bridge architecture\n3. create the 5 core project files\n4. define one promotion rule and one routing rule\n5. validate with one interruption-recovery case and one reuse case\n6. write a simple maintenance rhythm\n\nIf the agent can recover better, reuse more, and stay cleaner over time, the system is working.\n\n## Packaging guidance\n\nKeep the public skill:\n- short in SKILL.md\n- practical in workflow\n- generalized in examples\n- private details removed\n\nDo **not** include:\n- personal identifiers\n- real workspace paths tied to an individual\n- raw private conversation excerpts\n- internal-only document links\n- unredacted project-specific evidence\n\nRead `references/publish-checklist.md` before publishing or sharing widely.\n\n## Output style for public-facing use\n\nIf the user wants something that attracts attention, write with this shape:\n- start from a painful, recognizable problem\n- name the failure mode clearly\n- present the architecture as a relief pattern\n- show a small, concrete workflow\n- prove it with validation cases\n- end with operational simplicity, not abstract theory\n\nMake it feel like a **usable system**, not an academic essay.\n","tags":{"latest":"0.1.0"},"stats":{"comments":0,"downloads":452,"installsAllTime":0,"installsCurrent":0,"stars":1,"versions":1},"createdAt":1774458981255,"updatedAt":1778492190282},"latestVersion":{"version":"0.1.0","createdAt":1774458981255,"changelog":"Initial public release: build an agent memory operating system with global memory, project memory, promotion rules, validation cases, and a maintenance loop.","license":"MIT-0"},"metadata":null,"owner":{"handle":"aslan-ai-labs","userId":"s177qhrryy3e0y7ez8ycx4nwkn83kasa","displayName":"Aslan117","image":"https://avatars.githubusercontent.com/u/267115916?v=4"},"moderation":null}