An agent can receive a successful HTTP response and still leave the wrong state behind. A quota race, partial batch update, stale identifier, or upstream inconsistency can turn a claimed success into an operational incident. The right response begins with evidence, not guesswork.
1. Read the verification result
Check the post-condition proof captured after execution. Pakkawork distinguishes verified, mismatched, and unchecked outcomes. A mismatch states what the verifier expected and what the Google API returned, so the team does not debug from the model's narrative.
2. Reconstruct the exact action
- Identify the agent, principal, tenant, and Google connection.
- Inspect the pinned contract id, version, and content hash.
- Review the validated arguments and policy decision.
- Follow the signed ledger sequence through approval, execution, and verification.
3. Compensate or isolate
If the contract is reversible and the allowed rollback window is still open, run the captured compensation through the same policy gate. If rollback is unsafe, suspend the agent or revoke the connection, place failed work in the dead-letter queue, and open an incident with an explicit reporting clock.
4. Replay with a pin
A replay should use the original contract versions and description pins, not whatever happens to be latest. Pakkawork keeps trajectories and steps so a team can resume from a safe point without repeating already verified side effects.
Frequently asked
Does Pakkawork automatically report every 2xx response as success?
No. Where a verifier exists, the intended state is read back. A mismatch is returned instead of a false success.
Can a failed agent action always be undone?
No. Only contracts with a registered inverse are reversible. Pakkawork records that boundary before execution and does not pretend an irreversible action can be rolled back.