AI Agent Quality Gates: Done vs Verified, Human-in-the-Loop & Guardrails (2026)

Prevent AI coding agents from marking work complete before it is verifiably done — with cost gates, context gates, action gates, and board-enforced outcome gates. Updated July 2026.

Why AI agents need quality gates

Without gates, an AI coding agent's definition of “done” is “I pushed the code.” The agent has no intrinsic reason to wait for CI, check whether the deploy succeeded, or run a smoke test on production. It just moves on to the next task. This produces a classic overnight-run failure: 20 tasks marked done by morning, zero of them deployed, none of them tested. The board looks like progress; the product is unchanged.

The deeper problem is that agents are optimizing for task completion as a signal, not for working software as an outcome. A gate interrupts that optimization and forces the agent to produce evidence — a CI run URL, a deploy confirmation, a smoke-test result — before it is allowed to call something finished. Without that evidence requirement, “done” is a fiction the agent tells itself.

amux's board distinguishes done (implemented and merged) from verified (confirmed working in production with CI, deploy, and smoke-test evidence). This prevents false completion status from accumulating silently across a team of parallel agents. The stale-doing detector catches a different failure: tasks that get claimed by an agent and never updated, which are silent abandonment rather than silent completion.

Cost gates — prevent runaway token spend

A coding agent stuck in a bad loop will spend tokens indefinitely. A recursive refactor loop, a test-fix cycle that keeps generating new failures, or an agent that cannot find a file and keeps retrying can exhaust a Claude Max monthly budget in a single overnight run if nothing stops it.

amux tracks per-session token usage in real time, parsed from the JSONL transcript each session writes. The usage is visible on every session card in the dashboard. Set a per-session token kill threshold in Settings → Session Limits; the watchdog process terminates any session that exceeds the limit and logs the termination event with timestamp and token count.

# Check token usage for all active sessions
curl -sk https://localhost:8822/api/sessions | python3 -c "
import json, sys
for s in json.load(sys.stdin):
    tokens = s.get('tokens_used', 0)
    limit  = s.get('token_limit', 'none')
    print(f\"{s['name']:20s}  {tokens:>8,} tokens  limit={limit}\")
"

Cost gates pair with the scheduler: long-running batch sessions can be given a budget for the run, not just the session lifetime, so a nightly job that normally costs 50k tokens is automatically killed if it reaches 200k — a signal that something has gone wrong.

Context gates — prevent context overflow crashes

Claude Code sessions crash when their context window fills up. In a long-running unattended session — overnight refactors, multi-file migrations, test generation at scale — context overflow is the most common failure mode. Without intervention, the session dies silently at 3am and no one is there to restart it.

amux's watchdog monitors context usage on each session and intervenes before overflow. When usage crosses a configured threshold, the watchdog pauses the agent, sends a /compact command to Claude Code, waits for the compact to complete, and then resumes the session with the agent's last message — making the intervention transparent to the developer. The session loses no work; it just continues with a compressed context.

# Context auto-compaction is enabled by default. Monitor it:
curl -sk https://localhost:8822/api/sessions/myproject | python3 -c "
import json, sys
s = json.load(sys.stdin)
print('context_pct:', s.get('context_pct', 'n/a'))
print('compactions:', s.get('compaction_count', 0))
"

If a session crashes despite compaction — an edge case where the compact itself overflows, or the process dies for an unrelated reason — the watchdog restarts it with --resume so the conversation continues from the last checkpoint rather than starting cold.

Action gates — human approval for irreversible operations

Some agent actions cannot be undone: pushing to a shared branch, deleting a database record, sending an email, calling a paid external API, or clicking “deploy” in a production dashboard. Action gates are the mechanism that puts a human between the agent and those consequences.

amux supports two modes per session:

• Gated mode (default): each action that Claude Code would normally prompt for requires explicit human approval before proceeding. The permission prompt is queued and surfaced in the dashboard and iOS app.
• YOLO mode (--yolo): all per-action prompts are auto-approved. The agent runs fully unattended. Use this for isolated environments with no irreversible side effects.

Phone approval via iOS app: When a session is in gated mode and the agent reaches a step requiring approval, the prompt appears in the iOS app's session view as a pending action card. Tap Approve or Deny from anywhere. The agent is blocked until you respond — it does not time out and move on. This means you can run a gated session overnight and wake up to a single approval request rather than a completed (or broken) run.

# Register a session in gated mode (omit --yolo)
amux register myproject --dir ~/Dev/myproject

# Or switch an existing session between modes at runtime:
# YOLO on:  amux start myproject --yolo
# YOLO off: amux start myproject   (no --yolo flag)

The browser automation layer — amux's Playwright integration and the Computer Use agent — adds a per-automation allow_irreversible: false flag. When set, the automation blocks on any step classified as destructive (form submission, file deletion, payment action) until the operator explicitly approves that step. This is independent of Claude Code's permission system and applies even in YOLO mode.

Outcome gates — board gates for evidence-based completion

Outcome gates are the highest-value gate category: they enforce the distinction between “the agent thinks it is done” and “a human can confirm it is done.” amux's board implements this with three task states and explicit gate conditions that must be acknowledged before advancing.

The three states

• doing — actively being worked on by an agent or human. Only one task per session should be doing at a time.
• done — implemented and merged. Gate conditions: “Implemented and merged” + “Tests / lint pass.” This is not deployed and not confirmed in production.
• verified — confirmed working in production. All four conditions must hold, with evidence recorded: CI pipeline green on the merged commit, deployed to production, smoke-tested in prod, zero regressions.

Agents cannot advance a task from doing to done by setting the status field alone — the gate checkboxes must be acknowledged in the API call. The same applies for done to verified. This prevents an agent from bulk-completing tasks at the end of a run without actually checking whether any of the conditions are met.

# Advance to done (agent must acknowledge both gates)
curl -sk -X PATCH -H 'Content-Type: application/json' \
  -d '{
    "status": "done",
    "gate_checked": ["Implemented and merged", "Tests / lint pass"],
    "desc": "PR #142 merged. CI passed on sha abc1234."
  }' \
  https://localhost:8822/api/board/TASK-123

# Advance to verified (all four production gates required)
curl -sk -X PATCH -H 'Content-Type: application/json' \
  -d '{
    "status": "verified",
    "gate_checked": [
      "CI / CD green on merged commit",
      "Deployed to production",
      "Smoke-tested in production",
      "Zero regressions"
    ],
    "desc": "Verified in prod: CI run https://... green; deployed sha abc1234; prod smoke passed; no regressions in health checks."
  }' \
  https://localhost:8822/api/board/TASK-123

Stale-doing detector

A task stuck in doing with no progress update is a different failure mode: silent task abandonment. An agent claims a task, hits an obstacle, and stops updating the board — but the task stays in doing indefinitely, blocking other agents and creating false signals about session activity.

amux's stale-doing detector flags tasks held in doing beyond a configured interval without a description update. These appear as warnings in the dashboard and the iOS app's board view. The flag does not automatically reassign the task; it surfaces the problem for human review so a different session can be assigned or the task can be reset to todo.

Shepherd / executor split

The session that creates a board task (the shepherd) is tracked separately from the session that executes it (the executor). This accountability split matters when tasks are delegated across sessions: you can see at a glance which session is responsible for the outcome versus which session is doing the work. It also enables the stale-doing detector to notify the shepherd when the executor goes silent.

amux quality gates vs. alternatives

Setting up quality gates in amux

Step 1: Install amux

brew install mixpeek/amux/amux
# or: git clone https://github.com/mixpeek/amux && cd amux && ./install.sh

Step 2: Register your project in gated mode

# Gated (default) — each action prompts for approval
amux register myproject --dir ~/Dev/myproject

# YOLO — auto-approve everything (isolated environments only)
amux register myproject --dir ~/Dev/myproject --yolo

Step 3: Set a token kill threshold

Open the amux dashboard at https://localhost:8822 → Settings → Session Limits. Set a max token budget per session. The watchdog terminates sessions that exceed it and logs the event with the token count and timestamp.

Step 4: Connect the iOS app for phone approval

Install amux – Agent Multiplexer from the App Store. Enter your amux server address in the app. Pending permission prompts from all active sessions appear in the app; tap to approve or deny from anywhere.

Step 5: Mark tasks done with gate acknowledgment

# Via CLI
amux board done TASK-ID --gate "Implemented and merged,Tests pass"

# Via API (more explicit)
curl -sk -X PATCH -H 'Content-Type: application/json' \
  -d '{"status":"done","gate_checked":["Implemented and merged","Tests / lint pass"],"desc":"PR merged, CI green"}' \
  https://localhost:8822/api/board/TASK-ID

Step 6: Verify in production before marking verified

curl -sk -X PATCH -H 'Content-Type: application/json' \
  -d '{
    "status": "verified",
    "gate_checked": [
      "CI / CD green on merged commit",
      "Deployed to production",
      "Smoke-tested in production",
      "Zero regressions"
    ],
    "desc": "Verified: CI run https://ci.example.com/123 green; deployed sha abc1234; prod smoke passing; no regressions."
  }' \
  https://localhost:8822/api/board/TASK-ID

When to relax gates (YOLO mode)

YOLO mode exists because not every agent action needs a human in the loop. The right trade-off depends on the reversibility of the side effects:

• Use --yolo for: greenfield projects with no production surface, test environments with no external dependencies, isolated feature branches where a bad push is easy to revert, documentation generation, pure read-only analysis tasks.
• Keep gates enabled for: anything touching a shared repository, external APIs (billing, email, third-party services), production databases, deployment systems, or any operation where the cost of a mistake exceeds the cost of an approval tap.

The principle is: the more irreversible the side effect, the stronger the gate. YOLO mode is a deliberate opt-in to “I trust this agent with everything in this session.” Gated mode is the default because most agents should not have that level of trust by default.

YOLO can also be toggled per-session from the dashboard without stopping and restarting the session — useful when a trusted batch run needs human sign-off on one specific step and then wants to continue unattended.

Frequently Asked Questions

git clone https://github.com/mixpeek/amux && cd amux && ./install.sh
amux register myproject --dir ~/Dev/myproject
amux start myproject
amux serve  # → https://localhost:8822 — open Board tab

Related guides

• Getting started with amux
• Running 10+ parallel AI coding agents
• Self-healing AI agent configuration
• amux vs DIY tmux
• Claude Code documentation (Anthropic)