How it works
Workflow approval turns a human decision into an explicit state transition. The workflow does not merely wait for a chat reply or a loose confirmation. It reaches a named approval point, persists the proposed next action, and stops execution until a valid decision arrives.
A typical approval mechanism has five parts:
- The workflow produces a proposal: action, target, inputs, expected effect, and risk level.
- The harness records the pending state in durable storage, usually with a run ID, proposal hash, actor, timestamp, and timeout policy.
- The approver receives enough context to decide without reconstructing the whole run from memory.
- The decision is captured as approve, edit, reject, delegate, or timeout.
- The workflow resumes from the recorded checkpoint, using the approved or edited proposal as the new source of truth.
The important detail is durability. An approval is not a modal dialog floating over an in-memory process. The worker may crash, the browser may close, or the operator may answer later from another surface. The approval state still has to be recoverable. That means the harness needs a stable checkpoint before the hold and a clear resume contract after the decision.
The approval should also bind to the exact proposal being reviewed. If the agent changes the email, command, budget, credential scope, or deployment target after approval, the old approval should not silently cover the new action.
Why it matters in an agent harness
Agents are useful because they can carry work across several steps. They are risky for the same reason. A model can move from reading to planning to acting before an operator has noticed that the trajectory changed. Workflow approval gives the harness a place to slow down at decisions that matter.
The engineering value is control, not ceremony. A good approval point separates capability from permission. The agent may know how to publish, deploy, spend credits, send a message, mutate records, or call an external tool. It still does not have authority to do every one of those actions whenever it predicts they are useful. Approval turns that authority into a specific, logged grant.
It also improves reversibility. Many agent actions are not truly reversible after they cross a boundary: an email is sent, a payment is initiated, a customer record is overwritten, or a production system is changed. Approval before the boundary is cheaper than compensation after it. Where reversal is possible, the approval record still helps because it shows what the operator believed they were authorizing.
Observability improves as well. A pending approval is an inspectable state, not an absence of progress. Operators can see what is blocked, why it is blocked, who can decide, how long the hold has existed, and what will happen on timeout. That matters in long-running workflows where silence is otherwise ambiguous. Did the agent stall, finish, fail, or wait for judgment? The approval state should answer that question.
Workflow approval also contains failure. If a model is confused, manipulated by prompt injection, or operating on stale context, the approval checkpoint can stop the bad trajectory before it gains write authority. It is not a replacement for sandboxing, typed schemas, or deterministic verification. It is a control boundary for decisions where human judgment is still part of the system design.
Workflow approval vs approval gate
The distinction changes implementation. An approval gate is often discussed as a policy boundary. Workflow approval is the durable runtime mechanism that enforces that boundary inside an executing workflow.
| Concept | Primary concern | Design implication |
|---|---|---|
| Approval gate | Whether an action class requires human permission | Define policy by risk, scope, cost, reversibility, or authority |
| Workflow approval | How the running workflow pauses and resumes around that permission | Persist state, bind the decision to a proposal, and resume deterministically |
| Manual review | A person inspects output outside the workflow engine | Useful for quality, but weak if it is not tied to execution state |
A system can have approval gates without reliable workflow approvals. That usually looks fine in a demo and fails under interruption. The agent asks for permission, the operator replies, and the run continues from memory. If the process restarts, or if the proposal changes between question and answer, the system has no trustworthy record of what was approved.
A system can also have workflow approvals without a thoughtful policy. That produces too many holds in low-risk places and too few in dangerous ones. The result is operator fatigue. People click through prompts because the harness has not reserved approval for decisions that deserve carried judgment.
The Rifty take
We optimize approval for state, not sentiment. A human saying yes is not enough; the harness needs to know what proposal was approved, which authority was granted, and what checkpoint can safely resume.
The tradeoff is latency. We accept that some workflows should pause if the alternative is granting broad authority to a stochastic process. The boundary is simple: approval should protect irreversible, externally visible, costly, privileged, or reputationally meaningful actions. It should not become a substitute for better schemas, smaller permissions, or deterministic checks.
Implementation checks
- Store approval as a first-class workflow state, not only as a notification or chat message.
- Persist the proposal, approver, decision, timestamp, timeout behavior, and resume target.
- Bind approval to a stable proposal hash or version so changed work requires a fresh decision.
- Show the operator the action, target, diff, credential scope, expected effect, and failure consequence.
- Support explicit reject and edit paths. Do not treat no response as approval unless the policy says so and the risk is low.
- Make timeout behavior visible. A timeout may cancel, escalate, retry, or continue with a reduced action, but it should not be implicit.
- Keep approval scopes narrow. Approval to send one message should not become approval to use the mailbox freely.
- Record the decision in the audit trail and connect it to the execution trace.
- Test crash and resume behavior at the approval point. The most important approval bugs appear after interruption.
- Watch for approval fatigue. Too many low-value checkpoints train operators to stop reading the high-value ones.
Frequently asked questions
When should a workflow require approval?
A workflow should require approval before actions that are hard to reverse, externally visible, costly, privileged, legally sensitive, or reputationally meaningful. Low-risk internal transformations usually need deterministic checks instead. Approval is best reserved for places where human judgment changes the authority of the run.
What makes workflow approval durable?
Workflow approval is durable when the pending decision is persisted outside the live worker and can survive process failure, browser closure, or delayed response. The stored state should include the proposal, checkpoint, approver, timeout policy, and resume contract so execution can continue without relying on memory.
Is workflow approval the same as human-in-the-loop?
Workflow approval is one form of human-in-the-loop control, but it is narrower. Human-in-the-loop can include labeling, review, correction, coaching, or escalation. Workflow approval specifically pauses execution at a decision point and resumes only after a recorded decision changes the workflow state.
How do approvals fail in agent systems?
Approvals fail when they approve vague intent instead of a specific proposal, when the proposal changes after approval, or when approval state lives only in chat history. They also fail through overuse. If every minor action asks for permission, operators stop treating approval as a serious control.
Should timeout ever mean approve?
Timeout should rarely mean approve, and only for low-risk actions where that behavior is explicit in policy. For meaningful write actions, timeout should usually cancel, escalate, or keep the workflow pending. Silent approval on timeout turns absence into authority, which is a poor default boundary.