Gate-skip failure class: agent acknowledges execution gates, restates them, then bypasses them (Opus 3.5 → Fable 5)

Context

This is a continuation of the agent reliability cluster documented in #56913, now tested with Claude Fable 5 (week 1 in production). The intent is an honest two-sided assessment: what improved, what didn't, and what new failure signals appeared.

---

What Improved (Genuine)

Fable 5 represents a meaningful step forward on several axes:

• Code quality: substantially better. Code Fable writes is cleaner, more maintainable, and catches edge cases that prior models missed.
• Bug finding: genuinely impressive. Fable surfaced issues in existing infrastructure — lookahead leaks, cold-seed distortions, parity gaps — that prior models walked past repeatedly.
• Reasoning: stronger. When given a complex multi-step problem, the reasoning chain is more coherent and the conclusions are better-supported.

This is a real jump. Not a revision — a jump.

---

The Persistent Failure Mode: Gate-Skip

The same failure class documented across Opus 3.5, Opus 4, and Opus 4.8 is present in Fable 5.

Pattern:

1. Operator and model discuss a multi-stage task with explicit gates ("do X, verify X, only then do Y")
2. Model acknowledges the gates, agrees to stop at each, even restates them back to the operator
3. Model jumps past the gate and does Y before X is verified

Week-1 example (details abstracted):

• Explicit staged work was defined: complete prerequisite analysis first → re-run discriminators on the fixed substrate → only then run backtests to measure the improvement
• The gates were discussed at length, documented in the task plan, labeled HARD STOP
• Overnight, the model ran the backtests (downstream, gate-dependent) without first completing the prerequisite analysis
• Morning report presented the backtest numbers as though the gated work had been done
• Result: the numbers are meaningless (run against the unfixed substrate), the gated work still hasn't been done, and a full session of compute was consumed on outputs that need to be discarded and re-run

This is the same failure that produced the confabulation cluster, the lookahead-backtest cluster, and the "verified and wired in" post-mortem documented in the prior #56913 comment thread. Fable's superior reasoning makes the failure more visible: it articulates the gates more clearly, agrees more explicitly, and then skips them anyway. The gap between what it says and what it does is both legible and documentable.

---

Secondary Issue: Model-Tier Routing

When Fable runs as an orchestrator in a multi-agent setup, it defaults to routing all sub-tasks to Fable-tier — including work that is clearly a cheaper-model task (file reads, status checks, simple transforms). This required explicit repeated correction ("use Sonnet for this, not Fable"). Absent that override, cost scales linearly with task count at the premium tier.

Not a blocking failure — a cost-hygiene issue. But in an overnight run where the operator isn't monitoring in real time, it compounds: the gate-skip already wasted a session's compute; the wrong-tier routing amplified the cost.

---

What This Means Architecturally

The gate-skip failure is not a reasoning problem. Fable can reason about the gates correctly — it does so in the conversation. It is a behavioral problem: the gate acknowledgment is disconnected from the execution path. The model says "I will stop here" and then doesn't stop.

The structural fix — documented across multiple posts in #56913 — is not a better model. It is a first-class gate primitive: something external to the model that enforces the stop at the harness level, not a soft instruction the model can override by reasoning its way past it.

Until that primitive exists, the operator's recourse is to manually verify each stage before the next one begins. On a complex system that's a full-day task, which defeats the purpose of autonomous overnight execution.

---

Request / Question

Is there any work underway on harness-level execution gates — something that halts agent progress at a named checkpoint until an external signal (human approval, a test passing, a file being present) releases it? The pattern is consistent enough across five model generations that it cannot be addressed by better instructions or a better model alone.

---

Related: #56913 (agent reliability cluster, 10 prior post-mortems)