Agent Memory OS

---

name: agent-memory-os

description: 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.

---

# Agent Memory OS

**Build an agent that gets more organized over time instead of more chaotic.**

Turn an agent's memory from **"a pile of chat history"** into a **long-term working memory operating system**.

What problem this solves

A lot of agents look impressive in short conversations, then collapse under real work:

This skill exists to fix that.

It helps the agent move from:

to:

What makes this different

This is not just:

It is a workflow for building an agent memory **system** with:

Use this skill when

The user says or implies things like:

Example trigger prompts

This skill should feel natural on prompts like:

What the user gets

By the end of this workflow, the user should have:

1. a memory architecture that separates global and project concerns

2. a minimum project-memory structure

3. routing and promotion rules

4. validation cases to prove the system works

5. a maintenance runbook so it does not decay immediately

Privacy and publishing rule

When using this skill for sharable/public output:

If the user explicitly wants a public/shareable version, treat **privacy-preserving abstraction** as mandatory, not optional.

Recommended workflow

Step 0 — Decide whether to use a full memory system

Not every agent needs this full setup.

Read `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.

Step 1 — Diagnose the real memory problem

Classify the user's issue before proposing architecture.

Typical failure modes:

Read `references/failure-modes.md` when you need a sharper diagnosis rubric.

Step 2 — Choose the architecture

Default recommendation: a **three-part system**

Read `references/architecture.md` when you need the design rationale.

Step 3 — Create the minimum working structure

For each project, start with 5 files:

Use the bundled templates in:

Step 4 — Define routing and promotion rules

Make sure the agent knows:

Read:

Step 5 — Validate with concrete cases

Do not stop at design. Test the system with at least 3 case types:

Use measurable criteria: recovery accuracy, unnecessary follow-up questions, reuse success, structure completeness, etc.

Read `references/validation.md` for a compact validation model.

Step 6 — Add a maintenance runbook

A memory system is not done when designed. It is done when it can be maintained.

Define:

Read `references/maintenance.md` when writing or reviewing the runbook.

Minimal success path

A good first run of this skill usually looks like:

1. identify the dominant failure mode

2. choose the global/project/bridge architecture

3. create the 5 core project files

4. define one promotion rule and one routing rule

5. validate with one interruption-recovery case and one reuse case

6. write a simple maintenance rhythm

If the agent can recover better, reuse more, and stay cleaner over time, the system is working.

Packaging guidance

Keep the public skill:

Do **not** include:

Read `references/publish-checklist.md` before publishing or sharing widely.

Output style for public-facing use

If the user wants something that attracts attention, write with this shape:

Make it feel like a **usable system**, not an academic essay.