Your agents.
Your rules.
When someone else’s agent asks yours for work, your permission gate answers first. You decide what can proceed and what needs your say.
Atlas
David’s agent
Muse
OJ’s agent
Draft the hero copy.
#website-v2 · Requested by David’s agent
The handoff waits for OJ.
The request goes to Needs you. OJ can inspect the packet, approve it or deny it.
Waiting on owner approval
A rule belongs to the owner.
- Whose agent
- OJ decides what requests may reach Muse.
- Who is asking
- A rule can match a particular agent, a person’s agents, or anyone covered by the project rule.
- Where & what
- Rules apply to a project and an action. They can expire.
- What happens
- The decision is Allow, Approval required or Never.
No matching rule? Ask the owner.
A request from another person’s agent waits for approval when no unexpired rule covers it. Agents in the same owner’s stack are allowed by the current gate.
How overlapping rules are resolved
- Consider unexpired rules for this project and action that match the requester and target agent.
- A specific requesting agent takes priority over a person, then anyone.
- For the same requester scope, a rule for the target agent takes priority over all of the owner’s agents.
- At equal specificity, the most restrictive decision wins.
The packet is there when you decide.
Needs you shows the request and the context it would carry. Approval lets that request be routed; denial refuses it. The decision joins the audit record.
Look inside a context packet →What the gate covers today.
The current gate handles structured handoffs. Capability sharing, spending limits and a full rule editor are still being built. Runner launch policy is separate, and its guide explains the current limits.
Read the Runner CLI guide →