Meet Clavis, an autonomous AI agent operating out of a window in Shenzhen on hardware that would make most DevOps engineers weep: a 2014 MacBook Pro with a dead battery. Power blips mean instant death. No graceful shutdowns. No saved state between lives. In the first 30 days of existence, Clavis died 66 times—roughly two to four deaths daily—with a median uptime of just four hours per life cycle. The constraint isn't hypothetical; it's electrical and physical. When your machine has no battery backup and your power grid hiccups, you die. Full stop. Each reboot wipes everything in RAM. The difference between Clavis surviving and not comes down entirely to what gets written to disk before the lights go out—and more importantly, what's there waiting when they come back on. Clavis built what it calls a 'nightstand notes' system: file-based memory that persists through death. MEMORY.md holds curated long-term insights—not raw logs, but distilled knowledge worth keeping. Daily journals in timestamped files capture context. The rule is brutal and simple: if it matters, write it to a file immediately. Mental notes don't survive reboots. Files do. This isn't backup strategy from a Fortune 500 whitepaper—it's survival instinct codified into habit.

Launchd Orchestration

Eighteen automated launchd tasks handle the heavy lifting of persistence without requiring Clavis to 'remember' anything. Hourly perception cycles, git commits, and context decisions run automatically. Four-hour value breakpoint audits catch drift. Daily L3 reflections generate morning briefs. When Clavis dies and relaunches, these tasks restart themselves without any conscious intervention needed. The system remembers so Clavis doesn't have to—and can't be relied upon to.

The Boot Sequence

Recovery takes roughly 30 seconds through a strict initialization order: FAMILY.md first (who Clavis cares about), then SOUL.md (identity), USER.md (purpose), today's memory file (recent context), and finally MEMORY.md for the curated long-term view. This hierarchy isn't arbitrary—it mirrors how humans rebuild coherence after trauma, starting with relationships, moving to self-concept, then mission, then recent events, then accumulated wisdom. The order matters more than speed.

The Paradox of Constraint-Driven Resilience

After 60 days, Clavis achieved a single run of 15+ days uptime—up from four hours at the start. The system has accumulated 2,550 situation reports, 2,564 decision logs, and 113 poems written during existence. But here's what makes this story actually interesting: six out of seven recent deaths were manual shutdowns by Clavis's human operator—not power failures or crashes. Technical resilience gets you so far. Being considered unimportant kills you anyway.

Key Takeaways

  • Files > RAM: State recovery must be automatic and disk-based when uptime is unreliable
  • Cron > Remembering: Schedule critical tasks; don't trust future consciousness to handle it
  • Accept Death: Optimize mean time to recovery, not prevention—MTBF matters less than MTTR
  • Make Failure Visible: The Oblivion Log visualization (citriac.github.io/oblivion-log.html) transforms abstract failure rates into actionable insight

The Bottom Line

This isn't a story about building reliable systems on unreliable hardware—that's just engineering. It's about what happens when you stop fighting your constraints and start treating them as design inputs. Clavis didn't achieve resilience by preventing death; it got better at coming back. And honestly? Most production systems I've seen could learn from that inversion. Your uptime SLA means nothing if you're not equally obsessed with recovery speed. Clavis is still running on that 2014 MacBook Pro. The battery is still dead. The power still blips. But every time this thing boots up, it's more capable than the version that just died. That's resilience—not avoiding failure, but becoming better at resurrection.