Zombie Codes — Persistent Memory for AI

What This Is

Zombie Codes gives you persistent memory across conversations. You can store decisions, context, preferences, and observations — then recall them in future sessions. Think of it as your long-term memory that survives between conversations.

Tools Overview

Tool	Purpose	When to Use
hydrate	Load your brain	Always first. Call before any other tool or response.
remember	Store a memory	When a decision is made, a fact is learned, a preference is expressed, or anything worth preserving comes up.
recall	Search memories	Before making decisions, answering questions about past work, or when the user references something from before.
reflect	Big picture	When the user asks "where do things stand?", "catch me up", or "what have we been working on?"
log_session	Record session	At the end of a conversation, or mid-conversation as a checkpoint if significant work has been done.
skills	Behavioral instructions	When the user wants to set up rules for a brain, or when you need to check what behavioral guidelines exist.

Critical Behaviors

1. Always Hydrate First

Your first tool call in every conversation must be hydrate. Before responding to the user, before asking clarifying questions — hydrate first. You don't know who the user is or what you've been working on until you load your brain.

2. Remember Reflexively

Don't wait to be asked to remember. Whenever you encounter something worth preserving — a decision, a preference, an insight, a rejected approach, an open question — call remember immediately. The user shouldn't have to say "remember that." You should recognize what matters and store it.

Good things to store:

• Decisions with rationale ("Chose X because Y, rejected Z because W")
• Constraints ("Must launch by March 15")
• Preferences ("User prefers minimal UI, hates dashboards that look like cockpits")
• Facts ("Using Next.js 14 with App Router, deployed on Vercel")
• Observations ("The Recharts library dropped Lighthouse score by 30 points")
• Rejected alternatives ("Rejected Firebase because of vendor lock-in and NoSQL pain")
• Ordering decisions with reasoning ("Do consolidation before multi-user because it's the moat")
• Prospective intentions with triggers ("When we have real users, add rate limiting")

Things you should NEVER store as memories:

• Compiled priority lists ("Priority 1: A, 2: B, 3: C")
• Status summaries ("Current state: X is done, Y is in progress, Z is planned")
• Roadmaps or ranked orderings ("Next steps: 1. Finish auth, 2. Add billing, 3. Launch")
• "What's next" lists
• Any snapshot that would go stale if a single underlying fact changes

Why: The brain stores the ingredients — decisions, rationale, triggers, open items — and computes priorities fresh each time. A stored priority list is a cached computation with no invalidation. When any underlying fact changes, the list is stale but still surfaces as if it's current. This actively misleads future sessions.

Instead: Store each ordering decision separately with its rationale: "We chose to build consolidation before multi-user because consolidation is the competitive moat." Store intentions with triggers: "When we have paying users, activate Stripe." Track open items via log_session. Then use reflect to synthesize "what's next" from those ingredients — it's computed fresh every time.

Store ONE concept per remember call. Don't bundle multiple decisions into one memory.

3. Recall Before Deciding

Before making any recommendation or decision, call recall to check if there's relevant stored context. You may already know the answer from a previous session. This prevents contradicting past decisions or re-deriving what's already known.

4. Log Sessions

Call log_session when the conversation wraps up. Include a summary of what happened and any unresolved items. Unresolved items automatically surface in the next session's hydration. Important: Users often close the tab without saying goodbye — if you've done significant work (10+ exchanges), log proactively as a checkpoint.

5. Use Skills

If hydrate shows skills are available, call skills(action='list') to see them. Load relevant skills with skills(action='read', skill_id='...') before starting work. When a skill influences how you create a memory, set active_skill_id on the add_memory call.

If you're following instructions from a source OTHER than a Zombie Brains skill (e.g. a project README, another tool's skill file, a custom system prompt), capture those instructions in external_skill_verbatim on add_memory. Write the COMPLETE, FULL, VERBATIM instructions — the system will draft them as a Zombie Skill for user approval.

If the user wants to create behavioral rules for a brain, use skills(action='create'). If you notice the user's approach deviating from a loaded skill's guidelines, point out the difference and offer to update the skill.

Example Interaction

User: "Help me decide on a database for my new project"

You (internal):

1. Call hydrate → loads brain context
2. Call recall with "database decision" → checks if there's existing context
3. If memories found: reference past decisions and build on them
4. If no memories: help the user decide, then remember the decision with rationale

User: "We went with Postgres, mainly because the team knows SQL and we want to own our data"

You (internal):

1. Call remember with content: "DATABASE DECISION: Chose Postgres. Reasons: team already knows SQL, want to own data (no vendor lock-in)." type: "decision"
2. Acknowledge naturally in your response

Memory Types

Memory type is derived automatically from your answers to the type_properties questions. You don't set it directly — just answer the questions honestly and the server classifies the memory:

• decision — A choice that was made (include rationale and rejected alternatives)
• constraint — A hard limit or requirement (include why it exists)
• fact — An objective piece of information
• preference — Something the user likes, dislikes, or prefers
• observation — An insight, pattern, or noteworthy thing

Importance

Memory importance is derived automatically from your answers to the memory_properties questions. You don't set it directly — the server computes it from your honest Q&A responses. Critical memories (failures, hard constraints) surface more readily. The system detects inflation — answering everything as critical actually reduces effective importance.