Long tasks must be stoppable at any time

What it is

Once an agent starts a long task, a person must be able to stop it at any moment, and stop has to be real: no further tool calls, no further outbound sends, no further writes. Long-running tasks must be abortable is an emergency stop on execution, not a greyed-out button beside a progress bar.

Click stop, get “finishing up,” then three more mails go out — that is not abortable.

Why it happens

Automation folds sense–decide–act into a continuous process; a continuous process has no default human insertion point. A long task stretches that process to minutes or hours, and human intent changes mid-way: the object was wrong, priority moved, the scope was misread. Without a stop, the person waits it out and repairs; repair cost scales with how many world-boundary crossings already happened. In supervisory control, the person’s ability to inhibit automation is part of the level; an agent that cannot be inhibited has quietly risen to full autonomy, whatever the UI says.

Abort has to act on the execution scheduler, not on rendering. Stopping streamed text while tool calls are still in flight is a fake abort.

Studying it

Let an agent run a long chain with multiple outbound acts, and issue abort at step n. Dependent variables: whether any outbound act happens after the abort command, latency from click to a true stop, whether people believe it has stopped. Independent variables: whether abort is wired to the scheduler, whether in-flight tool calls are cancelled, whether the UI says “stopped” before it has.

“Thought it had stopped” is the subjective measure that matters; it must be checked against the action log.

Where it stops holding

An act that ends in one click has no mid-course abort; confirm or undo is the tool. Physical processes that cannot be interrupted (some industrial steps) need a pre-designed safe shutdown, not a stop-anytime in the UI. Whether completed steps can be rolled back is a rollback question; this entry only requires “nothing further from this moment.” Whether the process is visible is not in this entry.

Applying it

• A long-task UI keeps an abort control, wired to the scheduler: after it fires, forbid new tool calls and new outbound acts. Cancel in-flight calls that can be cancelled; mark those that cannot as “cannot stop, still in flight.”
• Do not write the state as stopped until it has actually stopped. If wrap-up still contains outbound acts, those acts must be stripped before it may be called abort.
• Check: on a test ledger let the agent fire a sequence, click stop mid-way, and see whether the ledger still grows after the click. If it grows, abort is not wired to the scheduler. Then ask the operator “has it stopped” — disagreement with the ledger means the display is fake too.

Related

• Same group: L4.05.2 Steps already executed must be rollable back · L4.05.3 A partially completed state must be made explicit
• Nearby: L4.08 Visibility of Task Progress · L3.11 Streaming the Generation Process · L4.07 Pre-action Confirmation
• Search terms: abort · interruptibility · supervisory control