Cancelling does not undo
It stops further action. It cannot recall what already happened.
Cancelling stops an agent taking any further action. It is checked between planning steps.
Why not mid-call
A tool call already sent to your database has happened. There is no message that recalls it, so the honest place to stop is before deciding to do anything more — which is between one planning step and the next.
The alternative would be to kill the worker mid-request, which does not undo the call either. It just loses the record of it.
What you are told
Showing "cancelled" beside three completed deletions would be worse than useless, so the execution page says how many calls had already run and that they were not undone. The trace is kept in full: every call that went out, with the arguments it went out with.
If you need something undone, undo it in the system it happened in. The trace is what tells you exactly what to undo.
Three ways a run stops itself
Cancelling is the one you do by hand. Two others use the same checkpoint:
- •The step ceiling — an agent may only act so many times in one run. It bounds how much a run can do.
- •The time limit — set per deployment. It bounds how long a run may take, which the step ceiling cannot express: a handful of steps against a slow system can occupy a worker for minutes while looking, to the person waiting, like nothing is happening.
A run that hits either finishes as a run — a recorded trace, a stated reason, and whatever partial answer it had. Not a killed worker with no explanation.