A gate that rejects a patch is only half a policy. The other half is what happens after the rejection. In most pipelines, a failing agent patch produces one of three outcomes: a human stares at the log, the patch is rebuilt blindly, or the test is deleted. All three are wrong in different ways.
This article is a decision procedure instead. It classifies every rejected patch into one of three failure classes, assigns one action to each class, and keeps a quarantine ledger with an expiry date. The reproducible artifact is triage_gate.py: a small script that re-runs the failing test, compares fixture hashes, and freezes only the flakes.
The three failure classes
An agent patch fails CI for a reason. The reason is rarely "the code is bad" in the abstract sense. Every failure I have triaged lands in one of three buckets:
Class A — deterministic regression. The test fails on the first run and on every re-run. The assertion fails with the same input each time. This is the only class where the agent's code is the primary suspect.
