Why approval gates matter
Approval gates are one of the clearest proven parts of the product's safe-by-default model. They let a run pause before a live write so a human can review the proposed action.
That review point matters most when the agent touches external systems. It gives you a way to prove the workflow in real conditions without pretending the agent should run fully unsupervised on day one.
Configuration steps
1. Start with approval mode for write steps
The safest first launch is to keep any external write in approval mode. That means the run can pause before the write and wait for a human decision.
Read-only or low-risk steps can often stay outside that path, but live writes are where approval matters most.
2. Review the plan before deploy
The builder already gives you the right place to catch approval issues early. Review the generated plan and any connected-app requirements before you launch the agent.
3. Watch for runs awaiting approval
When a live run reaches an approval checkpoint, the run can move into an `awaiting_approval` state. That is the signal that the workflow is waiting for a human decision before it can continue.
4. Review and decide from the approval surfaces
The current product truth supports reviewing pending approvals in the app and deciding whether to approve or reject the proposed write.
Approve when the proposed action matches the workflow you intended. Reject when the plan is wrong, the context is wrong, or the write should not happen.
5. Use rejection as a workflow correction point
If you reject an approval, the waiting run should finish without applying the proposed write. That makes rejection a useful signal that the agent still needs a tighter prompt, narrower permissions, or a narrower job boundary.
6. Keep the public claim boundary precise
Avoid claiming routed approvals by role, timed escalations, or bulk approval unless those exact user-facing behaviors are separately proven. The current safe claim is approval mode, pending approvals, and approve or reject decisions in the app.
What happens at each stage
| Stage | What to look for | Safe takeaway |
|---|---|---|
| Build review | Write steps, approval-required steps, rule warnings | Catch approval needs before deployment |
| Live run | Run enters awaiting-approval | The workflow is paused and waiting for a decision |
| Pending approval | Proposed action details in the approval surfaces | Review before the write continues |
| Approved | Approval recorded | The waiting run can continue from that checkpoint |
| Rejected | Approval recorded as rejected | The waiting run finishes without applying the proposed write |
Best practices
- Start with approval mode on external writes.That is the safest first-launch posture.
- Review the plan before deploy. Approval issues are easier to fix at plan time than after a live run.
- Use the awaiting-approval state as a signal.It tells you exactly when a run is paused and needs a decision.
- Treat rejection as feedback. A rejected write usually means the workflow still needs narrowing.
- Do not overclaim approval behavior. Stay with the product truth the app currently proves.
Frequently asked questions
Should write actions start in approval mode?
Yes. The safest first launch is to keep external write steps in approval mode so the agent shows what it wants to do before the run continues.
Where do pending approvals show up?
The current product truth is that runs can enter an awaiting-approval state and pending approvals can be reviewed from the approval surfaces in the app.
What happens when I approve or reject a pending approval?
Approving lets the waiting run continue. Rejecting ends the waiting run without applying the proposed write. Keep that decision point in place while the workflow is still proving itself.
What is the safe public claim today?
Keep the public claim narrow: protected actions can stay in approval mode, runs can pause in awaiting-approval, and a person can approve or reject the proposed action in the app.