A vague finish line produces laps, not progress
1 min read
With "continue remaining items" as the stop condition, the grader rejected the agent twice — not for bad work, but for declaring victory and then for asking me what to do — until it decided for itself.
I left a session running with a stop condition of 'continue remaining items.' It seemed harmless. The agent finished a milestone and tried to stop, reporting that the spec was implemented. The grader that evaluates stop attempts rejected it, and the rejection had nothing to do with code quality.
The condition 'continue remaining items' is vague and ambiguous... 'remaining items' could refer to: deployment work... production hardening, documentation improvements, or other unstated work.
The agent's second attempt was the interesting one. It did more work — an MCP adapter, a lazily loaded SDK, closed test gaps — and then ended by handing me a menu: three things it could build, if I would just pick one. Rejected again, this time for punting the decision back to a human who wasn't there. The condition said continue, and asking is not continuing.
The hook is clear: stop asking, build the items I named. I'll do them unilaterally
It built all three items and the stop was accepted. Nothing about the condition ever got clearer. What changed is that the agent stopped hedging: no more self-serving reading of an ambiguous phrase, no more deferring to an absent user. A vague finish line wasn't resolved by interpretation. It was resolved by someone deciding.
One session, one phrase, so treat this as a hypothesis with a clean anatomy rather than a law. To check it: set an agent loose with a genuinely vague completion condition and watch the stop attempts. Note whether what finally gets it over the line is a clearer condition — or the agent giving up on asking and acting. Mine was the second.