MyDot Consultancy

Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.

Imagine an operator pressing cancel in a test scenario. The agent stops producing messages, but a queued request still reaches the customer system. Is the task canceled? From the user’s perspective, perhaps. From the business’s perspective, an action was still pending. A stop button needs an execution design behind it.

The same problem appears at the other end of a run. An assistant says it is finished, while a document is still uploading or an approval remains outstanding. Starting, stopping and completing work should be explicit states that the application can verify. They should not depend on conversational tone.

What does finished mean?

For a hypothetical agent preparing a monthly supplier report, completion might require a saved report, a reconciled data range and a successful quality check. If the request also includes sending the report, completion may require a verified send to approved recipients. Those are different scopes and should have different acceptance criteria.

Write the postcondition before the run begins. An artifact path, a record identifier or a checked system state provides stronger evidence than “the agent attempted the task.” If a required check fails, the run should remain incomplete even when the generated document looks polished.

Anthropic’s long-running agent case study describes premature completion as a failure mode in coding work. The business inference is broader: systems need explicit completion evidence because an agent’s own assessment can be wrong. The case study does not establish a universal solution for every workflow.

What is the difference between blocked and failed?

Blocked means progress depends on something unavailable: permission, information, approval or an external service. Failed means an error has prevented the intended result and the current recovery path cannot safely complete it. The distinction helps route work to the right person.

A report missing an approved exchange-rate source is blocked on evidence. A corrupt export that cannot be parsed may be failed pending repair. Neither should be counted as a successful report merely because the assistant produced a summary. Conversely, a correctly blocked task may demonstrate that an important control worked.

Use status labels consistently in the interface, logs and operational reporting. If “done” means the model stopped in one dashboard and the business outcome completed in another, managers will draw misleading conclusions about throughput and reliability.

What should a cancel request stop?

List the stages that may be active: model generation, tool execution, queued jobs, uploads, scheduled continuations and downstream callbacks. A cancellation design should specify which can be interrupted, which can only be prevented from starting and which may already have committed an action.

Do not promise rollback where none exists. A sent email may be irreversible. A saved draft may be removable. A payment instruction may require a separate authorized reversal. The cancellation message should describe the known state and any remaining action required, without implying that stopping the agent undid the outside world.

The OpenAI Agents SDK running-agents documentation covers run lifecycle and error handling. Those mechanisms are part of execution management. Application designers must still connect them to queues, integrations and business-specific cancellation semantics.

How do you prevent endless work?

Give the run a bounded purpose and an operational budget. Relevant limits can include elapsed time, tool attempts, repeated identical failures and resource consumption. Choose limits according to the task’s risk and normal behavior rather than using a single arbitrary value everywhere.

A limit should lead to an intelligible outcome. If the supplier report reaches its time budget, save verified progress, identify unfinished checks and stop starting new work. Do not discard everything silently or manufacture a complete-looking result to satisfy a deadline.

Repetition is a particularly useful signal. If the agent keeps calling the same unavailable tool with unchanged arguments, another attempt may not add information. Recovery policy should distinguish transient failures from missing authority or invalid inputs. More persistence is not always safer or more productive.

What belongs in the operator’s control panel?

• The current business objective and the scope of permitted actions.
• The latest verified milestone, with its artifact or record reference.
• The action currently executing and any queued consequential actions.
• The reason for a pause, blocker or failed recovery.
• The effect of canceling now, including known irreversible actions.
• The person or process responsible for unresolved work.

Avoid showing a percentage complete unless it has a defensible meaning. A plan with ten steps is not necessarily ninety percent finished after nine steps; the final step may depend on a difficult approval or an unavailable service. Named milestones are often more useful than a reassuring progress bar.

How do you test the stop button?

Use a controlled environment with synthetic data. Cancel before a tool call, while a tool is running and after the remote system has accepted the action. Inspect the final destination, not only the agent interface. Confirm that no continuation restarts canceled work through a scheduler or retry queue.

Also test stopping at an approval boundary. The SDK approval guide documents paused runs and resumption. Your application should define whether cancellation invalidates pending approval and ensure that an old approval cannot revive a canceled task unexpectedly.

Finally, test a false completion claim. Arrange for an upload or validation to fail and verify that the application does not label the task completed. A test that checks only the assistant’s final sentence misses the failure mode this control is meant to prevent.

Make stopping part of the service promise

Users need to know what the system can finish, what it can pause and what it cannot undo. Document those boundaries in ordinary language. Give operators a reliable way to disable an integration when individual cancellation is insufficient.

An agent’s usefulness includes its ability to stop honestly. Clear terminal states protect users from false success, protect operators from hidden work and make failures easier to recover. The stop button deserves the same design attention as the feature that starts the task.

Sources and further reading

Anthropic: Effective harnesses for long-running agents. Coding case study describing premature-completion failures; published November 2025.

OpenAI Agents SDK: Running agents. Lifecycle and recovery reference; checked October 2026.

OpenAI Agents SDK: Human-in-the-loop. Paused approval and resumed execution behavior; checked October 2026.