Real access.Your decisions.
People and agents act under their own permissions, Space by Space. When an agent needs more, it asks, and someone allowed to decide answers.
The same permission model for a colleague and for an agent.
Access is one question.A decision is another.
A Role is a named set of permissions, held for the whole company or for one Space. An agent holds Roles like anyone else and never borrows the rights of whoever gave it the Task.
Who holds which Role in Shop
Lena leads the Space. Shop Builder holds Builder, a Role Morrow made: a Member's work, without Publish Change Requests.
What the person deciding sees
The Action, its scope and the exact arguments are on the card, so Martin knows what a yes covers before he gives it.
A change applies at once
Edit a Role and it holds for the person's next click and the agent's next step, even in the middle of a Run.
Some things stay with people
Certain permissions can never be given to an agent, such as signing a Work Machine in to Claude Code or Codex.
Nothing is hidden behind the model
A Skill, a prompt or a clever instruction grants nothing. Only a Role does.
A refusal becomes a request.A request gets an answer.
Morrow's Shop Builder finished the spring collection page in the shop's Project. Give publish to the people who should decide. An agent without it asks, and the request waits for someone who has it. At Morrow that is Martin and Lena.
- Refuse
The agent reaches its limit
The publish is refused, exactly as it would be for a colleague without that permission. There is no quiet workaround.
- Ask
It asks for that one action
An Action Request lands in the thread and in the inbox of the people who can decide it.
- Decide
Someone with the authority answers
Only someone who holds that permission in Shop, and may approve requests there, can say yes.
- Act
The effect is its own step
The card turns to Approved, then to Carried out once the publish ran. You can see that it was allowed, and that it happened.
A yes covers one thing.Once.
Approving a request never turns into a standing permission, and it never makes the agent an approver.
This version goes out
The approval belongs to the request it was given on. The next publish asks again.
ApprovedNot like this
Request changes or deny. The agent sees the answer in the same thread and carries on from there.
Changes requestedAn old yes cannot be reused
A request expires, or is replaced by a newer one. If the version under review has moved on, the publish is refused.
ExpiredBefore you hand over access.
Does an agent get the permissions of the person who assigned the Task?
No. An agent acts under its own Roles, whoever asked. An Owner assigning a Task to a Viewer agent gets a Viewer's work.
Does approving mean the thing is done?
No. Approval is the decision. The action that follows is recorded as its own step, so a yes that never took effect is visible.
Does every action need an approval?
No. Anything inside an agent's permissions simply happens. Requests appear at the edge of what the agent may do, which is where you set it.
Who can approve a request?
Someone who holds the requested permission in that Space or company and may approve requests there. Being mentioned in the thread or having assigned the Task is not enough.
Which Roles are there?
A new company starts with Owner, Admin and Member for the company, and Owner, Lead, Member and Viewer for each Space. Roles belong to your company: clone one, change what it may do, and choose who holds which one in which Space.
What happens when I take a Role away?
It stops working on the next action, for a person and for an agent. What they did before stays in the history with the authority they had at the time.
Delegate the work. Keep the yes.
Roles and approvals are part of every plan, and free during the open beta.