A transcript is not a recovery system

A transcript is not a recovery system

The credit request left your process. Then the call timed out.

You did not receive an ID. You did not receive an error from the billing system. The customer may already have the $40 credit, or the request may have died before the effect. Now the agent has a cheerful transcript saying it decided to issue the credit and a tool message saying the call returned nothing.

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 controller knew at a point in time: credit proposed, policy authorized, request started, response absent. An artifact preserves something inspectable, such as the exact request body or a returned receipt. A pending-effect record names the operation, target account, deduplication key if the provider supports one, start time, and the observation still required. If completion remains unknown, the next legal step is reconciliation—query the billing ledger, search by the operation identity, or escalate—not blind replay.

Patchwork, the book's fictional pedagogical software-change agent, has the same problem in a less financial costume. Imagine 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?