Human-in-the-loop

Human-in-the-loop (HITL) describes a system in which a person takes part at defined decision points: reviewing, approving, correcting or rejecting what an automated system proposes before it takes effect. The automation does the work; a human keeps the authority over consequential actions.

What it is

The pattern sits on a spectrum. At one end, a person approves every action. At the other, the system acts alone and people only audit afterwards ("human-on-the-loop"). Most practical systems pick specific checkpoints: the actions that are expensive, irreversible or risky get a person, the rest run on their own.

Two properties make a checkpoint real rather than ceremonial. The approver has to see what they're approving, and the approval has to belong to the exact thing that ships: if the work changes afterwards, the approval should not carry over.

Why it matters

AI agents can produce plausible code that is wrong in ways tests don't catch. A human checkpoint before merge puts accountability with a named person, catches problems automation can't judge, such as product intent, and gives auditors a clear record of who decided. It's also what many change-management controls already require of human-written changes.

In AI CodeOps

The checkpoint is before the pull request. When a session finishes with a diff, AI CodeOps opens a review request under Review & Gate → Approvals:

1. Choose Review the proposed changes to read the diff, next to the findings and test results.
2. Choose Approve (an optional note) or Reject (a reason is required). The run page offers the same as Accept changes and Reject.
3. Approving opens the pull request, if the quality gate also passes.

The rules that keep it honest:

approvers        owners, admins, security admins, or a role with approval:decide
two-person rule  the person who launched the session can't approve while
                 someone else in the workspace can
rejection        one reject ends the request
edits            editing the change after approval resets it to pending
expiry           code-change reviews 7 days; held session starts 3 days

Policy rules can add checkpoints earlier. An ask decision on workflow.dispatch or agent.dispatch holds a session until someone approves it; an ask on diff.apply or github.push requires an approved review before the pull request. See the policy engine.

Each decision is recorded in the audit log as approval.decided, and the approval and every vote go into the change's signed evidence pack.

Related terms

• Policy engine: decides when a person is needed.
• Role-based access control (RBAC): decides who that person may be.
• Multi-agent system: the automated work a person reviews.