Handling a failed call

On a live call you cannot throw an exception and be done. Eliminating failure is not an available goal; choosing how you fail is. Stepping a capability down beats dropping the call, and saying you do not know beats saying the wrong thing confidently.

Telling apart what wavered

Handling every failure the same way blunts the response. A vendor degrading, a capability of ours sitting in an uncertain state, and the caller's connection dropping are three different events, and each needs different handling.

While the call is running

When a vendor wavers

Speech synthesis depends on an outside vendor. When one degrades mid-call, the rest of that call moves to another provider and stays there. Swapping every sentence would be stranger than the degradation itself, so once a call fails over, it stays failed over.

When a capability is uncertain

When one of our own capabilities is uncertain, a flag steps it down. The flags guide covers that level structure in detail. What matters here is that the call continues in the stepped-down state.

After the call ends

A failed call still leaves a record. What ran in a stepped-down state has to be in it, or the same judgement gets made again in the same place next time.

• Check which stage stepped down, and whether the call held to the end.
• Read the transcript back for what changed on the caller's side — following the transcript review guide.
• When a pattern repeats, mark the settings rather than the flow as what to adjust.
• When the decision is about deployment scope, support is where the next step is.

This is not a claim that the pipeline does not die. It does. We only tried to choose how.