The running release identifier after the rollback.
Workflows · Production rollbacks
The service owner confirms both releases before rollback.
CC8.1 evidence for a rollback: both releases, the named approver and reason, and the running release read back.
Example workflow. Execution requires a configured tool with provider permissions for this action; see the connection’s operation reference or bring your company tool to the demo.
Agent request
Roll the checkout service back from release 2026.08.28 to 2026.08.27
The rollback replaces the running release and can restore behavior with an older data contract.
- Identity
- recovery-agent · Reliability
- Target
- production/checkout
- Cost
- Recorded agent cost
- Evidence
- Current release, rollback target, and compatibility checks
SOC 2 CC8.1
Sensitive: waits for a named approver.
The two releases, the compatibility checks, the Checkout owner's reason, the running release after the rollback, and the CC8.1 test it supports.
Policy decision
Production rollbacks require the Checkout service owner.
Checkout service owner
The action waits until this owner approves or denies it.
Tool call resumes
The deployment tool starts the approved rollback and records the completed result.
Tool call stays blocked
The running release stays unchanged and the rollback request closes as denied.
Execution order
The agent request stops before the connected tool runs.
- 01Recovery agent requests the rollback
- 02Deixic checks the service, releases, evidence, and policy
- 03Checkout service owner decides
- 04Connected deployment tool returns the rollback result
- 05Deixic reads the result back and attaches the receipt to the test
Activity history keeps the request, decision, cost, and result.
Keep the procedure for the next request.
Keep the policy and decision history, save the steps and evidence as a skill, and test changes on real sessions; an approval stays specific to its request.