Guides
Reviewing approvals
When an agent wants to do something with a side effect, it pauses and asks. The Approval Centre is where a person reviews that request and decides. This is the heartbeat of SyftOS, so it's worth knowing exactly what happens when you approve or reject.
The Approval Centre
Open Approvals. Pending requests are listed oldest-first, so nothing waits behind newer work. You can filter by status, risk level, the agent that raised it, or how long it's been waiting.
Open a request and you see everything you need to judge it:
- A plain-English summary of the action.
- The tool and the exact arguments that will run, with sensitive fields redacted, never truncated.
- A risk level (low, medium or high).
- Which agent and version proposed it, its objective, and who started the run.
- The agent's reasoning for choosing this action, so the decision isn't a black box.
Approve or reject
Approve and the exact action you reviewed runs. SyftOS first confirms the request hasn't changed since you looked, then executes it and the run carries on from where it paused, with the result in hand. Approving is the action happening; it doesn't sit in a second queue.
Reject and you're asked for a reason (it's required). Here's the important part: rejecting does not fail the run. The agent is told its proposal was declined, along with your note, and can adapt — propose a different action, ask for clarification, or wrap up with what it already has. You're steering the worker, not killing its work.
Waiting & expiry
A paused run waits as long as it needs to — there's no rush to decide. Each request does carry an expiry, though (24 hours by default, and the agent's owner can set anything from 1 hour to 7 days). What happens when it lapses depends on the agent's policy:
- Decline: the request expires, the action is declined, and the run resumes and adapts, just as with a manual rejection.
- Escalate: a fresh request is raised to owners and admins for a decision, and the original reviewers are told it's been escalated.
Deciding in bulk
When a queue builds up, you can approve or reject many requests at once with a single shared reason (up to 100 at a time). Each one is still checked individually, with your permission and any segregation rule applied per request. And high-risk requests are never swept through in bulk; decide those one by one.
Who can decide
Deciding requires the approvals permission, which Owners, Admins and Approvers hold. Agents never can — that lock is structural.
If segregation of duties is on (Settings → Organisation, on by default), the person who started a run can't approve that run's actions: the decision controls are hidden for them, with an explanation, though they can still see the request. That keeps a genuine second pair of eyes on every action. See Members & roles.
Being notified
The moment a request needs a decision, the people who can decide it are alerted: in-app always, and by email, Slack or webhook where your organisation has enabled the channel and you've opted in. You are also alerted if a request lapses unattended, so nothing falls silently through the cracks.