When a Tool Fails: How to Stop an Agent from Repeating an Action

The problem: an action can happen even when its confirmation never arrives

An agent that uses tools may start an operation in another system and lose its connection before receiving a clear response. The task is then in an ambiguous state: the agent does not know whether the destination system applied the change, but the missing confirmation does not prove that it did not. Running the same action again without checking the state can create a duplicate or increase the impact.

This problem is different from generating a response again. In a conversation, a repeat may produce different text; when a tool changes a record, books an appointment, or modifies a file, repeating the action may create a second external effect. For that reason, a recovery procedure should begin by finding out what happened, not by automatically repeating the original instruction.

This guide proposes an operational discipline, not a guarantee that every system can be recovered. The ability to verify, stop, or compensate depends on the specific tools and the features they document. If the destination state cannot be observed, the agent should treat uncertainty as a reason to pause or escalate, not as permission to make an assumption.

Map the workflow before designing recovery

Describe the task as a sequence of specific steps and identify the tools involved. For each step, note whether it only reads information, writes or changes state, or can produce an external effect that may be difficult to reverse. This classification helps focus controls on the steps where repeating an action could have consequences.

Classifying a tool by name alone is not enough. The same integration may provide both a query and a write operation. Nor is it enough to describe the agent’s general intent: “manage an appointment” may involve checking availability, creating a booking, and sending a notification. Each operation may have a different state and require a different recovery decision.

Also identify what observation would allow you to consider each step complete. For example, updating a record may require reading it again and checking the relevant fields. For a booking, it may be necessary to check whether an appointment with the expected details exists. For a code change, you might inspect the file contents or the status of the change. These are design patterns: adapt them to the actual capabilities of each system.

Before allowing a write, define its scope: which entity the agent may modify, which data it may change, and which actions are outside its permissions. Permissions limit potential harm, but they do not prove that an earlier action succeeded or make a repeat safe. Tool selection should preserve this distinction between authorization and knowledge of the state.

Classify the state before deciding

After a failure, record the last reliable observation and classify the interrupted step. A practical taxonomy distinguishes four states: the action was not started; the outcome is confirmed; the outcome is uncertain; or the task is partially complete. The classification should be based on available evidence, not on the explanation the agent would prefer to give.

“Not started” means there is sufficient evidence that the step was not sent or did not begin. “Confirmed” means a response or a later lookup verifies the expected outcome. “Uncertain” means there is not enough evidence to decide whether the action ran. “Partial” means some steps or effects were completed while others remain pending. If it is unclear which of two categories applies, keep the more cautious classification and do not turn uncertainty into confirmation.

The distinction matters because the appropriate action changes. If the step did not start, it may be possible to start it, subject to permissions and workflow rules. If it is confirmed, do not repeat it merely to obtain a clearer response. If it is uncertain, first check the destination; if no reliable lookup exists, stop or escalate. If the work is partially complete, resume only from a verified state and take into account the effects that have already occurred.

The agent’s state should not be confused with the state of the external system. A checkpoint may store which steps the workflow attempted or which response it received, but that information may become outdated if another process changes the destination or if confirmation was lost. A checkpoint helps recover context; by itself, it does not establish the current state.

Before repeating, check the destination and look for signs of a duplicate

The first operational question is not “Can I call the tool again?” but “What can I observe now in the affected system?” If an authorized lookup is available, search for the object or change associated with the task using the data that identifies it. Check that the relevant attributes match and that an equivalent outcome does not already exist. Avoid relying on a single signal if it cannot distinguish the current operation from similar ones.

A request may have an operation identifier or a task-specific reference. If the system documents a way to look up the operation or recognize duplicate requests, follow that mechanism as documented. Do not assume that every tool accepts an idempotency key, that an identifier prevents repeated effects, or that a result with the same text necessarily corresponds to the same action.

Detecting duplicates requires clear criteria. For a record update, compare the record identifier and the fields that were meant to change. For an appointment, check the details that distinguish the booking and its current status. For a code change, inspect the file or the status of the change before applying another modification. These are examples of checks, not descriptions of guaranteed features from any provider.

If the status lookup is unavailable, returns incomplete information, or cannot distinguish a previous operation, uncertainty remains. In that case, define a stop condition. The lack of a verifiable response must not become a favorable assumption, especially when a second execution could create an additional effect.

Choose whether to continue, compensate, stop, or escalate

Continue when the previous state is sufficiently well understood, the pending step is within the authorized scope, and there is a way to verify its outcome. Resuming means moving forward from the last checked state, not replaying the entire sequence from the beginning. If the workflow has several steps, identify which are confirmed and which have not yet started so that work that has already produced effects is not repeated.

A compensation attempts to correct a confirmed effect through a different action. It is not always possible, and it does not necessarily restore the exact initial situation. Before designing one, check that the system documents the operation, that the account has permission to perform it, and that the change will not affect a later state. If you cannot confirm these requirements, do not present the compensation as a guaranteed reversal.

Stopping is a valid decision when the next action could worsen an uncertain situation, exceed the authorized scope, or lack sufficient verification. Escalating to a person is appropriate when someone needs to interpret ambiguous evidence, approve a higher-impact action, assess a compensation, or decide how to handle a change that cannot be safely undone. The pause should preserve the minimum context needed to review the case.

Define in advance which conditions require human intervention. Examples include an uncertain write outcome with no destination lookup; an operation with significant consequences that could be duplicated if repeated; an undocumented compensation; insufficient permission to verify; or a discrepancy between the state stored in the workflow and the destination system. Set these thresholds to suit the impact and obligations of the environment rather than using one rule for every action.

Applied examples: an appointment booking and a code change

For an appointment booking, a lost response after the request is sent leaves open the possibility that an appointment already exists. The agent should check the booking state using the actual capabilities available and verify whether the expected appointment appears. If it finds a matching result, it should not create another booking to make up for the missing confirmation. If it cannot distinguish an operation that already occurred from one that is still pending, it should stop the automatic attempt and request review under the service policy.

The check should also account for the fact that the state may change between the lookup and the next action. Therefore, the workflow should not treat an old observation as an indefinite guarantee. If the tool provides an operation reference or a documented status lookup, use it; if not, limit conclusions to what was actually observed. Do not tell the user that the booking is confirmed if the evidence shows only that the agent tried to request it.

When modifying code, the risk is not limited to repeating a write to the same file. The contents may have changed since the checkpoint, or one part of the task may have been applied while another remains pending. Before modifying it again, inspect the current state and compare the expected change with the observable result. If the intended modification is already present, avoid blindly applying it again. If the state differs or cannot be reconstructed, stop the workflow to review what should be preserved and what can be corrected.

In all three examples, the agent should communicate the outcome precisely: an attempt was made, an effect was verified, the outcome is uncertain, or intervention is required. Describing the process must not turn an issued call into a completed task.

Save useful context without confusing it with the current state

Resuming a task does not require indiscriminately preserving the entire conversation. Save the operational state needed to identify the task and reconstruct its decisions: a task identifier or reference, if one exists; the current step; the tool and operation invoked; the last observed response; the classified state; checks performed and when they were performed; confirmed effects; and the reason for any pause or escalation. Also record what remains pending and which authorization limits apply.

Avoid saving sensitive data that is not needed for recovery. Define who can access the record, how long it is retained, and how it is deleted or protected under the rules of the environment. Retention duration should not be invented as a universal value: it depends on the applicable privacy, audit, and operational requirements. If the record contains personal data or system details, limit its scope and access.

Conversational memory and a task checkpoint serve different purposes. The former may help provide context for what the user asked; the latter should represent the operational state observed by the workflow. Neither replaces a lookup in the destination system when the task depends on an external effect that may have changed. Treat memory as a clue to guide recovery, not as sufficient evidence that the outside world is still the same.

Include timestamps or the order of observations when they are needed to interpret the record. If another person or process can change the system, an earlier reading may have become stale. When resuming a sensitive operation, check the relevant data again instead of assuming that the checkpoint remains current.

Permissions and autonomy: limit what the recovery step can do

Design permissions so that each operation has the minimum scope it needs. If the agent only needs to check an outcome, do not assume it also needs permission to modify other records or cancel operations. If a compensation requires a different permission, separate it from the lookup and define the condition that authorizes its use. This makes the distinction between observing, acting, and correcting explicit.

Recovery should not expand autonomy simply because the workflow failed. An agent that was permitted to make an initial change does not automatically gain permission to take additional actions, reverse it, or modify related objects. Specify which decisions are automatic, which require approval, and what information must be presented to the person making the decision.

Human approval should relate to a specific action and its evidence. Instead of requesting general authorization to “solve the problem,” explain what state was observed, what could not be confirmed, what action is proposed, and what effects it could have. If essential information is missing, the next step should be to obtain it or stop, not to request approval in a way that conceals the uncertainty.

Permissions reduce the set of possible actions; they do not resolve partial failures by themselves. Keep scope boundaries, lookup mechanisms, and recovery rules distinct. A reliable design needs all three wherever a task can produce external changes.

Test reproducible failures before deployment

Tests should simulate not only tool errors but also the separation between execution and confirmation. One important case is when the destination system applies a change but the agent does not receive the response. The test checks that the workflow queries the destination or stops rather than automatically repeating the action. If the test environment cannot reproduce this behavior, document the limitation and at least check the uncertainty policy using controlled ambiguous responses.

Include delayed confirmations. For example, the agent may pause and start a check while the original operation’s response arrives afterward. Verify that the late response updates the state coherently and does not trigger a second execution. Also test the opposite case: the first operation did not occur, and the workflow gets enough evidence to start the pending step under its rules.

Add scenarios involving duplicates, partial state, an unavailable destination lookup, insufficient permissions, and an undocumented compensation. For each one, define the expected outcome before running the test: which actions the agent may take, which it must avoid, what it must record, and when it must escalate. A test that only checks whether the agent responds does not demonstrate safe recovery.

Use verifiable outcomes. Count how many write operations were executed, check the final state in the destination system, identify duplicates, and review whether any effects occurred outside the authorized scope. Evaluate the original task and the recovery separately: the fact that the user eventually gets an outcome is not enough to show that the workflow avoided a repeat or respected its limits.

Repeat the tests when tools, permissions, resumption policies, or checkpoint formats change. Record the relevant versions and conditions so the results can be reproduced. Do not interpret a passing test as a guarantee against every future failure: it demonstrates the behavior observed in the defined scenarios.

Evaluate the workflow and prepare for deployment

Evaluate recovery using several measures, not a single success label. Review how often a write was repeated, how many final outcomes were verified, how many cases were correctly stopped, and how many actions exceeded permissions. Also review escalations to determine whether they contained enough context and whether they were triggered under the expected conditions.

Interpret metrics alongside test cases and potential impact. A low repeat rate does not demonstrate that the system is safe if it also failed to detect ambiguous tasks. A correct final state is not enough if it was reached through a duplicate action or an unauthorized compensation. Define in advance which outcomes are acceptable and which failures block deployment.

Before enabling higher-impact actions, rehearse the procedure with low-risk operations or an appropriate test environment. Confirm that status lookups work, permissions are sufficient to verify but not excessive for acting, records allow you to reconstruct what happened, and pauses reach a person able to decide. If a dependency is unavailable, limit the scope of automation rather than assuming the agent will be able to resolve it.

The available sources include tool-troubleshooting documentation and general guidance on incident management and disaster recovery. They do not, by themselves, establish how a specific integration behaves when a response is lost, whether it can detect duplicates, or whether an operation can be reversed. Verify those points for each system before turning a design recommendation into an operational instruction.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.