A Green Gate Is Not Enough: Finding False Passes and False Fails

A green gate can still be wrong in two directions: it can approve broken output, and it can reject healthy output. If you only count successful passes, you cannot tell whether the gate is reliable.

Two errors hidden by one green light

Automated gates are usually built around one question: is this output acceptable? But the quality of the gate itself also needs evaluation. A false pass occurs when the real output is broken but the gate says Pass. A false fail occurs when the real output is healthy but the gate says Fail. Both errors can exist in the same gate at the same time.

In one internal TekeraLab incident, we found and patched causes of both error directions in a durability gate. The system details are not public, but the lesson is general: a run of green results proves neither the gate’s sensitivity nor its precision.

Build a 2×2 decision matrix

Every gate run contains two facts: the true state of the output—healthy or broken—and the gate’s decision—Pass or Fail. Their combination produces four cells: true pass, true fail, false pass, and false fail.

Without an independent ground truth, you cannot know which cell a result belongs to. Before tuning thresholds, create a small labeled evaluation set. Healthy samples should be independently verified; broken samples should contain specific, reproducible defects.

Use positive and negative controls

A positive control is a stable healthy output that the gate should always pass. A negative control is an intentionally broken output that the gate should always fail. Create at least one pair for every important rule—for example: file present versus missing, HTTP 200 versus 500, complete versus truncated text, or a correct versus malformed tool call.

Run both controls after every change to the prompt, parser, model, data source, or threshold. Testing only the happy path can hide false passes. Testing only broken cases can hide false fails.

Do not collapse every failure into one score

Microsoft Agent Framework separates dimensions such as task adherence, task completion, tool selection, and tool-call accuracy. That separation matters. An agent may select the right tool but provide the wrong arguments, or complete the task while violating a user constraint.

Use mechanical tests for deterministic facts, a limited rubric for open-ended quality, and human review for high-impact actions. A single vague score hides the source of failure and makes repair harder.

Official reference: https://learn.microsoft.com/en-us/agent-framework/agents/evaluation

What should a durability gate prove?

Durability means the gate’s decision remains dependable across restart, retry, stale cache, and repeated execution. Version the evaluation input, attach every decision to an evidence ID, and ensure a retry reproduces the decision without creating duplicate side effects.

Before deployment, run a two-sided regression suite. After deployment, run the same controls in production or shadow mode. If either false-pass or false-fail rate crosses its threshold, the gate must not remain the final release authority.

A practical gate-review checklist

Ask six questions:

• Is ground truth independent from the system being evaluated?
• Do we have both healthy and broken controls?
• Can we trace the reason for every Pass or Fail?
• Are model, prompt, parser, and threshold changes versioned?
• Do retry and restart reproduce the same decision?
• Does a high-impact action still require the correct human approval?

If any answer is unclear, the green light is not sufficient evidence. Treat the gate itself as a product that must be tested.

Short answers

What is a false pass in an AI agent gate?

The output is actually broken, but the gate labels it Pass. The defect is allowed into the next stage.

What is a false fail?

The output is healthy, but the gate labels it Fail. This increases retries, queue delays, and unnecessary human intervention.

How do you test an AI agent evaluation gate?

Use independently labeled healthy and broken samples, run paired positive and negative controls, and track false-pass and false-fail rates separately.

Conclusion

Trust does not come from the number of green runs. It comes from knowing the rate and cause of both false passes and false fails. Evaluate every gate with two-sided controls, independent ground truth, traceable evidence, and durability tests.