The agent had permission. It did not have the current task.

A developer writing on dev.to did the unglamorous work of defining what an agent may read, what it may write, and what needs a human, then edited a task while the agent was still setting up and discovered the permission model had nothing to say about it ^{[17] [3]}. This is the failure mode most agent deployments are not instrumented for: the authority is valid, the scope is correct, and the instructions are out of date ^[4].

The mechanics are worth stating plainly. A handoff carries a task definition, a scope, and the conditions that count as done ^[2]. Permission levels answer the question of what this agent may do; they are silent on what happens when the task itself changes after the grant ^[1]. In the incident described, the edit was a comment that changed what "done" meant ^[3]. Static levels cannot catch that, because the agent is doing exactly what it was allowed to do against a version of reality that had just been replaced ^[5].

The author rejects the obvious mitigation, having the agent check in when something looks off, for two reasons. From inside the handoff there is no ambiguity to see: the stale task reads as complete, the scope is clear, the acceptance conditions are stated, and the only defect is that a newer version exists somewhere else ^[6]. And an agent that escalates on vague uncertainty rebuilds the bottleneck delegation was supposed to remove, while training the human to approve without reading ^[7]. So the check has to be mechanical and fire at a specific moment rather than run continuously ^[8].

Four steps. Bind the task revision at dispatch, so the handoff record states which version it authorizes rather than only the contents ^[9]. Treat every authority-bearing input as part of the task, which means a comment that alters acceptance criteria bumps the revision exactly as a body edit does, or the mechanism misses the class of change that motivated it ^[10]. Re-read the live task immediately before every write, starting with the first, not at plan time and not at claim time ^[11]. If the live revision differs from the bound one, stop: do not re-plan, do not merge the versions, do not ask which to follow ^[12]. Return a typed result so the dispatcher can distinguish a safe stop from a crash ^[13].

Step three is the load-bearing one, and the argument for it is about authority, not caution. Re-planning against the new text would mean the agent granted itself authority for a question no human had handed it, which is the exact thing the structure exists to prevent ^[14]. Stopping is the agent declining to promote itself ^[14].

Two consequences follow from the design rather than from the post. Detection happens only at write boundaries, so a task with three writes gets three checks [c-d1], and everything between dispatch and the first write proceeds against text that may already be superseded [c-d2]. That is an acceptable trade if writes are where damage lives, and a bad one if the agent's reads are themselves side-effecting.

The published sketch is small: a Task with an integer revision, a store whose edit path increments it, a frozen Handoff holding the bound revision and the body at dispatch, and result types for written and stopped-stale ^[15]. The author calls it a sketch rather than a production system, though he says every line runs ^[16].

What to watch is whether your task system can support the first step at all. Most trackers version the body and treat comments as a separate stream, and if a comment can change acceptance criteria without moving a revision counter, the bound-revision check will pass while the agent works from the wrong definition ^[10]. The second thing to watch is the dispatcher side: a typed stop that gets retried automatically is a stale write with extra steps ^[13].