Memory Architect

Split a monolithic MEMORY.md into three tiers plus a structured entity graph.

Architecture

CODEBLOCK0

Process

1. Analyze the existing MEMORY.md

Read the full file. Classify each section:

2. Create the tier files

Write each tier file with a header comment explaining its purpose and update frequency.

protocols.md rules:

• - Only procedures that rarely change
• Include the exact commands (copy-pasteable)
• No project-specific state

active.md rules:

• - Only things with a next action or pending status
• Include "Waiting On" section at bottom
• Prune completed items to archive on each update

archive.md rules:

• - Completed work grouped by date or category
• Reference data (contacts, accounts, chat IDs)
• Keep searchable — use headers and tables

3. Extract entities to ontology

For each named person, organization, project, property, or location, create a JSONL entry:

CODEBLOCK1

ID conventions:

• - People: INLINECODE0
• Organizations: grp_name or INLINECODE2
• Projects: INLINECODE3
• Properties/locations: prop_name or INLINECODE5

Relation types: member_of, owns, collaborates_on, interested_in, guides, uses, listed_by, INLINECODE13

4. Rewrite MEMORY.md as router

Replace MEMORY.md with a ~25-line index that:

• - Lists the three tiers with one-line descriptions
• Notes the ontology location
• Preserves any system directives (NO_REPLY rules, heartbeat instructions)
• Contains zero project-specific content

5. Verify

CODEBLOCK2

Targets: MEMORY.md under 30, protocols under 100, active under 80, graph = 1 line per entity/relation.

Maintenance

On each session

• - Read memory/protocols.md (always)
• Scan memory/active.md (always)
• INLINECODE16 — only on memory_search or explicit request

When adding new information

• - New procedure → protocols.md
• New project/active item → active.md
• Completed item → move active → archive
• New person/org/project → append to graph.jsonl

Entity queries