Agent workspace on Workers · early access
Walk away.
Come back to a queue,
not a stall.
When an agent wants to take an action with side effects, a Gatekeeper simulates the outcome locally and lets it keep going. You approve or reject the queued actions later — in bulk, or one by one — when it is convenient for you, not when the agent hits step one.
“People often give in and set their agents to ‘auto-approve’ … which is, obviously, unsafe.”
— the README, on why people switch approvals off
Same task, two approval models
“Make an issue dashboard for this GitHub repo.”Synchronous approval
you went for coffee- 01Read open issuesdone
- 02Build dashboard gadgetdone
- 03Label stale issueswaiting for you
- 04Post summary commentnot started
- 05Read back labelsnot started
With a Gatekeeper
same coffee- 01Read open issuesdone
- 02Build dashboard gadgetdone
- 03Label stale issuessimulated · queued
- 04Post summary commentsimulated · queued
- 05Read back labelssimulated result
Steps are illustrative; the mechanism is the project’s. If the agent reads back a result before you approve, the Gatekeeper answers with the simulated one.
It kind of is an operating system
the project’s own mapping, one row left open“AI agents cannot simply be treated as users. They must be accountable to a human user, while at the same time having their own restricted permissions.”
The last row is the argument. A traditional OS has nothing in the left column for an agent, so the project leaves it as ??? rather than pretending an existing primitive fits.