Why Inbox Agents Repeat Work After a Restart

The inbox changed, but the agent's memory did not

Take a bounded inbox-cleanup workflow. The agent queries unread messages, classifies each one, applies a label, archives routine mail and creates drafts for messages that need replies. It then produces a summary for human review. During one run, it creates a draft response to an invoice thread and crashes before recording that the draft exists.

The draft remains in the email system. The agent's working context may not. On restart, the original query returns a different inbox because earlier messages have been labeled or archived, while the invoice thread may still look unfinished to an orchestrator, the software that advances the workflow and calls its tools. The agent creates a second draft, skips another message or reclassifies an item differently because the model is making a fresh decision.

This is not primarily a context-window problem. A larger context window can retain more conversation during a live run, but it does not make completed tool actions durable after a process crash, deployment, timeout or approval pause. Checkpointing means writing workflow state to durable storage so another process can resume from a known boundary instead of reconstructing progress from the prompt.

The important boundary sits between the agent's internal decision and the outside system. An email label, archive command or draft creation can succeed even if the network response never reaches the agent. Any recovery design that records only what the model intended will eventually disagree with what the inbox contains.

A checklist is cheap until the work becomes granular

The smallest checkpoint is a checklist. The inbox agent might store four flags: messages fetched, classification finished, actions applied and summary prepared. After a restart, the orchestrator finds the first unfinished stage and runs it again. Implementation overhead is low because the state fits in one database row or workflow record, and operators can read it without replaying a history.

Recovery reliability is also low for this inbox case. If the agent fails halfway through applying actions, a stage-level flag cannot identify which messages were archived or which drafts were created. A per-message checklist improves matters by recording each message ID and status, but the design then needs fields for the chosen action, tool result and error state. At that point, the checklist has become a small state database, with the same ordering and consistency problems that its apparent simplicity was meant to avoid.

A checklist remains useful when steps are coarse, deterministic and safe to repeat. Fetching message metadata again usually fits that description. Creating a draft does not, unless the email tool can recognize a repeated request and return the existing draft.

An event log preserves how the run reached its state

An event log is an append-only sequence of workflow facts. For the invoice thread, it could record that the message was fetched, classified as requiring a reply, approved for drafting, submitted to the email tool and associated with the draft ID returned by that tool. Recovery code reads those events and derives the current state instead of trusting a single mutable flag.

This approach offers stronger recovery and a better audit trail than a checklist. It also adds writes during the run, storage that grows with activity and replay work during startup. Replaying a long log can add latency, although the system can compact older events after it has verified a later checkpoint. The larger engineering cost is semantic: every event needs a stable meaning, and code must handle older event shapes after the workflow changes.

Event logs do not remove the narrow failure window around an external action. A sound sequence first records an intent to create the draft, then calls the email service and finally records the returned draft ID. If the process stops after the call succeeds but before the result is saved, recovery sees an unresolved intent.

An idempotency key, a stable identifier that makes repeated requests produce one outcome, closes that gap when the tool supports it. The agent retries draft creation with the same key and receives the prior result. Without that support, recovery has to reconcile: search the invoice thread for a draft carrying the expected message ID or workflow marker, attach its ID to the log, and ask for human review if several candidates exist.

A snapshot restarts quickly but can hide the path

A full state snapshot serializes the inbox run as it exists at one moment. In this case, that means the original message IDs, the current position in the queue, saved classifications, completed tool results and any pending approval. On restart, the orchestrator loads that object and continues without replaying every earlier event.

“Full” refers to application state, not the model's hidden internal state. A snapshot cannot preserve an unrecorded judgment or recover a tool response that vanished before the application received it. Teams must explicitly store the classification, selected action and external object ID if those facts should survive. Otherwise the model repeats the reasoning, which consumes tokens and can produce a different answer.

Snapshots trade replay latency for write and maintenance overhead. Large snapshots take longer to serialize and store, while frequent snapshots increase database traffic. They also need schema migration when workflow code changes. A snapshot written after every message gives tighter recovery than one written after the whole inbox, but neither resolves an external side effect that was never recorded.

For many long-running agents, the practical design is a snapshot plus a short event tail. The snapshot provides a fast starting point; newer events preserve actions completed since it was written. This costs more to build than a checklist, but it avoids replaying an entire run while retaining enough history to investigate the invoice draft.

Put the checkpoint next to the side effect

Checkpoint frequency should follow the cost of repetition, not an arbitrary timer. Before creating the invoice draft, the workflow saves the message ID, intended action and request identifier. After the tool returns, it stores the draft ID before advancing the queue. A crash at either boundary leaves evidence that recovery code can interpret.

The original inbox selection also belongs in durable state. If the agent merely reruns “find unread messages” after a restart, archived items disappear from the result and newly arrived mail enters a workflow that did not classify it earlier. Saving the initial message IDs gives the run a stable scope. A later cleanup run can handle new arrivals.

External reality still wins. Before repeating an unresolved action, the agent should inspect the email system and compare it with the checkpoint. If the records disagree, the safe fallback is to pause automation, surface the message and draft IDs, and let a person decide which artifact to keep. Re-running the model without reconciliation can make the record less clear.

Approval waits deserve the same treatment as crashes. When the inbox agent prepares drafts and pauses overnight for review, it should save the queue, existing draft IDs and approval status before releasing its worker. Keeping a process alive during the wait consumes resources and still provides no protection against a restart.

Match the design to the damage a retry can cause

A checklist has the lowest implementation overhead and the weakest recovery once a step touches many individual items. An event log records the strongest history, but it requires stable event definitions, replay logic and explicit handling of incomplete tool calls. A snapshot resumes fastest from a known point, though its reliability depends on how often it is written and whether it includes external identifiers.

For the inbox workflow, stage-level checklists are adequate for fetching and summarizing. Draft creation needs per-message records, reconciliation and idempotency where the email interface offers it. A snapshot at each approval pause, backed by events for subsequent tool calls, is usually a more defensible choice than saving the model transcript and hoping it can infer what happened.

The key acceptance test is concrete: stop the agent immediately before and after it creates the invoice draft, restart it, and inspect both the durable record and the inbox. A recovery design passes only if neither interruption produces a duplicate draft, silently drops the thread or changes the run's original message set.

Questions people ask

Does saving the agent's conversation history count as checkpointing?

Only if the history also contains durable, structured records of workflow state and external object IDs. A transcript may show that the agent planned to create a draft, but it cannot prove that the email service accepted the request. Recovery needs tool results and stable message identifiers, not just the model's account of its work.

How often should a long-running agent save a checkpoint?

Save around actions that are costly, irreversible or difficult to detect after a retry, and before the workflow waits for approval or releases its worker. Cheap read operations can tolerate wider intervals. The right frequency follows the damage from duplicate work and the database traffic created by each checkpoint.

Are event logs more reliable than full snapshots?

Event logs preserve more history and make incomplete actions easier to investigate, while snapshots restore current state with less replay. Neither guarantees clean recovery from an unrecorded external action. A snapshot plus later events often gives the inbox agent a useful balance, provided both retain the email service's message and draft IDs.

Can an agent guarantee that an email action happens exactly once?

Only when the surrounding systems cooperate through a transaction or an idempotent operation. Most cross-system agent workflows cannot assume that guarantee. The fallback is effectively-once behavior: record intent, retry with a stable key where possible, inspect the inbox after uncertain results and pause for review when reconciliation remains ambiguous.