Human checkpoints
Checkpoints pause a Flow before a step so a person can approve, reject, or skip the work before the run continues.
A checkpoint is a point in a Flow where the run stops and waits for a person. Until someone decides, nothing past that point happens.
Checkpoints are how a team keeps judgment in the loop while an agent does the work. You approve the plan before it gets built, or the change before it ships. This is the mechanism behind reviewable autonomy: the agent carries out the steps, and a person owns the decisions that matter.
The three decisions
When a run reaches a checkpoint, you have three choices.
| Decision | What happens |
|---|---|
| Approve | The run continues from the next step. |
| Reject | The run stops and ends in a rejected state. You can leave a comment explaining why, which is recorded with the run. |
| Skip | The current step is marked skipped and the run moves on. Skipping the last step finishes the run. |
Which steps pause
A Flow's checkpoint mode sets the policy for the whole run.
- template pauses only at steps that are marked for a checkpoint. This is the usual setting: the Flow's author decides which moments deserve a person.
- all pauses before every step, which is useful when you want to watch a run closely.
- none runs straight through with no pauses.
In interactive mode, every checkpoint the mode selects pauses and waits for you. There is no way for a run to slip past a checkpoint you can see.
Where you approve
You act on checkpoints from the run's timeline, which you reach from Sessions or from the run on the work it is tied to. Each paused step shows the completed work above it, the upcoming step and its message, and the Approve, Reject, and Skip actions. A rejection takes an optional comment, so the next person, or the next run, has the context. Run a Flow & manage checkpoints walks through the decision in the run UI step by step.
A decision is recorded as approve, reject, or skip against the specific run, and it requires the same permission as running a Flow. A run only accepts a decision while it is actually paused.
Checkpoints in background runs
You can send a run to the background so it proceeds without you watching it. A background run does not skip your checkpoints.
By default, a checkpoint in a background run pauses and waits for you, exactly as it would if you were watching. When the run pauses, its backing background task moves to a review state and its sandbox is torn down to free resources. It surfaces in Sessions and the Command Center while it waits, and sits there until you come back, approve, and resume, at which point the sandbox is rebuilt from the saved step results and the run continues.
A step can opt into auto-approval in the background. When a step is marked that way, a background run approves its checkpoint on its own and keeps going, and it writes that approval onto the step as an auto-resolved decision, so the record shows exactly what was approved without you and when. Steps that are not marked stay manual and still wait.
The practical takeaway: sending a run to the background is a choice about which approvals may happen without you, decided per step, not a blanket bypass of review. A run never advances past a checkpoint you have not explicitly allowed to auto-approve.
In-step questions versus step checkpoints
There are two different moments a run can ask for input, and it helps to keep them apart.
- A step checkpoint is the firm gate described above. It sits before a step and holds the run.
- While a step is running, the agent can also ask a question or present a plan for approval as part of its work. In an interactive run, these wait for your answer. In a background run, they resolve on their own so the run can finish: a question resolves to "proceed with your best judgment" and a presented plan resolves to "approved, proceed," and both resolutions are recorded in the Sessions transcript.
The step checkpoint is the gate you rely on for control. The in-step prompts are part of the conversation inside a step.
Why this matters
For the people doing the work, checkpoints mean you review intent while it is still cheap to change. Catching a wrong approach at the plan checkpoint costs a sentence. Catching it after the code is written costs a rewrite.
For the people who own how AI is used, checkpoints are the point in the system where a person signs off before a change lands, on the steps a Flow is configured to gate. Combined with the fact that any background auto-approval is recorded on the step, and that every run keeps a Sessions transcript, checkpoints give you a defensible answer to who approved a given change and when. The governance view of all of this, approvals as recorded control points you can attest, is human oversight and approvals. The control is only as tight as the Flow's configuration, so the steps that produce or ship changes are the ones worth gating, and the recheck and create-pr steps in the built-in Flows are gated for exactly this reason.