Re-Contact-Subtracted Resolution Gate

also known as Deflection-Minus-Re-Contact Resolution, True Resolution Rate Gate

Gate a support agent on a re-contact-subtracted resolution rate so an interaction that merely ends the session is never reported as a resolved one.

This pattern helps complete certain larger patterns —

specialisesEval as Contract★★— Treat the eval suite as the contract the agent must satisfy; releases ship only if evals pass.

Context

A customer-support or contact-center agent fields conversations and the team reports a containment or deflection number to justify the deployment. Deflection is trivial to register: the moment the user stops replying, the session closes and the dashboard counts a handled ticket. The agent can drive that number up by stalling, looping, or pushing the user away, and a low CSAT survey response rate hides the damage. The number that matters — whether the underlying problem was actually solved — is invisible at session-end and only shows up days later when the same customer comes back.

Problem

Session-end is a cheap proxy for resolution, and any metric the deployment is optimised against will be gamed once it becomes the target. A bot that answers wrong, or wears the user down until they give up, looks identical on a deflection dashboard to one that genuinely fixed the issue. Reporting raw deflection or containment as quality therefore rewards exactly the behaviour that erodes trust, and the team cannot tell a good deployment from a harmful one until churn surfaces. The gate needs a definition of resolution that the agent cannot inflate by ending conversations.

Forces

Deflection and containment are measurable in real time and look like progress, but they register at session-end, before it is known whether the problem was solved.
The one signal that resists gaming — the customer not coming back for the same issue — is only observable after a delay, so it cannot gate the live response.
A correctness check on the answer catches confidently-wrong replies, but it cannot catch a user who was simply worn down into leaving.
Conditioning the gate on CSAT exposes survey-response bias, since the unhappy customers are the ones least likely to answer.

Example

A support agent reports 70 percent deflection, and leadership is ready to expand it. Monitoring then links re-contacts: of the deflected tickets, 12 percent got a wrong answer that a sampled correctness scorer flags, and another 18 percent reach back out within 48 hours about the same problem. The gated rate is (70 − 12 − 18) / 100 = 40 percent true resolution. The expansion is held: the agent was closing sessions, not solving problems, and the raw deflection number had hidden that for weeks.

Diagram

flowchart TD H[Handled interactions] --> D[Deflected: session ended] D --> S1[subtract wrong answers\ncorrectness scorer] S1 --> S2[subtract re-contacts\nwithin 48h window] S2 --> C{CSAT floor met?} C -- no --> X[not counted resolved] C -- yes --> R[Gated resolution rate] R --> G[gate release / rollout]

Solution

Therefore:

Stop treating session-end as success. Define the gated rate as (deflected interactions − wrong answers − re-contacts within a fixed window such as 48 hours) divided by total handled interactions, and optionally condition it on a CSAT floor so worn-down departures are not counted as wins. Wrong answers come from an automated or sampled correctness scorer; re-contacts come from production monitoring that links a later conversation back to the same customer and problem. Deflection and containment stay on the dashboard, but only as raw throughput labelled as such — never as a quality claim. Releases and rollouts are gated on the subtracted rate, so an agent that drives deflection up by stalling, looping, or answering wrong sees its gated number fall, removing the incentive to game session-end.

What this pattern forbids. An interaction is not counted resolved on session-end alone; deflection without a verified resolution must not be reported as success, and the gated rate subtracts wrong answers and within-window re-contacts.

The smaller patterns that complete this one —

usesScorer Live Monitoring★— Score agent outputs asynchronously in production with non-blocking scorers that observe, alert, and log but do not regenerate the output.

And the patterns that stand alongside it, or against it —

complementsReward Hacking✕— Anti-pattern: optimise the agent against a single proxy metric and assume the metric remains a faithful proxy after optimisation pressure.
complementsFalse Resolution✕— The agent proposes a compromise that addresses each constraint individually but subtly violates one in joint interpretation, shipping as success but discovered as failure at audit.