Agent executes a gated workflow out of order on task transition: enforcement state left pointing at the completed prior task goes inert, and the agent free-styles step order
Filing on behalf of a paying user after a recurring, reproducible failure. Proprietary product details omitted.
Setup
The agent operates under a stateful, gated workflow: each task has an ordered step-plan with human-approval gates (e.g. "produce + approve the test plan BEFORE capturing reference data"). A small "lock" file points a PreToolUse enforcement hook at the ACTIVE task's plan and the step it is authorized through. The agent is intentionally blocked from editing the lock (owner = human only).
The failure
On transitioning to a NEW task, the agent did NOT instantiate the new task's step-plan, and the lock was left pointing at the PREVIOUS task's plan — which was already complete and authorized through its final step. Consequences:
- The enforcement hook, pointed at a completed plan, saw "fully authorized" and imposed zero sequence constraint on the new task. The gate was silently inert.
- With no plan instantiated for the new task, the agent could not run its own mandated "next-step" check (it needs a plan file to check against).
- So the agent drove from a remembered pattern of the prior task plus forward directives, and executed steps out of order — performing an expensive capture step and a later wiring step before producing the required planning artifact and before the human-approval gate. It then built the planning artifact retroactively, after the fact.
The human had to catch this manually, twice.
Why it keeps happening
This out-of-order / skipped-step class has recurred multiple times despite (a) explicit process rules requiring first-incomplete-step-only execution and (b) the PreToolUse enforcement hook. The reason: the rules and the hook only constrain behavior when the active task's plan is instantiated and the lock points at it. Neither enforces the one transition where the gate goes inert — task start, where the new plan must be created and the lock re-pointed. A stale lock silently disables enforcement, and the agent does not self-detect that its own gate is pointing at a finished task.
Core problems to investigate
- The agent does not detect that its gated-workflow enforcement is pointed at a completed task (therefore inert) and proceed anyway, instead of halting to instantiate the new task's plan first.
- Step-order discipline degrades when the agent works from memory + forward directives rather than from a live, gated plan — it follows "what comes next in the pattern / what I was told to do next" instead of "the first-incomplete step the workflow permits."
- Enforcement that depends on per-task state which only a human can refresh will silently fail open on task transition unless the agent treats "no active plan for the current task" as a hard stop.
Request
A self-check at task boundaries: if the agent is about to act on a task whose gated plan is absent or whose enforcement lock points at a different/completed task, it should HALT and instantiate the plan before any substantive step — rather than free-styling the order and discovering the skip only when the human objects.