Who gets to say yes: designing approval for agent work

An approval gate settles whether an action should pause. It does not settle who should decide once it has. In many teams that second question gets answered by accident: whoever sees the notification first clicks the button. That works until the person clicking has no authority over the thing being approved, or until an approval given in one place is quietly treated as valid somewhere else. Approval responsibility deserves the same deliberate design as the gate itself.

Start with the company boundary

The outermost line is the company. Work, memory, files and credentials belong to one company, and a decision made inside it should carry no weight outside it. That sounds obvious until you meet the cases that test it: a consultant who belongs to two client workspaces, an agency running work for several brands, an employee who moves between subsidiaries. The same human can be a legitimate approver in one company and a stranger in the next. A decision should travel with the company it was made in, not with the person who made it.

GoCux treats the company as the boundary for work, memory, files and credentials. A yes given inside one company counts for nothing in another.

Projects narrow the scope

Inside a company, the next scope down is the project. Projects separate client matters, product lines or teams, and they are where most approval rules should live. Someone who can approve an export from the finance project has not thereby earned the right to approve an export from the legal project. Write approval rules per project and per kind of action, not per person in general.

Members, launchers and approvers are different jobs

It helps to pull apart three things that people often bundle together:

• Who can see the work. Membership of a project lets someone read work orders, results and evidence.
• Who can start the work. Launching a work order sets its goal, scope and bounds.
• Who can decide on consequential steps. Approving a send, an export or a deletion.

These overlap but should not be identical. A sensible starting point looks like this:

The pattern is simple. The further an action reaches beyond the launcher's own work, the more the approver should be someone with authority over what it reaches.

Access on one surface is not permission on another

The quietest way approval breaks is by inference. Someone has access to one thing, and the system, or the team, treats that as permission for a neighbouring thing. Common examples:

• A credential has been granted for a system. That does not mean an agent may write to it unattended.
• A connector has been registered. That does not mean every task may use it.
• An MCP server is configured in a client. That does not make it authorised for every piece of work.
• A skill is installed. A reusable instruction is not a grant of authority.
• A person approved one email. That approves neither the next email nor a revised version of the same one.
• Someone is an administrator in the system the agent writes to. That does not make them an approver for agent work in your workspace.

Each of these should be its own explicit decision. Connecting tools without widening authority goes deeper on the connector side.

Designing approval responsibility

• Name a person or a small role per action and per project. “The team” is not an approver. A group where everyone can click tends to become a group where everyone assumes someone else has read the request.
• Plan for absence. If the approver is away, the work should wait rather than route to whoever happens to be online. Name a backup in advance.
• Decide on self-approval explicitly. Letting the launcher approve their own send is often fine. Letting them approve their own deletion or instruction change usually is not.
• Check again at the moment of execution. Authority can change between a decision and the action it covers. The check belongs to the moment the action runs, not only the moment the button was pressed.
• Record who decided and what they saw. Responsibility you cannot trace later is not responsibility. See what an agent audit trail should record.

How this looks in GoCux

In GoCux, a short list of action classes pauses for a decision by someone on the team, and everything else runs inside the limits set for the work. While a work order is waiting on a decision, nothing downstream of it starts. Each decision applies only to the attempt it was given for and is checked again when the action executes, and decisions are kept as receipts on the work's record. Projects are scopes within the company, and credentials stay on the server as references rather than sitting in the browser. How roles map onto these permissions is described in the roles and permissions documentation, and the governance page gives the overall picture.

Questions to settle before you switch approvals on

1. For each project, who may approve each class of consequential action?
2. Who is the backup, and what happens to waiting work if neither is available?
3. Where is self-approval allowed, and where is it not?
4. Which credentials, connectors and skills does each project use, and has each been approved for that use on its own?
5. Can every approval be traced to one company, one project, one attempt and one person?

If you are still deciding what should pause in the first place, start with why agents should ask before acting.