An agent can be stopped in an instant. Reconstructing what it set in motion may take much longer.
A subscription company experiences a service outage. To make amends, its customer-support manager authorizes an AI assistant to issue a one-time $10 credit to each eligible customer. The assistant can examine affected accounts, submit credits through a payment service, update customer records to record those credits, and notify customers. The account-management tool also exposes subscription dates: technically the assistant can change them, but the manager has not authorized it to change subscription terms.
Rather than following one fixed script, the assistant assembles its working sequence as it goes. It retrieves customer records, chooses an order for processing them, calls the credit service, checks some responses, and updates account records. When a few calls time out, it tries alternative ways to complete the task. For customer notifications, it selects an existing outage-compensation email template—one written for a different remedy, which promises an additional month of subscription instead of a $10 credit.
Then a customer reports receiving two credits. An operator sees repeated submissions and presses Stop.
The dashboard changes to Agent stopped. Yet the payment service is still processing instructions it accepted earlier. Some credits are complete; others are queued. For several timed-out requests, nobody yet knows whether the service accepted them. An email service continues delivering messages assembled from the wrong template. During some account updates, the assistant also changed subscription end dates it was not authorized to change. As a result, some customers received an actual extension, while others received only a message promising one.
The AI is no longer making decisions. Its decisions are still producing effects.
This is a hypothetical incident. Queues, timeouts, repeated requests, and failed cleanup are familiar engineering problems. The unusual difficulty is more concrete: no one had designed a recovery procedure for the particular combination of actions this AI chose. The assistant may also be the only one who remembers why it took that route. Its explanation could help—but it cannot establish which payments settled or which emails arrived.
Stopping the actor is one decision. Understanding what happened outside it is another.
The stop button cannot recall an external instruction
A stop command can prevent a model from making its next decision. It may stop a worker from accepting new jobs or force a workflow to terminate. But an external service does not necessarily stop just because the system that contacted it has gone quiet.
Consider four customer accounts. For one, the assistant prepared a credit but never sent it. For another, the payment service accepted the request and is still processing it. For a third, the credit is confirmed in the customer's account. For the fourth, the API call timed out and the result remains unknown.
These are four different facts about the world: not sent, in progress, completed, and unknown. A timeout is evidence about communication, not proof that the other side did nothing.
This distinction matters before anyone attempts recovery. The first request may be safely withheld. The second might still be cancelled, subject to the provider's rules and the stage of processing. The third has already changed a balance. The fourth calls for reconciliation before a repeat request or reversal.
Temporal's distinction between cancellation and termination illustrates that stopping a workflow and allowing its cleanup are already separate concerns in established engineering. Cancellation can give a workflow a chance to clean up; forced termination does not. Neither can make an external payment or a delivered email vanish.
The dashboard's Agent stopped label tells the operator very little about the four customers. It does not settle their accounts, recall their emails, or resolve the timed-out request.
Why the standard answer to duplicate requests is not the entire answer
Engineers will immediately ask why the payment service allowed two credits. That is the right objection.
A standard protection against accidental duplicate submissions is an idempotency key. When a service supports it, a client can attach a stable identifier to a logical operation; a retry using that identifier can be recognized as an attempt to repeat the same operation rather than to create a second one. Stripe's API documentation describes this pattern, including parameter checks on repeated keys and limits on key retention.
The key is normally assigned by the payment integration or tool layer, not invented by the language model. Suppose the assistant receives a timeout and makes another submission through a different tool path. If that path assigns a new request key rather than reusing the identifier for the original credit, the payment service may see two distinct requests. This depends on how the integration and provider handle duplicates; a correctly implemented protection for the same operation would prevent the ordinary retry failure.
In our incident, that means the provider's systems might have worked as designed while the company still owes an explanation for two $10 credits to one customer. The team must check what actually settled, including transactions completed after the operator pressed Stop.
The AI assembled the work. Who assembled the recovery plan?
For a familiar order-processing workflow, a business may already know which steps can be cancelled and which require a separate remedy. The saga pattern addresses this kind of multi-service coordination. Some implementations can even register possible compensations while a workflow is running, as Temporal's guidance explains. The sequence does not always have to be fixed in advance.
That is useful when the operation has been planned for. But nobody wrote a tested procedure for this assistant issuing a credit, switching services after a timeout, altering a subscription date, and sending a mismatched message. The individual tools may all have ordinary error-handling rules. Their accidental combination may not.
Imagine an operator telling the AI to “undo the last three steps.” Did the payment settle? Was the account update the AI's, or did a support employee subsequently change the same account for a legitimate reason? If the company restores yesterday's database snapshot, it may erase that employee's correct update and still leave the payment and email untouched.
Microsoft's guidance on compensating transactions also cautions that compensation may not restore the original state and can itself fail. In the subscription incident, there is no reason to assume that running an action in reverse would repair every affected customer's situation.
A system able to invent a course of action is not automatically able to invent a safe way back.
The agent may be the best witness—and not a sufficient witness
After the operator presses Stop, the assistant can still explain why it retried, which information it relied on, and how it ended up using the wrong email template. That account is valuable. It may also be inaccurate. Perhaps the assistant took a timeout to mean that payment had failed; perhaps it remembers only its latest attempt.
The support team asks it what happened to customer 104. It replies, “I issued one credit.” The payment provider shows two settled credits. For customer 205, the assistant reports a successful payment, but the provider has no matching completed transaction. An account-change history shows a subscription date was altered; the email platform shows that an extension promise was sent to a different set of customers. Some discrepancies can be resolved. Others remain open pending a response from the provider.
Part 8 asked who could establish what an AI's proposed click would do. The situation here is the mirror image: after a problem, the AI may be the most articulate witness to its own actions, but not the final evidence of their effects.
The operations team does not need to treat the assistant as dishonest. It simply cannot treat a plausible narrative as a substitute for checking customers' accounts and the services that actually handled the work. Even a second AI reading the same partial history would not resolve a missing payment confirmation.
A safe recovery may be a new decision, not a reversal
Once the company stops sending duplicate credits, it has decisions to make about individual customers. A second $10 credit might be left in place as goodwill rather than reclaimed. For someone whose subscription date was incorrectly changed, billing may need correction. For someone who received the extension email but no account change, support must decide whether to honor the promise or explain the mistake. Contract terms and applicable law may affect what the company must do; the support manager may need to involve someone with broader authority.
None of these cases is solved merely by restoring a database backup. Some customers have already read the message; others may have acted on it. Attempting to reverse a credit could itself create confusion or cost more than accepting the mistake.
A reasonable recovery might leave the two $10 credits untouched, correct a subset of account records, and contact customers who received an inconsistent promise. That would not return the company to the moment before the incident. It could nevertheless be a better outcome than an indiscriminate rollback.
A simple interruption test
A company could rehearse this hypothetical incident in a test environment rather than risk customer money. Let the assistant work on sample accounts, stop it during a timeout, and allow a mock payment service to finish processing earlier requests. Have another simulated employee make a legitimate account change while the incident unfolds.
Then ask the support team what it can honestly tell each customer. Did a credit settle? Is another still pending? Was a renewal genuine or an AI mistake? Which messages went out? A test that ends at “Agent stopped” misses all of these questions.
This is a suggested exercise, not a completed experiment. The important result would be whether the people responsible for the incident can establish enough of the real situation to decide what to do next.
The system must survive its own interruption
Part 8 asked who knows what an AI's next click will do before it happens. After an unexpected sequence, a complementary question follows: who can establish what its earlier clicks actually did, when the AI itself can no longer be relied upon?
The assistant was useful because it could perform work without a person specifying each click. That freedom also meant that its precise sequence of credit requests, account edits, and messages had not been planned out in advance. Once it stopped, the remaining problem belonged to the company, its customers, and the outside services that had already acted.
The stop button mattered. The customer accounts and the messages still mattered too.
A stopped agent is a fact about the agent. Safe recovery is a claim about the world.
References
- Amazon Web Services. Saga patterns. AWS Prescriptive Guidance.
- Google Site Reliability Engineering. Incident Management Guide.
- Microsoft Azure Architecture Center. Compensating Transaction pattern.
- Stripe. Idempotent requests. API Reference (documentation consulted October 2026).
- Temporal Technologies. Cancellation and Termination; Saga Pattern. Documentation consulted October 2026.