What happens when your agent stops halfway?

When an agent stops halfway, a task may be only partly complete. A document might have been edited but not saved, or some actions in a sequence may have finished while others did not. If the agent restarts, it could repeat work or continue using incomplete information without anyone noticing.

You can reduce this risk by breaking work into steps you can check, saving progress, and making retries safe. Give each task a clear status, alert a person when work is interrupted, and provide a controlled way to resume or roll back. You cannot always prevent a stop, but you can make it possible to understand what happened.

Why does an agent stop halfway?

An agent depends on more than the model doing the work. A timeout can interrupt a long process. A network error can break the connection to a service. A usage limit, crash, unavailable tool, or problem with the input can also stop a task. Sometimes a person stops it deliberately, for example because a proposed action needs review.

The cause does not tell you which steps have already run. A connection might fail after an external service has applied a change but before the agent receives confirmation. The agent may not know whether the action succeeded. The system should check the actual state before trying that step again.

What can go wrong?

The simplest failure is a partial change: some files, records, or messages have been updated and others have not. This can leave inconsistent information. Restarting without checking may send the same message again, create a duplicate record, or overwrite a change. The agent might also stop without reporting a visible error. The task can appear finished even though work is missing.

The impact depends on the task. An unfinished summary usually takes less effort to repair than a set of changes to customer records or a workflow that triggers follow-up actions. Decide in advance which steps affect systems outside the agent and need extra checks.

Save progress and make resuming safe

After each important step, save a checkpoint: a durable note of what started, what finished, and what is needed to continue. It might include the task status, source used, result of the last step, and any approvals still needed. Store sensitive content only when necessary, and limit who can access it.

Design steps so that repeating them does not cause an unwanted duplicate effect. Such a step is called idempotent: repeating it leads to the same intended end state without adding another change. Instead of blindly adding a new item, the agent can check whether it already exists and update it if needed. If an action is not safe to repeat, record its result and check the current state before continuing.

For related changes, you can use an approach that confirms all the changes together or none of them. This is not possible with every external service or long workflow. Sometimes you need a compensating step to undo or repair an earlier action. Record which actions have run and the corresponding recovery action.

Make status, alerts, and handoffs clear

Give every task an accurate status, such as in progress, stopped, failed, or complete. Mark a task complete only when its required steps have finished and been checked. A stopped task is not necessarily a failed one: some of its work may be worth keeping.

Alert a person when the agent cannot safely continue on its own, for example when an action may have run, approval is missing, or resuming could overwrite information. Include useful context in the alert: the task’s goal, last completed step, error message, and possible next actions. Someone can then review or take over without reconstructing the whole process. Read more about designing reliable agents and managing progress and memory.

Record what happened and test interruptions

Logs and an audit trail help show which steps the agent attempted, which succeeded, and where the task stopped. Record relevant events and timestamps, the tools used, status changes, and any human approvals. Avoid logging more personal or confidential information than necessary. A log does not replace checking the task’s state, but it helps investigate differences between the expected and actual outcome.

Test what happens when you deliberately stop the agent halfway through. Use an isolated environment with test data, and check that resuming does not duplicate actions, the status is accurate, and a person receives enough context. Also test what happens when a tool does not respond or confirmation never arrives. Guidance on testing agents and agent observability can help you check these situations systematically.

A short checklist

• Can you tell which steps have already finished?
• Is a checkpoint saved after important steps?
• Can a step be repeated safely, or is the current state checked first?
• Does every task have an accurate status, with a person alerted when something is uncertain?
• Is there a way to recover or roll back partial changes?
• Can a person take over with the context they need?
• Have you tested what happens when the agent stops halfway?

An agent can still be interrupted. Saved progress, safe retries, visible status, and tested recovery make the interruption manageable. You can see what happened, decide whether it is safe to resume, and avoid mistaking a silent failure for a completed task.