Bulletproof Memory 🦞

By Hal Labs — Part of the Hal Stack

Your agent forgets things. Mid-conversation, after compaction, between sessions — context vanishes. This skill fixes that permanently.

The Problem

Agents lose context in three ways:

Compaction — old messages get summarized/dropped

Session restart — agent wakes up fresh

Distraction — mid-conversation, agent forgets earlier details

Traditional fix: "Remember to save important things."

But agents forget to remember.

The Solution: Write-Ahead Log (WAL) Protocol

The key insight: trigger writes on USER INPUT, not agent memory.

When the user provides a concrete detail, the agent writes it down BEFORE responding. The agent doesn't have to "remember" to save — the rule fires automatically based on what the user says.

Old Approach

WAL Approach

"Remember to save important things"	"If user gives detail → write before responding"
Triggered by agent memory (unreliable)	Triggered by user INPUT (reliable)
Agent forgets to remember	Rule fires automatically
Saves after the fact (too late)	Saves before responding (never too late)

Quick Setup

1. Create SESSION-STATE.md

This is your agent's "hot RAM" — the active working memory that persists across compactions.

Create SESSION-STATE.md in your workspace root:

# SESSION-STATE.md — Active Working Memory

This file is the agent's "RAM" — the hot transaction log for the current active task.
Chat history is a BUFFER. This file is STORAGE.

---

## Current Task
[What we're actively working on right now]

## Immediate Context
[Key details, decisions, corrections from this session]

## Key Files
[Paths to relevant files for this task]

## Last Updated
[Timestamp]

2. Add WAL Protocol to AGENTS.md

Add this to your agent's instructions:

### WRITE-AHEAD LOG (WAL) PROTOCOL

**The Law:** You are a stateful operator. Chat history is a BUFFER, not storage.
`SESSION-STATE.md` is your "RAM" — the ONLY place specific details are safe.

**Trigger:** If the user provides a concrete detail (name, location, correction, decision):
1. You MUST update `SESSION-STATE.md` IMMEDIATELY
2. You MUST write to the file BEFORE you generate your response
3. Only THEN respond to the user

**Example:** User says "It's Doboce Park, not Duboce Triangle"
- WRONG: Acknowledge, keep chatting, maybe write later
- RIGHT: Update SESSION-STATE.md first, then respond

**Why this works:** The trigger is the user's INPUT, not your memory. You don't have 
to remember to check — the rule fires on what the user says.

3. Add Recovery Protocol

When context is lost, don't ask "what were we doing?" — recover it yourself:

### Compaction Recovery Protocol

**Auto-trigger when:**
- Session starts with `<summary>` tag
- Message contains "truncated", "context limits", "Summary unavailable"
- User says "where were we?", "continue", "what were we doing?"
- You should know something but don't

**Recovery steps:**
1. **FIRST:** Read `SESSION-STATE.md` — this has the active task state
2. Read today's + yesterday's daily notes
3. If still missing context, use `memory_search`
4. Present: "Recovered from SESSION-STATE.md. Last task was X. Continue?"

**Do NOT ask "what were we discussing?" if SESSION-STATE.md has the answer.**

4. Add Session Startup Sequence

## Every Session
Before doing anything else:
1. Read `SESSION-STATE.md` — your active working memory (FIRST PRIORITY)
2. Read your identity files (SOUL.md, USER.md, etc.)
3. Read `memory/YYYY-MM-DD.md` (today + yesterday) for recent context

Don't ask permission. Just do it.

5. Add Memory Flush Protocol

Monitor context and flush before you lose it:

### Memory Flush Protocol

Monitor your context usage with `session_status`. Flush important context before compaction:

| Context % | Action |
|-----------|--------|
| < 50% | Normal operation |
| 50-70% | Write key points after substantial exchanges |
| 70-85% | Active flushing — write everything important NOW |
| > 85% | Emergency flush — full summary before next response |

**At >60%:** Update SESSION-STATE.md before every reply
**At >80%:** Write comprehensive handoff to daily notes

**What to flush:**
- Decisions made (what was decided and why)
- Action items (who's doing what)
- Open threads (anything unfinished)
- Corrections (things the user clarified)

Why This Works

The Trigger Insight

Most memory advice fails because it relies on the agent remembering to do something. But forgetting is the problem we're trying to solve!

The WAL protocol succeeds because:

• Trigger = user input (external, reliable)


• Not trigger = agent memory (internal, unreliable)

When the user says something concrete, the protocol fires. The agent doesn't need to remember anything — the rule activates based on what comes in.

The SESSION-STATE.md Insight

Daily notes are great for logging what happened. But they're not structured for "what am I doing RIGHT NOW?"

SESSION-STATE.md is:

• Hot — the current active task, not history


• Structured — current task, context, key files


• First priority — read before anything else on startup

It's the difference between a journal and a sticky note on your monitor.

Pre-Compaction Checklist

Before a long session ends or context gets critical:

• ○Current task documented in SESSION-STATE.md?
• ○Key decisions captured?
• ○Action items noted?
• ○User corrections saved?
• ○Could future-me continue from SESSION-STATE.md alone?

Self-Summarization Prompt

When context hits 85%+, ask yourself:

"If my context resets right now, what does future-me absolutely need to know to continue this task? Write it for someone with zero context."

This produces better summaries than mechanical extraction.

The Complete Memory Stack

For comprehensive agent memory, combine this with:

Skill

Purpose

Bulletproof Memory (this)	Never lose active context
PARA Second Brain	Organize long-term knowledge
Proactive Agent	Act without being asked

Together, they create an agent that remembers everything, finds anything, and anticipates needs.

Example SESSION-STATE.md

Here's a real example of what this looks like in practice:

# SESSION-STATE.md — Active Working Memory

## Current Task
Building dashboard for Jordan — Life OS view with goal tracking

## Immediate Context
- Dashboard deployed to: 
- Added tabs: Operations + Life OS
- Jordan at Moontricks concert @ The Independent tonight
- Correction: It's "Shovelman" (one word), not "Shovel Man"

## Key Files
- Dashboard HTML: /Users/Hal/clawd/dashboard/index.html
- Life OS data: /Users/Hal/clawd/dashboard/life-os.json
- Social events log: notes/areas/social-events.md

## Last Updated
2026-01-29 11:00 PM PST

Principles

Write before responding — The WAL protocol is non-negotiable

Trigger on input — User input fires the rule, not agent memory

SESSION-STATE.md is first — Always read it first on startup

Flush early, flush often — Don't wait for 85% context

Structure for retrieval — Future-you needs to continue, not just read

---

Part of the Hal Stack 🦞

Pairs well with [PARA Second Brain]() for knowledge organization and [Proactive Agent]() for behavioral patterns.