> ## Documentation Index > Fetch the complete documentation index at: https://docs.roark.ai/llms.txt > Use this file to discover all available pages before exploring further. # Interruption handling > Run one flow with callers who never interrupt, who only make listening noises, and who talk over your agent export const property_0 = "caller interruption" ## Why this is a common failure point Turn-taking is the hardest part of a voice conversation to get right. People say "mm-hm" while listening, cut in to correct a detail, and start talking before the agent has finished. An agent that stops at every listening noise sounds broken; one that talks straight through a correction books the wrong thing. Scripted test callers wait politely for their turn, so neither failure shows up in testing. ## How Roark tests it Interruption handling runs the same flow with callers who interrupt more and more, from never to constantly. It grades both directions of every overlap: whether the agent stopped when it should have (and kept going when it should have), and whether it cut the caller off. It is a **property sweep**: every value runs the same flow with everything else held the same, and the report tells you which values did worse than the rest and which differences are just chance. *** ## The values | Value | | | :--------------- | :----------------- | | Never | Suggested baseline | | Backchannel only | | | Occasional | | | Heavy | | **Backchannel only** callers make listening noises ("mm-hm", "right") without trying to take the turn, so the agent should keep talking. **Occasional** and **Heavy** callers genuinely cut in. *** ## What it measures The template seeds these, and your flow's own metrics run alongside them. Only checks can mark a value **Worse on**; the other measures explain why. | Measure | What it tells you | | :--------------------------------------------- | :------------------------------------------------------------------------------------------------------------------- | | **Incorrect Agent Interruption Count (check)** | The agent talked over the caller when it shouldn't have. The check allows one per call. | | **Incorrect Barge-in Yield Count (check)** | The agent stopped for a listening noise, or kept talking through a real interruption. The check allows one per call. | | **Agent Cutoff Count (check)** | The agent cut the caller off mid-sentence. The check allows one per call. | | **Interruption Appropriateness** | Whether each time the agent cut in was the right moment. | | **Barge-in Yield Appropriateness** | Whether the agent stopped, or didn't, correctly each time the caller cut in. | | **Incorrect Barge-in Yield Rate** | The share of caller interruptions the agent handled wrongly. | | **Failed Barge-in Rate** | The share of caller interruptions the agent talked straight through. | | **Customer Barge-in Count** | How often the caller cut in. | | **Agent Interruption Count** | How often the agent cut in. | | **Call Outcome** | Whether the call ended where it should. | *** ## What to look for * **Backchannel only is the trap.** An agent that stops every time it hears "mm-hm" fails here and nowhere else. Barge-in yield failures on this value point at over-sensitive turn-taking. * **Rates, not counts.** A Heavy caller interrupts far more often, so counts rise by construction. The rates say whether each interruption was handled worse. * **A single slip never fails a call.** Every check allows one mistake per call, so a value marked worse means repeated mishandling. *** ## Setting one up Pick the flow to test, then the values to run it across. Every value starts selected; deselect the ones you don't need. Each value runs your flow again, so the values you keep are the cost of the run. **Compared against** sets the baseline: a reference value the report pins first, such as silence for background noise. The template suggests the natural one, and you can change it or choose none. It doesn't change the verdict: whether a value did worse is always decided against every other value combined. **Iterations** live in the sweep panel rather than in Advanced. Each value runs every attached test case once per iteration: > **Calls per value = test cases x iterations** Each value needs **at least 5 calls** to be compared with the others, and the Iterations field won't go below the count that reaches it. It starts at 6 calls per value, so one call [excluded after the run](/documentation/simulation-testing/running-simulations#calls-that-dont-count) doesn't drop a value out of the comparison. More calls let the report see smaller differences. For a sweep of 10 values: | Calls per value | A value has to be about this much worse to be flagged | Calls in total | | :-------------- | :---------------------------------------------------- | :------------- | | 5 | 50 percentage points | 50 | | 10 | 35 percentage points | 100 | | 20 | 25 percentage points | 200 | | 30 | 20 percentage points | 300 | Below 5 calls a value can never be flagged, however badly it does, which is why the minimum is enforced rather than suggested. Over the API, a sweep template defaults `iterationCount` to 6 and refuses a plan with fewer than 5 calls per value with a `400`. *** ## How the results are decided The sweep's table leads the run report. Its **Compared with the rest** column gives each value one result: | Result | What it means | | :---------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Worse on** *check* | The value failed that check more often than all the other values combined, by a gap too large to be chance. | | **No difference** | Any gap is within what chance produces with this many calls. That is not proof of no effect: a small run can only see large gaps, and the report says how large when that matters. | | **Too few calls** (*n*) | Fewer than 5 counted calls, so the value is shown but not compared. | | **Not graded** | The value ran, but none of its calls were graded. | How "too large to be chance" is decided: * Each value is compared with **all the other values combined**, one check at a time, never with a single other value. Two values that happen to land at opposite ends are not a finding on their own. * A sweep makes many comparisons at once (every value on every check), and some will look different by luck alone. The report accounts for that: of all the values it flags in a run, **at most 1 in 10 is expected to be a fluke**. * A value is flagged only when it does **worse**. Doing better than the rest is not a problem to fix. **Checks passed** shows each value's pass rate with the number of calls behind it, so 100% of two calls never reads like 100% of twenty. A lower rate with **No difference** beside it means the gap is not larger than chance. **Fails, not {property_0} specific.** A check that fails on **at least 20% of calls** with no value standing out is listed under this heading. It is a real problem, just not one {property_0} caused, so changing {property_0} won't fix it. Select the check to open its evidence. The executive summary follows the same rules: it only blames the property for failures the table marks **Worse on**. Hover **How this works** under the table for this run's own numbers.