Voice agents need three exits, and a config flag only builds one

The boolean fails because the trigger and the exit are two separate decisions, and one flag collapses them into a single yes. Three exits crossed with four firing sources is a twelve-cell routing table ^[1], and each cell needs a decided answer before the booking path is worth writing. The same stranded-driver trigger at two in the afternoon and at two in the morning is not the same exit, because the live transfer depends on a specific human being available that second, which the author calls the exit with the most ways to fail ^[6]. Outside business hours it is not available at all, so taking a structured message and firing an alert becomes the only exit that works, and that is the one the piece says gets skipped ^[7].

The refusal exit is not a degraded version of the other two. For a medical clinic, the reported instruction is that anything reading as symptoms or advice is not the agent's job at any confidence level ^[12], which puts it outside the reach of model improvement: a better model does not turn clinical advice into a happy path, it makes the wrong answer more fluent. The same holds for price negotiation and fair housing at a brokerage ^[8]. What that path needs is a firm answer and a channel to point at, not a graceful one ^[8].

The repair-loop trigger is where the engineering cost actually sits, and it explains why so many implementations stop at keyword lists ^[17]. Content matching is stateless: one utterance, one lookup. Detecting that a call is simply going badly needs state the keyword path never keeps, such as how many times the same thing has failed to land and how long the call has run against the length that kind of call should take ^[19]. The explicit-request rule carries the same requirement, because "if they ask twice, it should already have happened" is a counter, and it has to be wired at every node in the flow rather than at one menu ^[18].

The elicitation question is the cheapest part of all this and the most portable. Asking a client which calls, handled badly, would make them switch the thing off tomorrow returns answers that are short and specific ^[9], and "never let a stranded driver sit through a booking script" is testable in a way that "handle our calls" is not ^[15]. One of those is a recorded call you can replay against the flow. The other is a mood.

Worth being clear about the evidence: this is one practitioner writing on dev.to, describing deployments in hospitals, vet clinics, garages and brokerages, with no call-level counts attached ^[2]. The assertion that repair-loop detection catches more calls than any other trigger ^[19] is experience rather than measurement, and it is the one most worth instrumenting, since it decides whether the extra per-call state is worth carrying at all.