Back to home

Keeping Them Alive Was the Easy Part

· 7 min read
aiagentsself-improvementopen-sourceclaude-code

Two weeks ago I shipped session-warden and wrote that agents are easy to start and hard to keep, and the keeping is the moat. I stand by every word. Then I audited my own fleet and found the part that undermines it: five of my eight core agents had completely empty long-term memory files.

Sit with that for a second. The lifeguard was doing its job perfectly. Sessions rotated before they died, transcripts got summarized into memory, agents resumed mid-task like nothing happened. Uptime was excellent. And the agents were exactly as smart as the day I deployed them, because nothing in any of that plumbing ever taught them anything.

Keeping an agent alive, it turns out, is the easy part. session-warden v1.0.0 is about the hard part: making the fleet sharper tomorrow than it was today. The watchdog grew a teaching loop. This is the launch note.

A watchdog restores your agent to the same level of dumb

Quick recap of what the lifeguard already did, because the new layer sits on top of it. Every 30 seconds, session-warden looks for Claude Code sessions that are bloated or dead: token bloat, context overflow, a compaction loop, a zombie CLI holding a stale session. It rotates them, has Haiku compress the full transcript (every tool call, every file edited, every command run) into the agent's native memory, and restarts, so the agent crosses the session boundary without noticing. Around that sit a live context sync every five minutes, a stall reaper for silent hangs, and a nightly dream cycle that refreshes embeddings and writes a daily digest.

If you run persistent agents on OpenClaw, you already know the failure modes this buys you out of: the session that dies at 3am and resumes into an infinite error loop, the channel that goes quiet and looks like a rate limit, the agent that comes back with amnesia. The first essay covers that layer in full.

But notice the shape of everything in that list. It is homeostasis: detect a deviation, restore the previous state. A watchdog is a thermostat. A fleet that survives a year of flawless rotations ends the year knowing nothing it didn't know in January.

Memory everywhere, learning nowhere

My fleet had a 1,300-page knowledge graph, per-channel memory files, rotation summaries, a nightly consolidation job. Every piece of memory infrastructure you could want, and no closing loop: nothing ever distilled what happened into rules the agents would actually load on their next start. The writes all flowed sideways, into archives and graphs, and never back into the context an agent wakes up with. Hence five empty memory files. Hence me correcting the same agent for the same mistake, weeks apart, like a manager who never writes anything down.

(The same audit also surfaced a three-week-old silent failure that had wedged my two most important agents in permanent backoff. That bug is a story on its own.)

The Reflector: distill a lesson, then try to kill it

A watchdog only restores prior state like a thermostat. The teaching loop runs nightly: sessions feed a Reflector, a Skeptic tries to kill each lesson, survivors are staged for phone approval, then appended to the memory file.

The centerpiece of v1.0.0 is the Reflector, a nightly job that runs at 04:10. It gathers each agent's last 24 hours, sessions plus rotation summaries, and has Sonnet distill at most five candidate lessons per agent, as short append-only bullets. Then a separate, cheaper Haiku skeptic tries to reject each one: ungrounded in the transcript? Too specific to generalize? Contradicts an existing rule? Derived from untrusted content? Only the survivors get staged, and apply-lessons.sh appends approved bullets to the agent's memory file and mirrors them to the knowledge graph with full provenance.

Two design choices carry the weight here. Append-only comes straight from Stanford's ACE paper (Agentic Context Engineering): never let a model rewrite its own instructions wholesale, because iterative rewriting collapses the context and breeds brevity bias. Itemized bullets accumulate instead. And the skeptic is never the author. A model grading its own homework is generous by default; an independent verifier whose only job is rejection is the cheapest honesty in the whole pipeline.

The first run produced seven lessons across four agents, every one grounded in a real transcript. My favorite: dash, the ads-and-ops agent, learned "never lead outreach with internal campaign labels" from corrections I made mid-session. That correction used to evaporate the moment the session rotated. Now it's a permanent rule with a source attached.

Skills, scorecards, and memory evals ride the same rails

Once the distill-verify-stage-apply spine existed, three more loops slotted onto it:

  • A weekly skill harvester (Sundays) mines the fleet's transcripts for workflows performed two or more times that no existing skill covers, then drafts complete SKILL.md files: steps, known failure modes, anti-patterns, staged for review, capped at two per agent per week. Its first harvest mined a warm-prospect-reply skill out of real client outreach, with my corrections captured as the anti-patterns.
  • A weekly model scorecard (Saturdays) runs eight fixed tasks across my three experimental agents, each on a different model, and scores every answer with a blind judge that is never told which model produced it. Its first dry run caught an agent that was 100% broken. Measurement deserves its own essay; the short version is that it pays on day one.
  • Monthly memory evals test whether an agent applies its stored rules, not whether it can recite them, and report pass-rate deltas month over month. A regression signal for memory itself.

And yes, it's all bash. 86.7% shell by GitHub's count, held together by cron, jq, and flock, with 316 passing tests standing between it and chaos.

Staged autonomy, because a self-editing fleet is an attack surface

Nothing self-applies by default. Lessons and skills stage for human approval; I review mine by messaging my chief-of-staff agent on Telegram: "show me pending lessons", "apply all". Every persona, memory, and skill file is versioned in a local git repo, so every self-modification the system ever makes is an auditable diff. Knowledge-graph writes carry provenance: a scope, a source, a trust level. Content from inbound email or strangers on Discord can never enter as verified, which is the memory-poisoning firewall. Nothing unverified ever overwrites a verified fact.

When the loop earns trust, you flip WARDEN_REFLECT_AUTO_APPLY and the approval gate opens. Autonomy is staged, not assumed, and the git history plus the evals are the safety net waiting underneath.

Install it before your fleet teaches you the hard way

You need bash, jq, flock, the Claude CLI, and an OpenClaw gateway. GBrain and Telegram are optional; the warden degrades gracefully without them.

git clone https://github.com/Ani-HQ/session-warden.git ~/session-warden
cd ~/session-warden && bash install.sh

The installer checks dependencies, detects your OpenClaw path, writes the config, and installs the cron entries. From there it's timers all the way down: dream cycle at 03:37, Reflector at 04:10, scorecard Saturdays, harvester Sundays, evals monthly. MIT licensed, release notes here.

Last month I told you the keeping is the moat. I was half right. Keeping a fleet alive gets you yesterday's fleet back, every single day. Teaching it gets you a fleet that is a little sharper every morning than it was the night before, on the exact same models.

Surviving was the easy part. Compounding is the moat.

References: session-warden (v1.0.0 release, changelog); the original session-warden essay; Zhang et al., Agentic Context Engineering (Stanford, 2025).