A long-running migration agent is processing 500 database records in batches of 50. After a server restart, the agent begins processing from the beginning and migrates the first 200 records a second time, creating duplicate entries. The agent has no record of which records were already processed. What state management mechanism was missing?

State persistence is essential for long-running agentic tasks that may be interrupted. The completed-item registry pattern stores the identifier of each processed item to a durable store (database table, file, Redis set, etc.) immediately after that item is successfully processed. On startup or restart, the agent queries the registry to get the set of already-completed items and skips them, processing only the remaining items.

The registry entry should be written atomically with or after the actual processing operation to avoid counting an item as complete if the write to the registry succeeded but the actual work failed.

Option A (larger batch size) is a throughput optimization, not a state management solution. Increasing batch size reduces the chance of a mid-batch restart but does not eliminate it, and does nothing to help recovery when a restart does occur. For 500 records, a single batch large enough to prevent interruption may not be feasible.

Option C (delete source records after processing) is a destructive approach with serious risks in a migration context. Source data deletion as a completion signal creates a point of no return and prevents rollback if issues are discovered later. It is also fragile — a failure between processing and deletion leaves ambiguous state.

Option D (single atomic transaction) may not be feasible for 500 records across external systems, and many migration scenarios involve heterogeneous data sources where a single spanning transaction is architecturally impossible. Even when possible, a transaction that spans hours is impractical.

A persistent completed-item registry is the standard, safe, and resumable solution.