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 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.

A phase that changed a wiki or Assets folder kept outside the repository lists those files under the gate's sentence: approving saves them. Open one to see it — a page rendered, a picture drawn — and a Changes tab with what changed in its text, with every other file it changed beside it. See Storage.

Actions that wait for you

When a run's agent calls a tool set to Waits for a person on one of your organization's MCP servers, the call doesn't happen. That might be sharing a file, sending a campaign or changing a record. The agent is told the call waits and carries on. The phase ends on a review of what it held, even without a gate, and the run says N actions wait for you, naming the services.

Review N actions shows each one: its service, its tool, and what the agent asked for, as a form you can change.
Discard throws one away. The others still apply.
Approve and apply applies them in order, as your organization, and advances the run. The next phase is told what each one answered.
Request changes runs the phase again. A call that went through at once (Live) already happened, and running the phase again doesn't undo it: the agent is told what the earlier attempts' Live calls did and what each service answered, so it builds on them instead of making them twice.

When the phase also held a draft or a plan, its actions are in that draft's or plan's review, under Held actions, with the same forms and Discard. The one button does both: Approve, send and apply 2 actions, or Approve, file 3 tasks and apply 1 action.

Approving them needs Act on connected services from runs. Without it you can still change or discard them: Save changes keeps what you changed, and somebody who holds it approves. The draft's or plan's own Discard waits for them too, since discarding it would decide the actions for them.

Who may approve

By default, any member of your organization who can see the project. 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
      - { role: [release-managers] } # anyone holding one of these roles
      - 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 your own organization's roles and people, for GitHub, GitLab, Linear, Jira, and Notion identities, for repository collaborator permission levels, and for the tracker's assignee or team. A role: rule names roles by id or by name, and everyone means every member; whoever holds the role when the gate is decided may approve. The Reviewers section picks roles and people for you.

Whoever approves also needs View project in the run's project, which every member holds unless your organization changed Everyone or the project is private. When the run worked with restricted folders or files, they need to be able to open those too, to approve or to send it back: "Approving needs access to the files this run worked with." The rules decide who approves a phase's finished work. Request changes, and Approve on a failed phase, which only retries it, act on the run instead: they take Start runs on your own run and Manage runs on somebody else's, unless the rules name you. A phase that sends mail or books an event a run drafted asks more of whoever approves it: their own connected mailbox, Send mail from runs, and Invite people outside for an event with people outside the organization — and it is approved in Peractor by a person, never by the assistant's Auto mode or a connected MCP client (see mail and calendar steps). The old admin and group: rules are gone: a workflow that names either is refused, with a pointer to role:.

Apart from role and 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.

In the app, a parked gate reaches whoever started the run and the people its approver rules name — everyone holding a named role, and the named people. When the rules name nobody in your organization, it reaches the people with Manage runs in that project instead. Nobody hears about a gate in a project they can't see, or on a run that worked with files they can't open.