The seven actions that wait for a person, one by one

An agent that asks permission for everything is as unhelpful as one that asks for nothing. The useful line runs through consequence. Most of what an agent does, reading, searching, comparing and drafting, can run freely inside the limits you set, while a short list of actions should wait for someone on the team. In GoCux that list has seven entries. This note walks through them one at a time: what each covers, why it pauses, and what the person deciding is actually agreeing to. The broader case for having a gate at all is in why an agent should ask before it acts.

Effects that leave the workspace

1. Sending things out

Emails, messages, posts, form submissions: anything that reaches a person or system outside the work. Sending pauses because it cannot be recalled. Once a message has been read, a correction is a second message, not an undo. The approver sees the draft as it would go, with its full recipient list, and can approve it, reject it or edit it safely before it leaves. An edit should produce a new draft that is checked again, not a change slipped into the one already approved.

2. Exporting data

Copying files or records out of the workspace, whether to a download, another system or another person. The risk with exports is scope: inside the selected folder sits another folder nobody remembered. So an export pauses with the files in scope listed one by one, not summarised as “the project folder”. The decision covers those files and that destination, and nothing more.

Effects that are hard to undo

3. Destroying things

Deleting files, records, branches or memory. This is the strictest class: destruction stays blocked until a signed decision arrives. A signed decision should be attributable: a named person, a specific set of things to delete, recorded at the moment they decided. Cleanup tasks are where instructions are most ambiguous (“remove the duplicates”, “clear out the old drafts”), so the list of what would be destroyed is the thing to review, not the instruction that produced it.

4. Scheduling work

Setting something to run later or repeatedly. A schedule is a decision that keeps executing after everyone has stopped thinking about it, consuming budget and producing effects. Recurring work runs only inside a cadence and a safeguard that someone approved: how often, until when, and what stops it. Changing the cadence is a new decision. Putting a ceiling on agent spend covers why schedules are a common source of quiet cost.

Effects that change who is acting

5. Acting in a live session

Working inside a browser or application session where the agent acts with someone's signed-in access. Here the agent can do anything the session can, so the session itself is supervised, and consequential steps inside it, such as submitting, purchasing or deleting, still pause individually. Being let into the session is not a blanket approval for everything that can be clicked there. Browser agents explains the wider pattern.

6. Rewriting its own instructions

Changing the standing instructions, skills or policy text that shape future runs. This class exists because instructions are where an agent can be talked into things: a line of text in a document it read can suggest a “small improvement” to its own rules. A proposed change is held for review and does not take effect until a person accepts it. Until then, the approved version is the one that counts.

7. Putting another agent to work

Delegating part of the job to another agent. Delegation is where authority spreads without anyone noticing, because the helper may have tools or access the original agent was never granted. In GoCux delegation is declared up front, and the second agent works under the same policy as the first. It inherits the limits, not a fresh set of permissions.

What a decision covers

Across all seven classes, three rules keep a decision from meaning more than it should:

• One decision, one attempt. Approving an email approves that email. The next one asks again.
• Checked again at execution. The decision is verified when the action runs, so a change in between, a new recipient or a different set of files, invalidates it.
• Quoted word for word. The paused call is shown exactly as requested, so what gets authorised is what was asked, not a paraphrase of it.

A rejection is recorded and closes that path; it does not release the work some other way. Approving takes a single click, and the decision and its outcome become a sealed receipt on the work's record. What an agent audit trail should record describes what that receipt should hold, and who may approve agent work covers who gets to click.

What runs without asking

The list is short on purpose. Everything outside it runs without a pause, inside the bounds of the work order: its scope, its wall time, its tool-call limit and the daily spend cap. That includes searching project documents, reading sources on an approved allowlist, extracting values, drafting deliverables, and preparing the very things that will later pause, like the email or the export. A gate that fires on every step teaches people to stop reading. A gate that fires on these seven gets attention each time.

Adapting the list to your own team

Whatever system you use, these questions test whether your pause list is right:

• For each action your agents can take, can you say whether it pauses? If some are unclear to you, they are unclear to the agent too.
• Does every pause show the exact action and its full scope, the recipient list or the file list, without digging?
• Are deletions held to a stricter standard than sends?
• Do schedules have an end, or at least a review?
• Can the agent change its own instructions without review? If so, the rest of the list can be rewritten from inside.
• Does delegation inherit limits, or reset them?
• Does anything pause so often that people approve it without reading? Then it belongs in the bounds of the work order, not at the gate.

If you are introducing agents for the first time, start them read-only and add these classes one at a time. The governance page shows how the pieces fit together.