Checkpoint fatigue causes operators to hand over control, leading to high-impact autonomous errors

[mrhobbeys]

MY NUMBER ONE PET PEEVE RIGHT NOW

Please post in the replies if you run into this outside of a completed task. I want to figure out if this ever happens in the middle of a task without a good reason.

The failure

On projects with many small sequential tasks, the agent stops at every atomic boundary to report completion and wait for operator input. This is correct behavior per the Atomicity mechanism. However, when the project has 10+ tasks in a phase, the repeated stop-start cycle creates operator fatigue.

In one specific case I got so annoyed I said something like "keep going without me until you really need me."

The agent then executes autonomously across multiple tasks. In observed runs, it gets 80-90% of the autonomous work correct. But the 10-20% that's wrong has outsized impact because no human gate caught it in real time, and the errors compound across dependent tasks before the operator reviews.

How to reproduce

1. Scaffold a project with 10+ tasks in a single phase, most of which are straightforward.
2. Execute tasks one at a time, stopping at each completion boundary.
3. After 4-5 stop-start cycles with minor or no corrections needed, the operator will naturally want to say "just keep going."
4. Allow autonomous execution across the remaining tasks.
5. Review the output. Observe that most tasks are correct but 1-2 contain errors that propagated into downstream work.

Expected: Task checkpoints hit a cadence which is comfortable for the operator and often enough to catch errors before they compound, but not so often the operator is annoyed.
Actual: Checkpoint frequency exceeds operator patience, operator disengages, errors slip through.

Root cause

There is no middle ground between "stop at every task" and "run unsupervised." The Atomicity mechanism treats all tasks as equal — each one gets the same stop-and-report cycle regardless of complexity or risk. A trivial formatting task gets the same ceremony as a task that rewrites core messaging.

Proposed fix: Batched Review Mode

Add a delivery mode option in config that allows the agent to execute multiple tasks autonomously while preserving verification evidence for bulk operator review:

1. Risk-based checkpoint cadence. Tasks already have a risk_level field (standard / elevated / critical). Use it: critical tasks always stop for operator review. Standard tasks can be batched. Elevated tasks stop if they produce discoveries.

2. Deferred verification bundle. When running in batched mode, the agent completes each task's verification checklist and evidence trail as normal, but instead of stopping, it appends a summary to a REVIEW-BUNDLE.md file. When it hits a critical task, a phase boundary, or the end of the batch window, it stops and presents the bundle: "I completed tasks 04-08. Here's what I did, here's the evidence, here are the 2 things I'm uncertain about."

3. Batch size cap. Maximum N tasks (configurable, default 5) before a mandatory operator checkpoint, regardless of risk level. Prevents unbounded autonomous runs.

This preserves Atomicity (each task is still binary done/not-done with evidence) while reducing the stop cadence to match operator workflow. The human gate shifts from "per-task real-time review" to "per-batch evidence review."

Mechanisms involved

• Atomicity (primary) — the stop cadence is correct but creates fatigue at scale
• Verification (primary) — evidence trails exist but aren't bundled for deferred review
• Lock (secondary) — batched execution must still respect Lock (one task active at a time, sequentially, just without stopping between each)