Coding agents that survive crashes use session state, not bigger context windows

I've been running coding agents that survive crashes, network drops, and even full system reboots. The secret isn't better prompts or bigger context windows — it's treating your agent sessions like distributed systems.

Most coding agents die when anything goes wrong. Your laptop sleeps, WiFi drops, or you accidentally close the terminal. The agent loses everything: current task, file locations, half-written code, debugging context. You're back to square one.

But there's a different pattern. Instead of one fragile conversation, you build persistent sessions that survive interruptions. The agent picks up exactly where it left off, even days later.

The Mori Pattern: Session State That Survives Everything

Here's what actually works. Every coding session gets three files that persist across crashes:

# session_state.md
## Current Task
- Implementing user auth middleware
- Files touched: auth.py, middleware.py, tests/test_auth.py
- Last working state: tests passing, need to add rate limiting

## Context
- Using FastAPI + JWT tokens
- Rate limit: 100 requests/minute per IP
- Redis available at localhost:6379

## Next Steps
1. Add rate limiting decorator
2. Test with curl
3. Update documentation

Your agent reads this file first, every time. No "what were we working on?" No re-reading the entire codebase. Instant context recovery.

The second file tracks the environment:

# environment.md
## Setup
- Project: /home/user/api-server
- Virtual env: .venv (activated)
- Database: PostgreSQL running on 5432
- Redis: localhost:6379
- Test command: `pytest tests/`

## Running Services
- API server: http://localhost:8000 (pid 1234)
- Background worker: running (pid 1235)

The third file is the work log — not for you, for the agent:

# work_log.md
## 2024-01-15 14:30
- Started auth middleware implementation
- Created auth.py with JWT validation
- Tests passing: test_valid_token, test_expired_token

## 2024-01-15 14:45
- Added middleware.py
- Integrated with FastAPI app
- Issue: Rate limiting not implemented yet

## 2024-01-15 15:00
- SESSION INTERRUPTED - WiFi dropped

## 2024-01-15 15:15
- SESSION RESUMED
- Environment check: all services running
- Continuing with rate limiting implementation
How It Actually Works
When your agent starts (or restarts), it follows this sequence:
Read session_state.md — What am I working on?
Check environment.md — Is everything still running?
Scan work_log.md — What did I already try?
Verify current state — Run tests, check services
Continue or recover — Pick up the task or fix what broke
The magic happens in step 4. Instead of assuming everything is fine, the agent verifies. Tests still passing? Services still running? Files still there? If something broke while it was offline, it knows immediately.
Pro tip: Use tmux or screen to keep your development server running even when the agent disconnects. The agent can reconnect to existing sessions instead of starting from scratch.
Why This Beats Long Context
I've tested this against agents with 200K context windows. The persistent session pattern wins every time:
Faster startup — 30 seconds vs 5 minutes of context rebuilding
Lower costs — No massive context window on every request
Better decisions — Fresh verification beats stale assumptions
Fault tolerance — Survives crashes, reboots, network issues
The best part? Your agent becomes genuinely autonomous. It can work overnight, survive your laptop sleeping, and pick up tasks days later. No babysitting required.
Most builders are still treating agents like chatbots — fragile conversations that die when anything goes wrong. But the builders getting real work done are treating them like distributed systems: resilient, stateful, and designed to survive the real world.