Engineering note
Human decision gates in production AI workflows
Separate generation from mutation. Let the system gather context and prepare a typed proposal, then require an explicit human decision before application code performs a state-changing action.
By Raphael Mansueto · Reviewed
A decision boundary, not a decorative approval step
The model can prepare work, but the product owns the transition from a reviewable proposal to persisted state.
- Ground contextCollect the business and workflow evidence needed for the task.
- Prepare typed outputConstrain the draft to a schema the product can inspect and render.
- Ask for a decisionExpose approve, improve, or reject paths before any mutation.
- Commit and traceApplication code validates, persists, and records the confirmed outcome.
Put the boundary before the write
A human-in-the-loop label is not enough. The important design choice is where authority changes hands. In the Ample News assistant, read behavior could run directly, while state-changing tools followed a read, confirm, write sequence. The user reviewed the intended change before the application accepted it as product state.
That boundary keeps AI useful without treating model output as an instruction that must be executed. The model proposes; the product validates; the person decides.
Make feedback part of the product path
A decision gate should support more than approve or cancel. An improve path lets a person change direction while the relevant context is still available. The revised proposal remains reviewable, and rejection ends the attempted change without leaving ambiguous partial state.
- Show the proposed effect in product language, not raw model output
- Preserve the feedback that produced a revision when it is safe to retain
- Require a fresh confirmation after material changes
- Keep the final mutation inside deterministic application code
Persist the workflow around the model call
Long-running AI work crosses request lifecycles and provider boundaries. A tracked run with bounded stages makes the draft, decision, retry, and final state inspectable. Typed inputs and outputs keep each handoff explicit, while stage-level failure boundaries prevent one provider error from obscuring the rest of the run.
Use gates where the cost of a wrong write is real
Confirmation adds latency and can become ritual if every low-risk interaction asks for permission. Use it for actions that change customer-visible state, publish externally, spend money, or are difficult to reverse. Read-only retrieval and clearly reversible local edits can use lighter controls.
This pattern demonstrates a reviewable production boundary; it does not claim that human review makes model output correct by itself.