Key facts
| Risk tiers | Read, reversible write, irreversible, financial, administrative |
| Pause and resume | Persist run state at the approval point and continue after a decision |
| Approval context | Exact tool, arguments, target record and expected effect |
| Identity | Approver identity, timestamp and channel recorded |
| Idempotency | Approved actions execute once, even across retries |
| Expiry | Unapproved requests time out instead of executing later |
| Audit | Approval and rejection decisions are first-class events |
| Status | Function calling, streaming and audit logging are live |
TL;DR
- Approve by risk tier, not everything: most steps should run without a human.
- Pause and resume requires durable run state, not a sleeping process.
- Show the exact arguments and target, or the approval is meaningless.
- Approvals must expire and must be idempotent when executed.
- Log who approved what and when, and review the queue regularly.
How it works, step by step
- Classify every tool action into risk tiers from read-only to administrative.
- Let read and reversible actions run automatically, and require approval above your threshold.
- Persist the full run state when the agent reaches an approval point.
- Present the approver with the tool, the exact arguments, the target and the expected effect.
- Record the decision with identity and timestamp, then resume or terminate the run.
- Execute approved actions exactly once with an idempotency key.
- Monitor approval volume and latency; if reviewers rubber-stamp, tighten upstream controls.
Try it yourself
Open the agent workflow designer →
Approval is a control, not a dialog
A confirmation prompt in the chat UI is not a control. Controls are enforced in code, cannot be bypassed by a prompt, and leave a record. Human approval becomes real when the agent's run is genuinely blocked until a named identity authorizes the next action, and when the execution path cannot proceed without that authorization.
That framing stops the common mistake of asking users to approve prose. Approvals should be about concrete actions: this refund of this amount to this account, this record deletion, this outbound email. The approver reviews a proposal with exact arguments, not a summary the model wrote about itself.
Designing the pause-and-resume flow
- Checkpoint: persist messages, completed steps and pending action before pausing.
- Proposal: render the pending tool call as a structured request with arguments and impact.
- Queue: route it to the right approver or role, with an SLA and an expiry.
- Decision: approve, reject with a reason, or edit parameters and approve.
- Resume: continue from the checkpoint with an idempotency key per approved action.
- Audit: store both the proposal and the decision as immutable events.
Rejections should teach the agent something: pass the reason back so the run can propose a corrected action rather than failing uselessly.
Keeping approvals fast enough to use
The operational risk of approval workflows is that they become bottlenecks or rubber stamps. Two tactics keep them effective. First, tier by risk so routine work never queues. Second, measure approval latency and override rates; if reviewers approve 99 percent of requests in two seconds, the control has degenerated and the real fix is upstream — tighter tool permissions or better evaluation.
Plugsky supports the mechanics with live function calling and audit logging, plus scoped keys and RBAC so approvers and agents have separate identities. Deployment options range from the shared cloud to VPC, on-prem and air-gapped for regulated environments. 30+ models are available behind one OpenAI-compatible API, so you can run planning on a frontier model and routine steps on plugsky-micro or plugsky-lite. Plans are on the live pricing page.
Honest comparison
| Action type | Example | Control | Reversible? |
|---|---|---|---|
| Read | Look up an order | Scoped read access | Yes |
| Reversible write | Draft a note, tag a record | Automatic with logging | Yes |
| Irreversible write | Send email, delete file | Human approval | No |
| Financial | Refund, purchase, payout | Approval plus limits | Rarely |
| Administrative | Change permissions, rotate keys | Two-person approval | No |
Frequently asked questions
Is a confirmation button enough?
No. The control must be enforced in code so the action cannot proceed without a recorded authorization, and the approver must see the concrete action rather than a model-written summary.
How do I resume a paused agent?
Persist the run state at the checkpoint, then restart the loop from that point after the decision, using an idempotency key so the approved action executes exactly once.
Should every action need approval?
No. Approve only actions above your risk threshold. Requiring approval for everything creates fatigue, delays and rubber-stamping, which is worse than no control.
What if nobody approves?
Expire the request after an SLA and fail the run cleanly, notifying the requester. Never hold pending actions indefinitely where they might execute stale.
Who should be the approver?
The person accountable for the outcome, with the authority to authorize it. For financial actions, use a role rather than an individual and consider a two-person rule.
How do approvals appear in audits?
As first-class events with approver identity, timestamp, channel, the exact proposal and the decision. On Plugsky, audit logging for API calls is live.
Can this work in an air-gapped environment?
Yes. Approval queues can run on your own infrastructure while the model endpoint runs on-prem or air-gapped, so the entire review loop stays inside your boundary.