Interruption vs context in voice agents: what's the difference?

Interruption and context get tangled together because they usually happen in the same instant: a caller cuts in mid-response to correct something. But they are two different capabilities, and an agent can handle one perfectly while failing the other. Teams that treat them as one thing end up fixing the wrong problem. Evalgent tests both, separately and together, and this guide draws the line.

Interruption: a caller speaking while the agent is still talking — a turn-taking event that requires the agent to stop and listen.

Context: the conversational state an agent carries — prior turns, the caller's goal, and corrections — that it must remember and apply.

Interruption vs context: the core difference

The clearest split is by what each one is about. Interruption is about timing — who is speaking and whether the agent yields. Context is about memory — whether the agent absorbs and uses what was said.

Interruption lives at the turn-taking layer: the agent hears the caller start and has to cut its own speech. Context lives at the reasoning layer: the agent has to take the caller's words into its working memory and act on them. They are neighbors, but they are not the same job.

Why they get confused

The confusion is understandable, because a single caller action triggers both. When a caller says "book me to Rome — actually, make it Paris," the agent has to do two separate things: stop talking (interruption) and update its plan to Paris and act on it (context). To a listener it feels like one moment, so a failure feels like one bug.

But the two can fail on their own. The agent might stop cleanly yet still book Rome, because it handled the interruption and dropped the context. Or it might keep the context correctly yet talk over the caller for a beat, an interruption failure with the memory intact. Because they are separate capabilities, "the agent got it wrong" is not a diagnosis — you have to know which layer broke. Our barge-in guide covers the interruption side, and our context retention guide covers the memory side.

The two failure modes, side by side

Keeping the failures distinct is what makes them fixable. An interruption failure is the agent talking over the caller — it did not yield when the caller cut in. The fix is at the turn-taking layer: full-duplex audio, barge-in handling, and voice-activity tuning so the agent stops promptly.

A context failure is the agent yielding correctly but not using what the caller said — it stopped, but acted on the old information anyway. The fix is at the memory layer: carrying conversation state forward and applying a mid-turn correction to the action, not just the transcript. The reason this distinction matters is that the fixes live in different parts of the stack, so misdiagnosing the failure sends you tuning the wrong thing entirely.

How to handle interruption and context together

A caller correction is only handled well when both capabilities fire. Build and test them as two steps.

1. Detect the interruption — Recognize the caller speaking over the agent, using barge-in and voice-activity detection.

2. Yield promptly — Stop the agent's speech quickly, so it is listening rather than talking over.

3. Capture the new input — Take what the caller said during the interruption into the conversation state.

4. Apply it to the action — Update the plan and the tool call to the corrected value, not just the words.

5. Confirm the change — Read back the updated action so the caller knows the correction landed.

6. Test both layers — Verify the agent yields (interruption) and uses the correction (context), and diagnose failures by layer.

A worked example

A caller says, "Book me to Rome — actually, make it Paris." Two things must happen. First, the agent has to stop talking about Rome the moment the caller cuts back in — that is interruption handling. Second, it has to change the booking to Paris and call the tool with Paris — that is context handling. If the agent stops but books Rome, the interruption worked and the context failed. If it books Paris but talks over the caller getting there, the context worked and the interruption failed. Same sentence, two independent verdicts — which is the whole point of keeping them separate.

Testing interruption and context with Evalgent

Evalgent tests both capabilities, and tells them apart. Scenarios script mid-response interruptions and mid-sentence corrections, so the agent has to yield and absorb new information in the same call. Profiles vary caller pace and interruption style over real audio, since timing is where interruption handling shows its cracks. Metrics track the interruption side — did the agent stop, and how fast — separately from the context side — did the corrected value reach the action — so a failure points at the right layer. Evaluations run the suite as automated batches before release, and Reviews let you replay the exact moment to hear whether the agent talked over the caller, dropped the correction, or both.

The result is a clean diagnosis, not a vague one: you learn whether an interruption bug is a turn-taking problem or a memory problem, and you fix the layer that actually broke. This failure pair is central to full-duplex agents — see testing GPT-Live voice agents — and to the wider AI voice agent testing discipline.

The bottom line

Interruption is a turn-taking event — did the agent stop and listen. Context is conversational memory — did the agent use what was said. A caller cutting in to correct something tests both, and they fail independently.

Treat them as one bug and you will tune the wrong layer. Keep them separate, and a caller's "actually, make it Paris" becomes two clear questions — did it yield, and did it update — each with its own fix.

Frequently asked questions

What is the difference between interruption and context in a voice agent?

Interruption is a turn-taking event: the caller speaks while the agent is talking, and the agent must stop and listen. Context is conversational memory: the information the caller has given, which the agent must remember and use. They often happen together when a caller cuts in to correct something, but they are separate capabilities that can fail independently.

Why does a caller interruption test both interruption and context?

Because a mid-response correction requires two distinct actions. The agent has to stop talking, which is interruption handling, and it has to absorb and act on the new information, which is context handling. "Book Rome — actually Paris" needs the agent to yield and to rebook to Paris. Either can fail on its own, so the single moment tests both layers at once.

How do you tell an interruption failure from a context failure?

Look at what actually happened. If the agent kept talking over the caller, that is an interruption failure at the turn-taking layer. If the agent stopped cleanly but acted on the old information — booking Rome after the caller said Paris — that is a context failure at the memory layer. The behavior tells you which layer broke and therefore which fix to apply.

What causes a voice agent to talk over the caller?

That is an interruption-handling failure, usually from a half-duplex pipeline that cannot listen while speaking, a barge-in threshold set too high, or a slow stop. The agent does not yield when the caller cuts in. It is separate from whether the agent remembers what the caller said, so fixing it means working on the turn-taking layer, not the agent's memory.

What causes a voice agent to ignore a correction?

That is a context-handling failure. The agent may have stopped talking correctly, but it did not carry the caller's new input into its working state or apply it to the action — so it books the original value despite the correction. The fix is at the memory layer: preserving conversation state and updating the tool call to the corrected value, not just the transcript.

Is interruption the same as barge-in?

Yes, effectively. Barge-in is the specific term for a caller interrupting the agent while it is speaking, requiring the agent to yield. Interruption is the broader everyday word for the same event. Both are turn-taking concerns, distinct from context, which is about whether the agent remembers and uses what the caller said during or after that interruption.

How do you test interruption and context together?

Script scenarios where a caller interrupts mid-response to change something, then assert both outcomes separately: that the agent stopped promptly, and that the corrected value reached the action. Vary caller pace and interruption timing over real audio. Measuring the two independently lets you diagnose a failure as a turn-taking or a memory problem rather than a single vague bug.

Can a voice agent handle interruptions but still lose context?

Yes, and it is common. An agent can yield perfectly when interrupted yet fail to absorb what the caller said, acting on the old information anyway. The reverse also happens — it uses the correction but talks over the caller getting there. Because interruption and context are separate capabilities, handling one well says nothing about the other.