Approvals & oversight
Human gates pause a run at a checkpoint and wait for a human decision before the next step runs. They're set up during team creation and enforced at runtime — your team doesn't need to do anything extra to activate them.
What is a human gate?
Most AI team runs start-to-finish without interruption. Human gates let you build in structured pause points — moments where output from an earlier step is reviewed, approved, or corrected before the run continues.
A gate sits after a specific step. When that step completes, the run halts and Envelope queues the pending items for review. Once the trigger condition is met — some records approved, all resolved, or a threshold reached — the gate clears and the next step runs automatically.
Common uses
- Review AI-generated content before it's sent to a customer
- Approve or reject proposed actions before they execute
- Classify or triage items from an earlier research step
- Add a human-in-the-loop before high-stakes actions
Gate types
The gate type controls how the review is presented in your workspace. Pick the type that best matches what reviewers are being asked to evaluate.
Content generation — The agent wrote something — an email, message, document, or summary — and a human should read and approve it before it's sent or used downstream.
Decision — The agent made a recommendation or proposed an action. The reviewer approves or rejects the proposed course of action.
Classification — The agent categorised or scored records. The reviewer validates or corrects the classification before it propagates.
Action — The agent is about to take an irreversible action — sending a request, modifying a record, calling an external service. The gate requires explicit approval before the action executes.
Triggers
The trigger controls when the gate clears and the run resumes. Choose based on how much human review is required before it's safe to proceed.
Any approved — The gate clears as soon as a single record is approved. Good for teams that process records independently and should continue without waiting for full review.
All resolved — Every record must be either approved or rejected before the gate clears. Use this when the next step depends on the complete reviewed set.
Threshold — A configurable minimum number of approvals is required. Useful for vote-style review where a quorum is enough to proceed.
Scheduled — The gate clears at the next scheduled run interval, regardless of how many records have been reviewed. Lets time-boxed review cycles integrate naturally with scheduled runs.
Rejection paths
When a reviewer rejects a record, the rejection path determines what happens next. The right choice depends on whether the failure is recoverable and what the best next action is.
Skip — The rejected record is dropped and the run continues without it. Use when the record isn't critical and failing fast is preferable to retrying.
Rerun — The reviewer can add a rejection note explaining what was wrong. The step that produced this record is re-run with the note as additional context — creating a human-guided feedback loop. This is the most powerful path for improving output quality iteratively.
Escalate — The record is flagged for escalation and paused. A secondary reviewer or administrator is notified. Use when the primary reviewer doesn't have authority to make the final call.
Halt — The entire run is stopped. Use when a rejected record indicates a fundamental problem that makes continuing the run unsafe or incorrect.
Reviewing in your workspace
When a gate triggers, the run pauses and an amber card appears inline in the room thread. The card shows the content waiting for review and an Approve & continue button. Click Read full output to expand the full output before deciding.
Press Approve & continue to release the gate and let the run proceed. If you want to decline or flag an issue, describe it in the thread — the assistant can help re-run the step with corrected context or halt the run.
Anyone in the room thread can handle the review.
Proactive teams and autonomous action
When a team uses an event or condition trigger, runs can appear in the thread without you initiating them. Gate configuration determines what happens after the run fires — the trigger type does not change the action authority model.
A proactive team with no gates runs fully autonomously — it observes, decides, and acts without any human checkpoint. This is a legitimate and useful configuration for low-risk, reversible actions (posting a Slack message, logging a record, sending an internal digest). For higher-stakes actions — sending external emails, modifying records, making purchases — you should add a gate before the action step.
The team editor shows a reminder when saving a proactive team with no gates configured. It is not a blocker — just an explicit acknowledgement that the agent will act without approval when triggered.