🔄 Topic

Designing resumable agent sessions that preserve critical facts across a restart without treating corrupted state as trustworthy.

🎯 Goal

Make shared agent sessions recoverable and bounded, while preserving existing stateless behavior as the default.

🛠 What I Did

I added a default-off shared runtime for local-agent sessions. The design uses append-only JSONL events, atomic snapshots, and explicit compaction to retain the important facts of a task without carrying an unlimited transcript forward.

The most useful lesson came from failure handling. A process can be interrupted while writing the last event, leaving a malformed trailing record. That is different from corruption in the middle of the journal:

  • a malformed trailing record can be treated as an interrupted final write and recovered cautiously
  • interior corruption makes the history ambiguous and must fail closed

The runtime stayed opt-in behind LOCAL_AGENT_SHARED_RUNTIME=1. A real two-process acceptance run created a session in one process, resumed it in another process with the same session ID, compacted the state, and verified that critical facts survived.

The implementation was also verified with shared-runtime tests, the broader AI-OS suite, legacy local-agent tests, and a review pass before it was documented as ready for later gated rollout.

🔗 Key Cybersecurity Connections

This is fundamentally a logging and recovery problem. Security investigations rely on logs, but only when their trust boundaries are understood.

An append-only journal is useful because it makes event history explicit. Atomic snapshots are useful because they reduce the chance that a reader sees half-written state. The real control is the recovery rule: do not silently invent a clean story from data that cannot be trusted.

The same reasoning appears in incident response, endpoint telemetry, and audit trails:

  • distinguish a known interrupted write from unexplained record corruption
  • preserve enough evidence to reconstruct state after a restart
  • reduce the amount of sensitive or irrelevant context retained
  • prove recovery across a real process boundary, not just in a unit test

🔍 Investigation Questions

  • Is the journal append-only, and can each event be tied to a sequence?
  • What exact corruption pattern is recoverable?
  • Which critical facts must survive compaction?
  • Can a second process read the same state safely?
  • Is the shared runtime enabled deliberately or accidentally?

🚨 Detection Opportunities

  • malformed journal records away from the final line
  • repeated recovery of torn trailing records
  • compaction that drops a required task constraint
  • sessions that grow past the configured context budget
  • a shared-session process running while its flag is disabled

🧭 MITRE ATT&CK Techniques

No direct MITRE ATT&CK mapping claimed. The focus here is durable state, recovery boundaries, and evidence preservation.

🗺 Visual Investigation Diagram

Process writes session event
    ↓
Append-only journal and atomic snapshot
    ↓
Restart or compaction
    ↓
Recover a torn final write, or fail closed on ambiguous corruption
    ↓
Resume only with trustworthy state

⚠ Challenges

The difficult design choice was refusing broad recovery. It is tempting to smooth over every malformed record so the system keeps moving, but doing that can turn uncertain state into a confident-looking history.

📚 What I Learned

Resilience does not mean accepting every damaged input. A safe recovery path is narrow and specific: recover the failure mode that is understood, record it, and refuse the situations that make the state unreliable.

➡ Next Steps

  • Add more fixture cases for interrupted writes and compaction timing
  • Monitor recovery events as a signal, not a routine success state
  • Review the retained critical facts after longer tasks
  • Keep shared sessions disabled unless a task genuinely benefits from them

🧠 Reflection

The most reassuring recovery behavior is not the one that always continues. It is the one that clearly distinguishes a known interruption from an unknown change and stops when the evidence is no longer trustworthy.

🧩 Lessons Learned

What worked

Testing a real handoff between two processes instead of only exercising in-memory state.

What broke

The first parser could let labelled critical facts absorb trailing instructions.

Why it broke

The parsing boundary was too loose for the structure of the session data.

Fix / takeaway

Bound critical labels precisely and recover only the narrow torn-tail case that is understood.

📈 Skill Progression Context

The work strengthened my ability to reason about logs, durable state, failure modes, and evidence preservation. Those habits transfer directly to security operations, where a fast but unjustified recovery can be more dangerous than an honest stop.

😄 TL;DR

Built resumable sessions that recover an interrupted final write, but refuse to invent certainty from deeper corruption.