How to Cancel an Approved AI Agent API Write Before Execution

The direct answer

An approved AI-agent API write can be cancelled only if execution has not claimed it yet. In ActionDock, a signed-in workspace owner can open the approved integration.execute job in Workflows and jobs, select Revoke queued approval, and confirm. If the job is still queued, revocation makes it terminally rejected before ActionDock sends the external write. If a worker has already claimed the job, the action returns 409 invalid_job_state: revocation cannot stop a running request or undo a provider-side change.

The window may be very short. Approval queues the job for execution immediately; ActionDock does not promise a review grace period after the owner clicks approve. If you need a business deadline, set it on the original proposal rather than relying on someone noticing a queued job in time. See approval deadlines for stale API writes.

Why cancel after approval?

Approval answers whether the owner authorized a specific request at a specific moment. It does not freeze the business world. Imagine an agent prepares an approved PATCH to release an inventory hold. Before the queued job executes, the team learns that the inventory is needed for another order. The owner now wants the already-approved change not to happen.

This is not a reason to let the agent alter the payload or to erase the approval record. It is a new owner decision about whether the original write may still start. A pre-execution revoke closes that job while preserving the original request and decision for audit.

Other systems also separate pending work from work already under way. GitHub, for example, lets reviewers reject a pending deployment, causing its workflow to fail. That is an analogy about the importance of a state boundary, not an ActionDock integration or a claim that all queues share the same cancellation behavior.

Use the right action for the job’s current state

The ActionDock dashboard exposes the revoke control only for an approved queued integration.execute write. Its owner-session endpoint is POST /v1/dashboard/jobs/{id}/revoke; it is not an agent API-key capability. This matters: the agent that proposed the side effect cannot silently revoke the owner’s approval in its own loop. The agent integration guide describes the current approval and job states, and human-in-the-loop approval explains why exact-request review comes before a write.

What a successful revoke proves

When the queued-state check wins, ActionDock returns HTTP 200 with a rejected job. It retains the original input, approval preview, approving owner and time, then records the rejecting owner, time, and explanation. Reserved capacity is released, one durable job.rejected event is recorded, and terminal callback delivery is queued if the workspace has configured it.

Repeating the revoke request for that same successfully revoked job returns the same terminal job rather than a second rejection event. Repeating the original agent submission with the same idempotency key likewise returns the existing rejected job; it does not restart the write. The agent should treat rejected as terminal even though the job has an earlier approval timestamp. To attempt the operation later, it must create a fresh proposal with a new idempotency key and get a new owner approval. See AI-agent API retries and idempotency for the distinction between resending a submission and creating a new operation.

Successful revocation proves this ActionDock job was stopped before its worker claimed execution. It does not prove that some separate agent, browser, shell command, or direct provider credential could not make a similar change outside ActionDock. The boundary applies to writes routed through the ActionDock gateway.

What a 409 means in the execution race

Queue cancellation and worker execution compete for the same job. ActionDock resolves the race atomically: either revocation changes the still-queued job to rejected, or the worker claims it as running and revocation returns 409 invalid_job_state. There is no state in which a successful revocation also lets that job be claimed for the external send.

Do not interpret a 409 as proof that the provider changed its data. It means the pre-execution revocation window has closed. The worker may still be connecting, waiting for a response, or recording an outcome. Refresh the owner’s dashboard, or have the agent read the current job with GET /v1/jobs/{id} or get_job, then wait for its terminal state. If it becomes execution_unknown, stop automatic retries and inspect the provider’s system of record. A new idempotency key is a new possible write, not a safe way to “retry the cancel.”

This distinction extends beyond ActionDock. AWS documents that stopping a durable execution does not necessarily stop a currently running Lambda invocation or roll back side effects. Treat cancellation claims as state-specific; after a request may have been sent, recovery requires provider evidence rather than a UI label.

A short operating procedure

1. Locate the exact job. Match its ID, connection, request preview, and status in Workflows and jobs. Do not cancel by a similar-looking resource name alone.
2. If it is still awaiting approval, reject it. Revocation is for a write that the owner has already approved and that remains queued.
3. If it is queued, revoke immediately. Choose Revoke queued approval and then Confirm revocation. Record the returned job ID and terminal status.
4. If revocation returns 409, follow the existing job. Do not submit a replacement while it is running; inspect the eventual receipt and the provider state.
5. If the provider outcome is unknown, reconcile before writing again. Keep the original job and key as evidence. The unknown-outcome retry guide gives a read-first checklist.
6. If the business change is still needed, start anew. Re-read the target, prepare an updated request, use a new idempotency key, and ask the owner to approve the new exact preview. For a time-sensitive operation, include an executeBefore deadline in that new proposal.

For teams testing this workflow, exercise both sides of the race: revoke a queued write and confirm no external send, then let a worker claim a write and confirm revocation is refused. Verify the retained preview, one rejection event, and callback behavior only when callbacks are enabled. The preproduction AI-agent write checklist covers the wider safety boundary.

The boundary to remember

“Approved” is not the same as “already executed.” A queued ActionDock write can still be rejected by its owner. Once execution claims it, the owner must manage the real outcome rather than assume a cancellation can pull back an in-flight API call. That is why a reliable agent loop checks the job’s current state, preserves the original approval and rejection evidence, and never treats an uncertain provider result as permission for a blind replay.