Request Agent Approval Changes
POST /agent/approvals/{approval_id}/request-changes
Send the agent back to replan, with a reason. THIS REJECTS THE PROPOSAL.
Not a “hold” and not a comment: the current proposal is rejected
ATOMICALLY, and the feedback is stored alongside so the next plan is
informed rather than identical. If you want the plan to proceed, use
POST /agent/approvals/{approval_id}/decide.
It FAILS CLOSED on both halves. A deployment that does not have this route 404s rather than doing something approximate, and a worker that does not understand the stored feedback still reads the row as a rejection. There is no version of “older software saw this as approval”.
Once decided, an approval cannot be decided again - the winner is settled server-side, so a second call gets 409 rather than overwriting.
Authorizations
Parameters
Path Parameters
Approval id (UUID).
Approval id (UUID).
Header Parameters
Request Body required
Mirror of RequestChangesBody.
object
Why the proposal is wrong, and what to do instead. REQUIRED and not decoration: it is stored on the rejection and is what the next plan is built from, so an empty-handed rejection produces the same plan again.
Responses
200
Successful Response
object
An open envelope for one approval answer.
Open because an approval carries the plan digest it is bound to, its expiry and its provenance receipts, and that set has grown twice already. On a human-in-the-loop surface a dropped field is a guarantee the caller does not know they lost.
object
object
Whether there are more pages
Items per page
Current page number (1-indexed)
Total number of items
422
Validation Error