Guardrails and AI Safety
Human Approval Gates — Stack
Human approval gates › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
Two components are being chosen and they have almost nothing in common: something that holds a suspended computation durably, and something that puts a decision in front of a person.
- Suspension durability. Whether a pending item survives a deployment, a crash, and a region failover without special handling.
- Resume fidelity. Whether execution continues with exactly the state captured at suspension, including the arguments and the versions in force.
- Hold duration. The longest a run can be suspended before the mechanism's own limits — token expiry, workflow history size, retention — become the constraint.
- Idempotence support. Whether the engine provides execution identity so a resumed step cannot repeat a completed effect.
- Approver identity. Whether the responder is authenticated as a specific person rather than as whoever holds the channel.
- Payload fidelity in the interface. Whether the surface can display the exact executable payload rather than a summary generated from it.
- Timeout and escalation primitives. Whether deadlines, reminders, and escalation are supplied or have to be built from timers.
- Record export. Whether decisions land somewhere with retention that matches the obligation rather than a chat history with a ninety-day limit.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Durable execution engines (Temporal, Restate, Azure Durable Functions, AWS Step Functions) | Multi-step runs that must survive restarts with exact resume semantics and built-in idempotence | A substantial architectural commitment; long waits grow execution history, and versioning a workflow mid-flight is its own discipline |
| Queue plus an explicit state machine in your own database | Teams wanting durability without adopting an orchestration platform | Everything the engines provide — timers, retries, idempotence, versioning — is now yours to get right |
| Chat-platform interactive messages (Slack, Microsoft Teams) | Reaching approvers where they already are, with the lowest friction per decision | Group identity rather than personal, limited payload rendering, platform retention, and anyone in the channel can press the button |
| Ticketing and service-management systems (Jira, ServiceNow) | Organisations with existing approval governance, rotas, and audit expectations | Latency measured in hours or days, which forces the hold duration question immediately |
| Purpose-built review consoles in the product | Showing the exact payload, the context, and the risk valuation together, with a real audit trail | Something nobody is on call for; an internal tool without alerting becomes a queue nobody opens |
| Email and webhook callbacks | Simple approvals and external approvers who have no account in your systems | Weak identity, replayable links, and no way to withdraw a request once sent |
| Identity platforms with step-up authentication | Making the approver prove who they are at the moment of the decision | Adds friction exactly where fatigue is already the problem, so it belongs on the high-value tail only |