Most agent frameworks treat a task's lifetime as binary: it's running, or it's done. In practice, a multi-step agent task — one that calls several tools, waits on external systems, and takes anywhere from seconds to minutes — needs a third state that most teams never design on purpose: stopped early, on purpose, by someone other than the agent.

Cancellation gets bolted on late, usually as a context timeout wrapped around the whole run. That's better than nothing, but it answers the wrong question. A blanket timeout tells you *when* to give up; it says nothing about *how* to give up safely, which is the part that actually causes incidents.

A timeout is not a cancellation policy

Killing a task mid-flight raises questions a raw timeout doesn't answer. If the agent was halfway through a tool call that writes data, does the write get rolled back, allowed to finish, or left in an unknown state? If it had already produced three good intermediate results before the fourth step hung, does the caller get those three back, or nothing? If the same task gets retried after a cancel, does it repeat side effects that already happened?

None of these are edge cases — they're the normal shape of failure once an agent runs long enough to call a paid API, write to a database, or wait on a queue. A timeout that just severs the connection turns an ordinary slow step into a data integrity question.

Three decisions worth making explicitly

Treat cancellation as a small state machine with intentional transitions, not a signal you hope the agent notices:

  • Where cancellation is checked. Between tool calls is cheap and safe. Mid-tool-call requires the tool itself to support interruption, which most third-party APIs don't — so decide up front which steps are cancellable and which are not, and say so in the tool's description.
  • What happens to partial results. If a task produces incremental output, that output should survive a cancel by default. Discarding a mostly-finished result because the last step didn't complete is the single most common cause of "the agent did the work twice" complaints.
  • What the caller is told. "Cancelled" and "failed" are different outcomes and should never share an error code. A caller retrying a cancelled task needs to know whether it's safe to retry from scratch or whether it should resume from the partial state.

None of this requires a sophisticated orchestration layer. It requires writing down, for each tool in an agent's toolkit, whether a mid-execution cancel leaves the world in a state you'd be comfortable inheriting. If the honest answer is "no idea," that's the gap — and it's worth closing before a user hits cancel for the first time in production, not after.

AI AgentsAgentic AI