How it works
An approval flow turns a decision into an explicit state transition. The agent may prepare an action, but the harness prevents execution until an authorized reviewer supplies a valid response. The pause must occur before the side effect, not after a tool call has already crossed the control boundary.
A reliable flow usually follows this sequence:
- A policy identifies an action that requires approval based on its permission scope, cost, reversibility, or blast radius.
- The harness saves the proposed action, relevant evidence, current workflow state, and an idempotency key.
- The job enters a durable waiting state. It does not hold an in-memory process open or repeatedly ask the model what to do.
- An authorized person approves, rejects, expires, or modifies the proposal.
- The harness validates that the decision still applies to the exact action and state that were reviewed.
- Execution resumes once, or the workflow follows a defined rejection or timeout path.
The proposal should be immutable while awaiting review. If a material parameter changes, the old approval no longer applies. A new proposal needs a new decision. This prevents approval from becoming a reusable token for an action the reviewer never saw.
Why it matters in an agent harness
Approval flows let a harness preserve useful autonomy without giving the model unrestricted authority. The model can research, assemble a plan, calculate a diff, or prepare a tool call. The harness retains control over whether a consequential side effect occurs.
That separation matters because model confidence is not authorization. An agent may choose a plausible action that exceeds the operator's intended scope, relies on stale context, or affects a resource with a larger blast radius than expected. An approval flow converts that uncertain judgment into a bounded proposal. The operator reviews the action at the point where intervention still has leverage.
The control is only useful when the review surface is legible. A prompt such as “Continue?” hides the decision. The reviewer needs the target, operation, important parameters, expected effect, permission being exercised, and available recovery path. For a file change, that may mean a diff. For an external message, it means the recipient and final content. For a destructive operation, it includes the exact resources and whether restoration is possible.
Durability and attribution are equally important. The harness should survive restarts while waiting, record who decided what, and bind the decision to the reviewed proposal. Otherwise, the flow creates the appearance of oversight without a dependable control boundary.
Approval should also remain selective. If every harmless read requires attention, operators learn to approve reflexively. That raises coordination cost while reducing review quality. Place approval where delegated authority crosses a meaningful boundary, then use deterministic policies and scoped permissions for routine actions inside that boundary.
Approval flow vs approval gate
The terms are related, but they describe different parts of the control design. An approval gate is the condition that blocks progress. An approval flow includes the surrounding lifecycle needed to make that gate operational.
| Design question | Approval gate | Approval flow |
|---|---|---|
| What does it define? | Whether execution may cross a boundary | How a proposal is paused, reviewed, decided, and resumed |
| Primary concern | Policy enforcement | End-to-end decision handling |
| State requirement | May be a synchronous allow or deny check | Requires explicit pending, approved, rejected, expired, and resumed states |
| Recovery concern | Usually outside the gate itself | Must define restart, timeout, cancellation, and duplicate-resume behavior |
| Audit requirement | Records the policy result | Connects proposal, reviewer, decision, and resulting execution |
This distinction changes implementation choices. A gate can protect a single tool invocation inside one process. A flow is needed when review may take minutes or days, execution must survive a restart, or several outcomes can redirect the workflow. Treating that lifecycle as a boolean callback usually leaves ambiguous state and unsafe retry behavior.
The Rifty take
We treat approval as a transfer of authority, not a ceremonial pause. We optimize for a small number of high-context decisions at real control boundaries, and we accept less nominal autonomy in exchange for legible, attributable execution. Approval never repairs an overbroad permission model; the action must still be scoped before it reaches the reviewer.
Common failure modes
- Asking for approval after the external side effect has already occurred.
- Showing a vague summary instead of the exact target, parameters, diff, or consequence.
- Allowing an approved proposal to mutate before execution.
- Resuming from memory rather than durable, authoritative workflow state.
- Retrying an approved action without idempotency protection, causing duplicate effects.
- Treating silence or a timeout as approval instead of following an explicit expiry path.
- Accepting a decision from a user who lacks authority over the affected resource.
- Reusing one approval across multiple actions, targets, or materially changed inputs.
- Placing gates on low-risk work until reviewers approve by habit.
- Recording the decision without linking it to the proposal and resulting execution.
Frequently asked questions
Which agent actions should require an approval flow?
Require approval when an action crosses a meaningful authority boundary: destructive writes, external communication, financial commitments, credential changes, publication, or operations with a wide blast radius. Routine reads and reversible changes should usually rely on scoped permissions and deterministic policy unless their context makes them unusually sensitive.
What context should an approval request show?
Show the exact proposed operation, target, consequential parameters, expected effect, permission scope, supporting evidence, and recovery option. The reviewer should understand what will happen without reconstructing the agent's entire trace. If the proposal changes materially after review, invalidate the decision and request approval again.
How should an agent resume after approval?
Resume from durable, authoritative workflow state rather than from a model's recollection of the conversation. Validate the decision, proposal version, current resource state, and idempotency key immediately before execution. Then record the outcome so a restart or retry cannot silently perform the approved action twice.
Can approval flows replace least-privilege permissions?
No. Approval confirms a specific decision; least privilege limits what the system can do at all. An approved action should still use narrowly scoped credentials and permissions. Otherwise, a mistaken approval, compromised reviewer account, or confused-deputy path can exercise more authority than the reviewed operation requires.
When does an approval flow create more risk than control?
It becomes counterproductive when prompts are too frequent, vague, or disconnected from the actual side effect. Reviewers then approve by habit while the system gains little control. Reduce low-value checkpoints, improve the decision surface, and keep mandatory review for actions whose consequences justify human attention.