# Explain why an agent run stopped

A stopped run may be waiting for approval, out of budget or uncertain about a completed write. Give operators a state they can act on.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Read the durable status first

Locate the run record and its last operation. Do not begin by asking the model to summarise what happened. The transcript can help explain intent, but the executor's records establish which actions were accepted and completed.

Identify the stopping reason: policy denial, approval required, input needed, budget exhausted, downstream failure or uncertain effect. These categories should lead to different recovery actions. A generic "agent error" forces support to reconstruct distinctions the application already knows.

Check whether work remains in flight. A stopped dialogue does not necessarily mean a queued mutation has stopped. The operator needs to know whether another worker can still change the target.

## Match the intervention to the state

For missing input, return the specific question to the user. For a policy denial, explain the permitted boundary rather than advising repeated attempts. For an approval wait, direct the request to an authorised reviewer through the normal workflow.

When a budget is exhausted, inspect the repeated calls before extending it. The agent may be looping on an impossible task or retrying a permanent error. Increasing the limit without understanding the pattern can multiply cost and side effects.

For an uncertain mutation, reconcile the operation identifier with the downstream system. Avoid creating a replacement operation until the original result is known or a deliberate recovery procedure handles the ambiguity.

## Preserve the user's intent during recovery

A resumed run should continue the same authorised task, not reinterpret a vague conversation into a broader one. Confirm the target, proposed change and any approval still match current state.

If the order has changed since the run stopped, the previous proposal may no longer be suitable. Return for review where required. A restart is not permission to bypass a failed eligibility check.

Use the supported resume or cancel action so the state transition is recorded. Editing database flags by hand can leave queued work active or make the audit trail contradict the actual effect.

## Close with the recorded outcome

After recovery, inspect the business record and operation result. Send the user a concise explanation of what changed, what did not complete and any action still required. Avoid presenting an inferred outcome as confirmed.

Record the failure mechanism and whether the runbook provided enough information. Repeated ambiguous stops often indicate missing product states or poor tool error contracts. Fixing those contracts makes future incidents easier to resolve than adding more instructions to the assistant's prompt.

## Sources

- [OWASP: logging guidance](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
- [AWS Builders' Library: idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)