Human-in-the-loop gates for AI coding agents

A gate is a point work cannot pass until a condition is met; a human-in-the-loop gate is one where the condition is a person's decision. In its work with AI coding agents (AI agents that write code, such as Claude Code or Codex), AR Labs keeps a small number of them fixed (the first design, the campaign plan, the merge to main, and anything irreversible or public), lets an autonomy level decide which others an agent may pass, and works to make each remaining gate cost the person one short decision rather than an investigation. The design matters to anyone running agents: badly placed gates either waste a person's day or let an agent decide what it should not.

The problem it answers

Gates fail in two directions. Too many, and the person becomes a relay who answers "yes" all day while the agent waits. Too few, and an agent decides something only a person can: a design trade-off, a priority, what the public sees. A gate can also be badly shaped: a question with no recommendation, a pull request with no summary, a decision whose context lives in a transcript nobody will read. We treat both the placement and the shape of a gate as engineering.

Where a person always decides

Gate	Why a person holds it
The first design of a campaign	Architecture and trade-offs are judgement the agent cannot be accountable for
The campaign plan	Every later step is delegated against it
The merge to main	A person checks whether the change serves the goal and fits everything else in flight, which no review model can see
Anything irreversible, public or paid	A deploy, a published page, a deleted file or a sent message cannot be undone with a revert

The rule for an agent working inside a session is described in act or ask: act on what is reversible and the agent's own to do, and ask about what is irreversible, outward-facing, someone else's, or a matter of the person's knowledge or taste.

Gates an autonomy level can relax

Every task carries an autonomy level, set when the work enters the pipeline and inherited by its children. The level decides which human gates an agent may pass; it never removes a scripted check.

flowchart LR
  H["hold: every gate waits"] --> I["hitl: ask, advance after silence"]
  I --> W["wave: agent passes spec and build gates"]
  W --> D["deep: also fan-out, design revisions, integration"]

At hold, every gate waits for the person. At hitl, the pipeline asks and, if no answer comes within a set silence window, advances and records that it did. At wave and deep, spec approval is delegated to the approved plan: a spec within the plan's constraints is approved, and any variance is a block. At deep, later revisions to the design record can also pass, but the first design, the plan and the merge hold at every level. See the pipeline for the full table.

How a gate is made cheap

A proposal, not a request to look. At a gate, the agent has already done the work and recorded the result as a proposal: a spec, a design diff, an issue breakdown. The person judges an artefact rather than deciding whether work should start.

One question, one recommendation. The agent gives the artefact's location, its gist in a sentence or two, and its own recommended answer. The same question and recommendation are written onto the task as a note, so the decision survives the session.

Fixed answers. A resting proposal lists the person's options, usually approve, revise or park. A failed review offers a per-finding choice: fix it, accept it with a note, or file it as a separate task. The person picks rather than composes.

Work carries on while the question stands. The agent asks once and moves to other runnable work in the same tree, or starts the next task. It never asks the same question twice in a row and never stops an unattended run to ask about something it is allowed to do.

Reports come from the record. When the person returns, a digest generated from the task records lists what landed, what waits for them and why, what is running and what the work discovered. Nothing depends on the agent's memory of what it did.

Reviewable units. One pull request per task keeps each merge decision to a diff a person can actually read. The body opens with three plain paragraphs (what was broken, what changes, what the reviewer needs to check) before any mechanism. A person who wants to understand the change in depth can ask for a guided reading of it (see understanding agent-written code).

Steering is not a waiver. "Looks fine, keep going" approves the gate just presented. It does not relax the next gate. Changing which gates hold is a recorded change to the task's autonomy level.

Facts are the agent's job. In the design interview the agent reads the code to answer factual questions itself and asks the person only about choices. A gate should never ask a person to look something up.

A worked example

Illustrative example, with generic names. An attended session is driving a campaign at the hitl level. The spec for billing-2.4 is ready. The session writes to the person:

Spec for billing-2.4 (retry failed card payments) is ready at specs/billing-2.4.md. It retries three times with backoff and adds one table. It stays inside the plan except for one point: the plan says "retry later", and the spec reads that as within 24 hours. Recommend approve.

The same text is appended to the task as a question: note, and the session moves on to billing-2.5, whose spec is still being written. An hour later the person replies "approve, but 48 hours". The session records the approval, relays the change into a revised spec, and re-runs the driver, which picks up the new state without being told what happened.

Where it came from

The split between human-in-the-loop and away-from-keyboard work comes from Matt Pocock's workflow. The autonomy levels, the recorded question with a recommendation, the silence window and the digest are our own, built because agents asking instead of acting had become the largest single drag on our agent sessions.