You Stopped the Agent. Did the Work Stop?

In the last edition, I asked who can stop an agent's work and authorize its return. That question deserves more room, because “stopped” can hide several different states.

The conversation ended. The process exited. Access was revoked. A downstream service confirmed cancellation. Each tells you something useful. None, on its own, tells you what happened to everything the agent had already set in motion.

Once an agent can delegate work, trigger a pipeline, or schedule an action in another system, the stop button makes a promise that extends beyond the interface containing it. We should be precise about that promise.

Follow the work past the button

Consider a hypothetical development workflow. An engineer asks an agent to fix a checkout defect and deploy the change to a staging environment. The agent investigates the code, delegates a test run, and submits a deployment job. The deployment service accepts the job and places it in a queue.

Then the engineer notices that the agent selected the wrong environment configuration and presses stop. The agent stops producing output. Its active process terminates. The interface marks the task canceled. Thirty seconds later, the deployment job starts.

Nothing in this scenario requires the agent to resist the user. The deployment service already accepted the request and runs under its own identity. Unless cancellation reaches that service and prevents the queued job from executing, the original task can still produce an effect after the agent has stopped.

Revoking the agent's credential may prevent another request. It does not necessarily withdraw a request that another system has already accepted.

This is a familiar distributed-systems problem. Agents make it a product problem for everyone who can now initiate that kind of workflow through a sentence. The user sees one task. Underneath it, several systems may hold separate pieces of work.

The product has to reconcile those two views.

Authority has a lifetime

There is current work behind this question.

On September 29, NIST announced that its DevSecOps project would provide the first implementation use case for its work on software and AI agent identity and authorization. That places the question directly inside the development lifecycle. NIST announcement

The accompanying public-comment summary identifies a need to preserve authorization through delegation, support revocation, and account for policy changes during long-running work. It also describes unresolved implementation questions. This is an evolving program of work, not a finished standard that enterprises can claim to have implemented. NIST feedback summary

A September research preprint examines the narrower problem of revocation across delegated and asynchronous agent execution. It distinguishes ending a process from establishing that work can no longer proceed under withdrawn authority. Its proposed guarantees depend on explicit assumptions and a defined set of participating systems. They do not establish universal cancellation or undo completed effects. Authorization Revocation for Long-Running AI Agents

The distinction matters for product requirements. Permission has to remain meaningful after the initial approval, including when the user changes their mind.

“Stopped” needs acceptance criteria

I would start by defining what the product promises when someone presses stop.

Does it prevent the agent from initiating more actions? Does it attempt to cancel everything associated with the task? Which downstream systems support that cancellation? What happens when one of them is unavailable?

Some operations will already have completed. Others may need to reach a safe stopping point. An external service may accept a cancellation request without immediately confirming the outcome.

Those conditions belong in the design. They determine what the interface can honestly tell the user.

For the staging example, a useful status might read:

“Agent stopped. Test worker canceled. Deployment cancellation requested; confirmation pending.”

That gives the engineer a reason to keep watching. Calling the entire task canceled would remove that signal while the consequential part remained unresolved.

I would also distinguish preventing further work from recovery. A deployment that already happened may require a rollback. A record that changed may require correction. Information already delivered to another party cannot be made undisclosed by ending the session.

Recovery needs its own scope and authorization. An agent should not interpret a stop request as permission to improvise an unlimited cleanup operation.

Test the moment after cancellation

The exercise I would run is small enough to fit into an existing release review.

Choose a representative workflow in a controlled environment. Let it reach the point where another system has accepted work. Then cancel it.

Have the product owner, an engineer, and a security owner examine the same run:

Which actions completed before cancellation? Which pending actions were prevented, and what confirms that? Which credentials or delegated permissions remain usable? Can a delayed callback, retry, or restarted worker continue the canceled task? What remains uncertain, and who is responsible for resolving it?

Repeat the exercise while a downstream service is temporarily unreachable. A control that works only when every participant responds immediately leaves an important part of the promise untested.

Record when the user requested cancellation and when each consequential system enforced it. The interval between those events is an exposure the team can measure and reduce.

The evidence should come from the systems performing the work. A final message from the agent saying it stopped is useful communication. The deployment service's record of what it accepted, canceled, or executed is what lets a reviewer check the claim.

Be explicit about coverage. If the team can verify three integrations but cannot inspect the fourth, the result has a known gap. Preserve that uncertainty in the status until someone can resolve it.

Someone owns the unfinished state

This is where the responsibilities become concrete.

The PM defines what stopping means to the user, including what remains visible when cancellation is incomplete. Engineering implements the behavior across the workflow. Security and system owners determine how authority is withdrawn. Independent verification tests those claims against actual effects.

The team also needs to name who handles a task that is neither safely running nor confirmed stopped. Otherwise, the agent disappears from the screen and the unfinished work disappears from ownership.

Resuming deserves the same attention. Before restarting, establish what already happened, what still needs doing, and which permissions remain appropriate. Repeating the original request can duplicate an effect that succeeded before cancellation but had not yet reported back.

The product should help the operator make that decision from the recorded state of the work.

I have argued throughout this series that agentic development has to produce evidence that our intent was respected. Withdrawing intent belongs inside that requirement.

The next acceptance test is straightforward: let the agent begin a consequential workflow, stop it midway, and account for what happens afterward.

This belongs inside the Agentic Development Life Cycle (ADLC). In my book, Product Management in the Agentic Era, I frame the work as a loop: Intent, Build, Evidence, Decision. A decision to stop has to travel back through what was built, withdraw the relevant authority, and produce evidence of what actually stopped. Cancellation deserves acceptance criteria as concrete as the original task.

Explore the book and read a free sample.

Keep the test open until the downstream systems have answered.