A gate is a checkpoint. When something needs a human’s say-so before it happens, the work pauses at the gate and waits. Nothing moves until the right person approves it.
This is how the AI stays within bounds and how your partners keep control. The system can propose a sensitive change, but it cannot carry that change out on its own. A person reviews exactly what is about to happen, then approves or rejects it. Only on approval does the change take effect, and every step is recorded.
What it does
It stages the change, not just the request. When a gate is proposed, the actual change is captured and held in a PENDING state. The gate is not a vague “please can I?” note - it carries the precise action that will run if approved.
It waits. A pending gate sits in the approval queue until a reviewer acts on it. Until then, nothing happens. There is no quiet timeout that lets the change slip through, and no back door that runs it without a decision.
A person approves or rejects. A reviewer with the right authority looks at the proposed change and either approves it or rejects it. A rejection is final and records who rejected it and why, so the trail is clear.
Approved means applied, faithfully. When an approved gate is applied, the staged change you reviewed is the change that runs. The system replays the exact action that was captured at propose time, so what gets approved is what gets done. The apply is fail-closed: if the gate is no longer in a clean, approved state at the moment it runs - already applied, already rejected, or changed underneath - it refuses rather than guessing. One approval can only ever apply once.
The AI uses gates for anything above its ceiling. Every agent runs with an authority ceiling. When the AI wants to do something above that line - a sensitive write, a step a partner asked to sign off on - it does not force it through. It proposes a gate and hands the decision to a person. The gate is the seam where autonomy stops and a human picks up.
Review policies decide what needs a gate. You do not have to mark every action by hand. A workspace’s review policy describes which kinds of work route into review and which lanes they land in - identity changes, autonomy escalations, general human triage. Set the policy once and the right things start arriving in the queue automatically.
An applied change can be cleanly undone. If an approved-and-applied gate needs to be reversed, the system restores the before-state it saved when the change was applied - the same governed, recorded path, not a manual unpick.
How you use it
See what is waiting. Open the approvals queue to see every pending gate: who proposed it, what it would do, which lane it sits in, and how long it has been waiting. The queue groups work by lane so a reviewer sees their own pile, not everyone’s.
Approve or reject. Pick a gate, read the proposed change, and decide. Approve it to let it proceed, or reject it with a reason. Both are deliberate, confirmed actions - there is no single-click way to wave something through or throw it away.
The change applies. Once a gate is approved and applied, the staged action runs and the work moves on. You see the result in the same place, and the full history - proposed, approved, applied - stays attached to the gate.
The agent proposes when it needs you. You rarely create gates by hand. The AI raises them as it works: when it reaches something above its ceiling or something your policy routes to review, a gate appears in the queue and waits for a person. Your job is to decide, not to chase.
The kernel verbs behind it
Every one of these goes through the one front door - permission-checked and audited before it runs (see Security & permissions). These are the verbs most specific to approvals and gates; the full set is in the Verb reference.
gate.propose- stage a change as a gate; it enters the queue inPENDINGand waits for a human.gate.list- see the pending gates, filtered by state, category, requester, or reviewer.gate.get- open one gate with its proposed change and full history.gate.apply- replay the approved change; fail-closed if the gate is not cleanly approved, and applies at most once.gate.reject- turn a pending gate down, recording who and why.gate.revert- cleanly undo an applied gate by restoring the saved before-state.review.open- put an item into a review lane for a human to pick up.review.claim- take ownership of a review so it is clearly yours.review.resolve- close out a review once it has been actioned.review.list- see the queue by lane, with aging and SLA, for the ops view.review.policy.set- configure which work routes to review, lane by lane.review.policy.get- read the current review policy for the workspace.