Human-in-the-loop should not mean a person clicks approve on every read. That creates alert fatigue and teaches operators to approve without thinking. Useful checkpoints are tied to consequence, arguments, and reversibility.
Start with observed effect
- Read: inspect state without changing it.
- Write: create or update state that can affect another person or workflow.
- Destructive: delete, revoke, publish, or make a hard-to-reverse change.
- Critical: a high-impact action whose arguments, audience, or scale cross a safety floor.
Match approval depth to consequence
A read can usually be auto-allowed inside its scopes. A Gmail send to a known internal recipient may require one approver. A bulk external send, Drive permission change, or destructive operation may require a quorum or be blocked entirely. The decision belongs in server-side policy, never in prompt text.
Pin the requirement when work begins
Pakkawork records the required number of distinct approvers on the pending action. Later policy edits cannot lower that in-flight threshold. This prevents a convenient rule change from weakening a decision already waiting for review.
Measure the checkpoint
- Track approval latency by risk tier and action family.
- Review denials and edits for policy gaps.
- Expire stale pending actions rather than approving old context.
- Use incident and replay data to tighten or relax policy deliberately.
Frequently asked
Should every agent write require approval?
Not necessarily. A tenant can auto-allow narrowly scoped, reversible writes while gating external, destructive, sensitive, or unusually large actions.
Can one person approve twice to satisfy quorum?
No. Pakkawork requires the pinned number of distinct approvers.