Gates & reviews

The checkpoint between phases: approve to advance, or send the work back with a note.


Between phases, a run stops at a gate and waits for a person. That is the core safety property: the agent never advances past a phase you have not seen.

A run parked at a gate holds nothing — no process, no container — so it can wait for an hour or a fortnight without costing anything or taking a slot.

Approve or request changes

At a gate you see the phase's full output: the transcript, the diffs, check results, published artifacts. Then two buttons:

  • Approve — the run advances to the next phase.
  • Request changes — your note goes back as feedback. The agent reworks the same phase on the same branch and returns to the gate.

The same review works everywhere: the editor's live session, the run's page in a browser, the Mac app, the desktop app, and your phone — with a push notification the moment a run parks.

A failed phase parks at its gate too. Approve retries it; Request changes sends it back with instructions.

Who may approve

By default, any signed-in member of your organization. A phase can narrow that, in the workflow editor's Reviewers section or in YAML:

phases:
  - id: coding
    gate: true
    approvers:                       # any-of: match one rule and you may approve
      - admin                        # Peractor organization admins
      - { member: [ana@acme.com] }   # named people in your organization
      - codeowners                   # owners from the repo's CODEOWNERS
      - { github: [alice, org/reviewers] }
      - { repo: write }              # collaborators at write or above
      - { tracker: assignee }        # the issue's assignee
    self: deny                       # four eyes: authors can't approve their own work

Rules exist for named members of your own organization, for GitHub, GitLab, Linear, Jira, and Notion identities, for repository collaborator permission levels, and for the tracker's assignee or team.

Apart from member, approval reuses the reviewer's external identity — the account they signed in with — so policies name people you already know, and a reviewer only matches rules from their own provider.

Peractor's gate advances the workflow. A merge step still goes through your git host, so branch protection and required pull request reviews keep applying on top.

Never miss one

Notifiers announce every gate in your team's channels, phones get push, and a self-hosted server can re-send a reminder for gates left waiting.

Related: Code review · Mid-run questions · Talking to a running step