Review consequence, not just complexity
A technically simple email can make a binding customer promise, while a complicated internal search may have no external effect. Classify actions by consequence: read, prepare, change, send or remove. Decide which require a person and why. This makes the approval boundary understandable to operators and prevents low technical complexity from being confused with low business risk.
Show what the person is approving
The approval screen should include the target, meaningful changed fields, proposed external effect and the evidence behind the suggestion. “Approve workflow” is too broad for a changed customer price. Use a specific statement such as approving this quote revision for this customer. If the source changes before execution, re-check that the approval still applies.
Make refusal a normal path
A reviewer needs ways to correct, reject or ask for information, not only a prominent green button. Preserve the draft and explain what the next step will be. A rejected suggestion should not reappear as approved because a background retry ran. State transitions and permissions belong in the application backend rather than only in the interface.
Measure review effort honestly
If every case needs lengthy manual reconstruction, the workflow may not yet save useful effort. Count review time, corrections and the reasons for escalation. Improving the input contract can be more effective than increasing autonomy. Forge helps engineer these boundaries in a new module, while the customer determines who performs the operational reviews after deployment.
Approve an action, not an undefined level of autonomy
“Let the agent work automatically” leaves important questions unanswered. May it change a schema, send a message, deploy code or spend money? Define action classes and the conditions under which each is permitted. A low-risk text change and a destructive migration should not inherit identical authority because they belong to the same Project.
For a quote workflow, allow extraction and draft preparation but require approval before an unusual discount or external send. The approval should refer to the exact draft and relevant version. If the amount or recipient changes afterwards, a stale approval cannot authorize the new action.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Read | Access only approved sources. | Scoped permission check. |
| Draft | Create a non-binding proposal. | No external side effect. |
| Commit | Perform a consequential operation. | Fresh permission and exact approval binding. |
Where this goes wrong
An approval button must not hide several unrelated permissions. Separate data import from deployment, and monitoring enrollment from remediation. Provide a visible stop action and define what happens to work already in progress when authority is withdrawn.
Human control works when the human can understand and change the decision.
Turn it into a working checklist
- Classify external consequences.
- Approve a named action and revision.
- Provide correction and refusal paths.
- Track review effort and stale approvals.
A concrete next step
Create a small action policy matrix and test both permitted and denied operations. Review stale approvals, changed records and revoked access as first-class scenarios, not exceptional afterthoughts.
Watch a related case
The video could not be loaded. Try again later.