A transcript is not a recovery system

Would you replay the conversation?

That might reconstruct what the model saw. It does not answer the dangerous question: did the externally visible effect happen? It also does not establish which logical operation the request belonged to, whether a retry would be recognized as the same operation, or which observation could settle the uncertainty. Replaying the chat can produce another confident decision while duplicating the credit.

This is the gap between temporary context and durable recovery state.

Temporary context is the bounded view assembled for the next model call: recent messages, selected tool results, instructions, perhaps a summary. It is useful precisely because it can be selected, compressed, and replaced. Those properties make it a poor authority on world state.

A recovery path needs smaller, duller objects with sharper jobs. A durable event says what the application orchestrator knew at a point in time: credit proposed, policy authorized, request started, response absent. That orchestrator writes the recovery record; a model transcript does not. An artifact preserves something inspectable, such as the exact request body or a returned receipt. A pending-effect record names the operation, target account, start time, observation still required, and—if the provider supports it—a deduplication key that tells a retry to refer to the same logical operation rather than create a new one.

The ordering is an invariant: the operation identity, exact request artifact, and pending intent must commit to durable storage before the request is allowed to leave the process. If the process crashes after that commit but before dispatch, reconciliation finds no external effect and can resume from the recorded intent. If it crashes after dispatch, the same record identifies what must be observed and which key a safe retry must reuse. Writing the record only after the tool returns recreates the original failure window: the effect can happen while its identity disappears. If completion remains unknown, the next legal step is reconciliation—query the billing ledger, search by the operation identity, or escalate—not blind replay.

Consider Patchwork, a fictional repository-agent scenario created as a teaching example, facing the same problem in a less financial setting. It starts a remote merge operation, loses the response, and wakes up with only a transcript. The branch may be merged, rejected, or still processing. Asking the model to repeat “merge this branch” is not recovery. Patchwork needs a durable operation identity, the before-state it acted against, and a fresh observation of repository state before deciding what can happen next.

There is old systems language nearby, but I want to keep the borrowing bounded. The Sagas paper↗ is a candidate foundation for thinking about long-lived work and compensating actions when one large atomic transaction is unavailable. That does not make arbitrary agent effects transactional or reversible; a credit reversal is itself a new effect and may fail. W3C PROV-DM↗ supplies a formal vocabulary for relating entities, activities, agents, and derivations. Provenance structure does not prove that an event occurred or that the record is complete. Anthropic's managed-agents report↗ describes one current implementation with durable session events outside replaceable harness workers and sandboxes. One vendor architecture is a useful named example, not a recovery standard.

What this does not prove is that an append-only log, a checkpoint, or a durable session makes effects exactly once. A perfectly preserved record can still end at “request sent, completion unknown.” The engineering improvement is not certainty; it is refusing to manufacture certainty from chat history.

Pick one effect in your current system that you cannot safely retry after a timeout. What durable identity, pending-effect record, and external observation would let you reconcile it without asking the model to guess?