An agent receives approval to process a partial refund. It sends the request to a payment API, and the process crashes. Maybe the payment service completed the refund. Maybe the request never went through. A replacement agent spins up and finds an operation record marked dispatched with no outcome written.

This kind of ambiguity isn’t unique to agents. Any distributed worker crashing mid-mutation faces the same problem. But a conventional worker resumes a predetermined workflow from the last checkpoint. An agent does something more dangerous: it reasons on its own. Given the same customer request and no outcome record, it might come up with a different plan, pick different parameters, or decide to issue a new refund instead of continuing the one already approved.

If the original refund went through, a second attempt refunds the customer twice. The charge still has enough remaining balance to cover another partial refund, so nothing stops it.

An agent’s process, its in-memory variables, its transient reasoning context: all disposable. The business operation is not. The refund, its approval, its parameters, its current status. A long-running agent can preserve useful state for as long as it runs. The requirement: no essential operation should depend on the original execution surviving.

Before dispatching the refund, the application commits a durable operation record to a transactional store. That record includes the approved amount, the applicable authorization, the idempotency key the application sends to the payment provider, the application’s operation identifier in the provider’s metadata, and a status.

Source link