Skip to main content

What this snippet demonstrates

Agent runs can be interrupted by timeouts, cancellations, infrastructure failures, or intentional pauses (such as waiting for human approval). When a run is interrupted, the runner persists a checkpoint containing the run’s state at the point of interruption. The resume() method picks up from that checkpoint, restoring the conversation history, tool execution records, and step counter so the agent continues where it left off rather than starting from scratch. Over time, long-running threads accumulate checkpoint records, event logs, and state entries. The compact_thread() method prunes old records according to retention policies, keeping storage bounded without losing the data needed for active runs.

Resuming an interrupted run

How resume works internally

The runner follows this sequence when resume() is called:
  1. Checkpoint lookup — The runner queries the memory store for the latest checkpoint matching the given run_id and thread_id. If no checkpoint exists, it raises AgentCheckpointCorruptionError.
  2. Terminal check — If the checkpoint already contains a terminal result (the run completed before the resume was requested), the runner returns that result immediately without re-executing.
  3. Snapshot restoration — The runner loads the runtime snapshot from the checkpoint, which includes the conversation message history, step counter, tool execution records, and any pending subagent state.
  4. Continued execution — The runner calls run_handle() internally with the restored snapshot, continuing the step loop from where it was interrupted.

Resume method signature

Compacting thread memory

How compaction works

Compaction operates on two dimensions of stored data:
  • Event retention — Controlled by RetentionPolicy. Removes event records older than max_age_ms. Events are the raw telemetry log entries (LLM calls, tool executions, state transitions) that accumulate over the lifetime of a thread.
  • State retention — Controlled by StateRetentionPolicy. Removes state entries that exceed max_entries, keeping only the most recent ones. State entries include checkpoint snapshots, conversation summaries, and key-value metadata.
Both policies are optional. If you omit a policy, that dimension is not compacted. The method returns a MemoryCompactionResult with counts of removed records so you can log or alert on compaction activity.

When to compact

  • After long conversations — Threads with hundreds of turns accumulate large checkpoint histories. Compact after the conversation ends or reaches a natural break point.
  • On a schedule — Run compaction as a background task (e.g., hourly or daily) for threads that are still active but have grown large.
  • Before resume — If you know a thread has extensive history, compacting before resume reduces the data the runner needs to load.

Error handling

  • Memory — Full memory architecture, checkpoint schema, and retention policies.
  • Core Runner — Step loop lifecycle, state machine, and all runner API methods.
  • Checkpoint Schema — Exact structure of checkpoint records stored in memory.