Human oversight and approvals

When an agent does the work, the question a governance owner has to be able to answer is not "did it run," it is "who decided it could move forward, and can you show me." This page is that answer. Disco Parrot keeps a person at the points that matter, makes each decision a recorded fact rather than a memory, and never lets a run slip past an approval you can see. It is the governance view of reviewable autonomy; for the mechanics of acting on a checkpoint in a run, the human checkpoints concept page walks the buttons.

Approvals are control points, not suggestions

A checkpoint is a point in an agent's run where the work stops and waits for a person. Until someone decides, nothing past that point happens. At each one a reviewer has three choices, and each is a different control outcome: approve continues the run from the next step, reject stops it in a rejected state and takes a comment that is kept with the run, and skip marks a step done and moves on. The run holds at the gate until one of the three is chosen.

Two properties make this a control a security owner can rely on rather than a convenience. Deciding a checkpoint takes the same permission as running the work in the first place, so the people who can approve are exactly the people you authorized to run agents, not a wider set. And a run accepts a decision only while it is actually paused at that gate, so there is no way to approve something that is not waiting, and no way for a run to advance past a gate that no one resolved. The gate is the control; the decision is the act that opens it.

There is no path around a gate. A checkpoint is resolved only by an authorized decision, and there is no break-glass override that lets a run slip one unrecorded. Even stopping a run is a scoped, recorded act, available to the person who started it and to anyone you granted the authority to cancel others' runs. The ways past a gate are the three on the record, and nothing else.

How much of a run gates is itself a setting you control. A run can pause before every step when the work is sensitive enough to watch closely, or gate only the steps a flow marks as the moments that matter, which is the usual choice. The more consequential the work, the more of it you can hold for a person, and the decision about where the gates sit is made before the run starts, not by the agent during it.

Every decision is on the record

A checkpoint decision is not a transient click. When a reviewer approves, rejects, or skips, the platform records the decision against that specific run, with who decided, which step, and the reviewer's comment when they leave one. That record lands on the run's own timeline and in the workspace event stream, alongside the per-run Sessions transcript that already holds every tool the agent called, the turns it took, and the cost. A recorded decision is an entry written when it happens, not a field anyone edits afterward, and audit and evidence covers how long that record is kept and the evidence trail behind it. So after the fact, "who approved this change, and when" is a question with a precise answer, produced from the record rather than reconstructed from memory.

This is the difference between oversight that is real and oversight that is asserted. The approval is not a feeling that someone was watching; it is a row you can point to, tied to a person and a moment, next to the work it gated.

A rejection is part of that record, not an erasure of it. A run someone rejects ends in a rejected state and stays that way in the history; re-running the work starts a new run linked to the one it came from, so the rejection is never overwritten, only superseded on the record. The reason a piece of work was turned back is as durable as the work that eventually went forward.

A background run advances only where you allowed it

The hard governance question about any automation is what happens when no one is watching. Sending a run to the background does not loosen its gates. By default, a checkpoint in a background run pauses and waits for you, exactly as it would if you were watching: the run parks, its background task moves to a review state, and it sits there until you come back and approve, at which point the run rebuilds from its saved results and continues. A waiting run surfaces in Sessions and the Command Center, so a reviewer finds the runs that need a decision rather than hunting for them.

A step can be marked, in advance, to auto-approve in the background. That is a deliberate, per-step setting decided when the work is configured, not a property of running in the background. When a step is marked that way, a background run approves that one checkpoint on its own and keeps going, and it writes the approval onto the step as an auto-resolved decision, so the record shows exactly what was approved without a person and when. The default for a step is to wait.

The governance reading of this is the one that matters: sending a run to the background is a choice, made per step and in advance, about which approvals may happen without you. It is never a blanket bypass of review. A run never advances past a checkpoint you did not explicitly allow to auto-approve, and the ones that do auto-approve leave the same kind of record the manual ones do. You can audit what ran unattended as easily as what ran with someone watching.

Which pause your controls hang on

A run can ask for a person in two different ways, and a governance review should keep them apart.

• A step checkpoint is the firm gate above. It sits before a step, holds the whole run, and is the control you rely on.
• While a step is running, the agent can also ask a question or present a plan 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 complete unattended, and every resolution is written into the Sessions transcript: a question proceeds on the agent's best judgment, and a presented plan is taken as approved. The firm gate that holds a run is the step checkpoint, not these in-step prompts.

The point of naming the difference is that the firm gate is the one your controls hang on. The in-step prompts are part of the conversation inside a step, and they are recorded, but the step checkpoint is where a person holds the run. When you decide which steps to gate, you are deciding where the real control points sit.

When the work does not converge, it stops

Oversight is not only the gates you set; it is also what the automation does when it cannot finish cleanly on its own. The built-in flows that re-check an agent's work do not loop forever. A recheck runs a bounded number of times, a few by default, and if the work regresses or fails to converge within that budget, the run pauses and escalates to a person rather than grinding on. So the cases that most need a human, a fix that keeps breaking something else, are exactly the cases that come back to one, on the record, instead of being buried in an endless retry. The automation has a ceiling, and the ceiling routes to a decision.

The riskiest changes come back as proposals

Some changes should never be applied by an agent on its own, and an environment is where you draw that line. Each environment carries a change policy that says, per kind of change, whether an agent may apply it or may only propose it. Under a propose-only policy, the agent prepares the change as reviewable source, the code or configuration that expresses it, and stops short of the apply-class commands that would push it live. The platform backs that line up: when a run produces a propose-only change, it raises a blocking event on the environment and the run holds rather than carrying on as though the change were already applied. The change comes back as a proposal a person reviews and ships through the normal pull-request path.

Propose-only is enforced on two sides. The agent is instructed to stop short of the apply-class commands, and the platform gate independently catches the change and pauses any downstream step that depends on it being applied. The catch does not rely on the agent flagging anything: the platform reads the files the run actually changed and matches them against the environment's policy, so an infrastructure or schema file raises the block on its own.

What a reviewer can verify

Oversight is only worth as much as what you can show, so each part of it produces something you can point to:

• The gated steps. A run's configuration says which steps pause for a person; the steps that produce or ship a change are the ones worth gating, and the built-in flows gate their plan and ship steps for exactly this reason.
• The decisions. Every approve, reject, and skip is recorded against the run with the person who made it, the step, and any comment.
• The unattended approvals. Any checkpoint a background run auto-approved is written onto the step as an auto-resolved decision, so what ran without a person is as legible as what did not.
• The full transcript. Each run keeps a Sessions transcript of the agent's tool calls and edits, and changes to your work carry an edit source of person, agent, or system, so the agent's hand is always distinguishable from a teammate's.

Answering "who approved this"

A quarter-end review lands on Sarah's desk with a single question about a change that went out during the Insights work: who signed off on it. A year ago that would have meant asking around. Here it is a lookup. She opens the run on the work it was tied to, and the timeline shows the plan checkpoint approved by a named reviewer with their comment, the ship step gated and approved before the pull request opened, and one background step that auto-approved, marked as such on the step with the time it happened. The change is traceable from the requirement that started it to the person who let it proceed, with nothing reconstructed and nothing taken on trust.

That is the whole intent of treating approvals as recorded control points rather than live moments. The team gets the speed of letting agents carry the work, and the people who answer for how the work is governed get an answer they can produce on demand, for the runs someone watched and the runs that ran on their own alike.

Why oversight works this way

The easy version of human-in-the-loop is a person watching a screen, and it fails the moment the work scales past what one person can watch. So the model does not rely on attention. It relies on gates that hold whether or not anyone is looking, decisions that are recorded whether or not anyone remembers, and a default that a run waits unless you decided, in advance and per step, that it could proceed without you. Attention is welcome but never load-bearing.

From that one choice the rest follows. Approving takes the same permission as running, because the right to let work proceed should be the right you already granted, not a looser one. The riskiest changes route back as proposals, because the line between what an agent may apply and what a person must approve belongs to you and should be enforced, not hoped for. And everything is recorded, because attention fades and memory drifts, but a record does not.

For the person who owns how AI is used, this is the page that answers "is a human really in the loop, and can we prove it." A run holds at every gate you set, deciding takes the permission you already control, each decision is recorded with its author, and a background run advances only through the approvals you marked in advance, each of which is logged. The proof is the record, not the promise.

For a team lead, the gates are how you let the team move fast without losing the moments that matter. You gate the steps that produce or ship a change, send the rest to the background, and still get a clean answer to who approved what, because the auto-approvals are on the record too.

For an engineer, checkpoints mean you weigh in while a decision is still cheap to change, at the plan and at the ship, not after a pile of output lands. You can send a long run to the background and pick it up from the review state, and nothing past a gate happened without a decision.

For a prospect evaluating the platform, this is what reviewable autonomy looks like under a governance lens. The agent does the labor; a person owns the decisions at defined points; the record shows who decided and when; and the riskiest changes come back for review by design. The control is in the mechanism, not in a policy you have to trust the product to honor.