Voice agent interruptions: stop stale audio safely

TL;DR: An interruption-safe voice agent invalidates the old response, stops queued playback, cancels disposable work, and rejects late results before admitting a new response. Keep business actions and heard conversation history under separate, explicit rules because stopping speech cannot undo an external write.

A caller says, "Wait, use the other address," while an agent is reading a delivery summary. The language model stops, but buffered speech continues and an older lookup returns after the correction.

That sequence can leave the caller hearing one address while the system acts on another. The repair requires a concurrency contract covering detection, generation, media, tools, and conversation history.

Current public documentation already exposes pieces of that contract. Twilio's Media Streams protocol supports clearing buffered media, and OpenAI's Realtime conversation guide distinguishes client-owned WebSocket playback from server-managed playback paths.

The design below is vendor-neutral. It is not a description of 60db Agent's private controller, and it makes no measured claim about interruption accuracy or stopping latency.

For measurement definitions, use the companion speech-to-playback benchmark. Here the goal is behavioral correctness when events arrive in an inconvenient order.

Table of contents

1. Define what an interruption changes
2. Represent the conversation with explicit ownership
3. Stop playback and reject stale work
4. Keep conversation history aligned with heard speech
5. Protect tools and irreversible actions
6. Test races with controlled event schedules
7. Tune detection without hiding false interruptions
8. Operate the state machine across transports
9. Frequently asked questions
10. Make interruption behavior a release contract

Define what an interruption changes

An interruption transfers conversational ownership from an assistant response to new caller input. It does not automatically revoke a business action already accepted by an external service.

Begin by identifying what can still change. Future model tokens can be discarded, future audio can be rejected, queued playback can often be cleared, and pending reads can be canceled or ignored.

Audio already played cannot be unheard. A booking already committed needs a business cancellation or correction process, even if the agent stopped explaining it halfway through the sentence.

Those distinctions belong in the design before any silence threshold is tuned. Otherwise the system treats an audio event as if it were a transaction rollback.

A useful interruption contract states which event changes ownership. That event can be confirmed caller speech, an explicit stop button, a push-to-talk press, or an application-level cancellation request.

Raw voice activity is an input to that decision. Background television, echo, a cough, and an acknowledgment can all produce sound while requiring different conversational behavior.

The VAD and turn-detection guide separates speech activity from intention to take a turn. Keep that distinction in the state machine so you can change the detector without rewriting response ownership.

You also need a policy for short backchannels. A caller saying "mm-hm" while an address is read may be agreeing rather than asking the assistant to stop.

A detector can classify those cases imperfectly. Make the uncertainty observable and define what the controller does while confirmation is pending.

One option is to pause playback briefly on a suspected interruption, then resume only if the event is classified as a false interruption and the old response remains valid. Another is to wait for stronger evidence before stopping, accepting a longer overlap interval.

These are product trade-offs. Measure false stops, missed stops, overlap duration, and successful correction handling against representative fixtures rather than choosing a universal threshold.

State the invariants

An invariant is a behavior that must hold across every allowed event schedule. For interruptions, the most useful invariants concern ownership and effects rather than the exact wording of a reply.

After the old response is invalidated, no newly admitted output belonging to it may enter playback. Audio already beyond the controllable boundary is recorded as residual output and measured separately.

A late result from the old response cannot update the current answer, current tool arguments, or the new turn's decision state. Retaining it for restricted diagnostics is a separate policy.

The system must also preserve caller input during the transition. Stopping the assistant must not disable microphone capture just when the caller is explaining the correction.

A call that ends reaches a terminal state. Later speech, tool, or synthesis events cannot restart it, and approved post-call work cannot reopen its media channel.

The shutdown contract provides the lifecycle boundary for that last rule. Treat hangup as more than another interruption because it removes the participant who would hear the next response.

Finally, business changes require their own confirmed intent and authorization. A canceled response must not silently carry an old write proposal into a new turn.

Write these invariants as release checks. They are more durable than a prompt telling the assistant to be polite when interrupted.

Represent the conversation with explicit ownership

Use identifiers that distinguish the call, caller turn, assistant response, and external operation. One identifier cannot safely represent all four because they have different lifetimes.

A call can contain many caller turns. One caller turn can produce multiple response attempts after retries, while a single business operation may survive a response cancellation because the external system already accepted it.

A response generation number, sometimes called an epoch, is a convenient local ownership token. Increment it when the current response becomes invalid, and require queued output to carry the generation under which it was created.

The generation is not an authorization token. It only tells a local output gate whether a piece of work still belongs to the active conversational response.

Keep the gate at the boundary that admits output to playback. If you check only when starting generation, a request that was valid at startup can return after the caller changes direction.

A single event loop can serialize ownership transitions. A distributed controller needs an equivalent concurrency mechanism, such as a single owner for a call or an atomic state transition enforced by its storage and delivery model.

Do not assume that a shared mutable integer makes a multi-process system safe. The token needs an ownership model appropriate to the runtime, and every output path must consult it consistently.

Model a small set of states

Separate conversational states from task execution details. listening, responding, interrupting, and ended can be enough for a small controller, with tool status represented as associated operations rather than dozens of top-level states.

A more complex product may need handoff_pending or another explicit business state. Add it when it changes the transitions your controller must permit, not merely because a diagram looks more complete with more boxes.

stateDiagram-v2
    [*] --> Listening: call ready
    Listening --> Responding: caller turn committed
    Responding --> Interrupting: confirmed interruption
    Interrupting --> Listening: old output invalidated
    Responding --> Listening: response playback completed
    Listening --> Ended: hangup
    Responding --> Ended: hangup
    Interrupting --> Ended: hangup
    Ended --> [*]: resources settled

This diagram is an application design, not a provider API. The transition labeled old output invalidated includes the media and ownership operations your actual transport requires.

Keep transitions idempotent. A duplicate speech-start event should not create a second new turn, double-increment business state, or reissue the same cleanup indefinitely.

Use the event's identity or the state transition's precondition to deduplicate. A second event can still be logged without triggering another effect.

Record the transition reason. A caller correction, a stop button, a false-positive detector event, and a hangup should not all become an indistinguishable cancelled field in your traces.

The observability guide explains how to join these decisions with media evidence. When debugging, you need to know what event transferred ownership and which output was already beyond your control.

Keep state small enough to inspect

Store the current generation, lifecycle state, active response identifier, controllable playback offset, and references to owned tasks. Put raw transcripts and business records in their proper stores instead of duplicating them inside the controller.

This reduces the amount of state that must change atomically. It also makes a failed race easier to reproduce because the test can describe a compact event sequence.

Every asynchronous callback should arrive with context. A callback without a response identifier forces the receiver to guess whether it belongs to the current turn.

Require the context at creation time. Retrofitting ownership after the result returns is too late when several overlapping requests share the same provider connection.

Stop playback and reject stale work

Cancellation requests stop effort; ownership checks prevent obsolete effort from taking effect. Use both because remote operations and local callbacks do not always stop at the moment you request cancellation.

Python's asyncio cancellation documentation describes cooperative task cancellation and cleanup through try/finally. Your controller still needs to await task settlement and reject late output at the admission boundary.

The interruption sequence begins by recording that the current response is invalid. This must happen before slow cleanup awaits, so another callback cannot observe the old generation as valid while cleanup is waiting on a network operation.

Then stop or pause local playback and clear buffers you control. Request provider-specific media clearing where the route supports it, and keep track of the acknowledgment semantics.

Next cancel disposable model, synthesis, and read tasks. Settle them under a bounded cleanup policy, while preserving the ability to accept caller speech.

Finally, align conversation history with the heard boundary and admit the next response only under the new ownership token. The order of independent cleanup operations can vary, but invalidation must precede any wait that permits stale output to slip through.

A minimal ownership check

The following Python example is vendor-neutral. It models a local output gate and tests stale response rejection, duplicate invalidation, and the terminal call state without contacting a provider.

from dataclasses import dataclass, field


@dataclass
class OutputGate:
    generation: int = 0
    ended: bool = False
    queued: list = field(default_factory=list)
    invalidated: set = field(default_factory=set)

    def admit(self, generation, audio):
        if self.ended or generation != self.generation:
            return False
        self.queued.append((generation, audio))
        return True

    def interrupt(self, event_id):
        if self.ended or event_id in self.invalidated:
            return
        self.invalidated.add(event_id)
        self.generation += 1
        self.queued.clear()

    def end(self):
        self.ended = True
        self.generation += 1
        self.queued.clear()


gate = OutputGate()
old = gate.generation
assert gate.admit(old, b"old")
gate.interrupt("speech-start-1")
assert not gate.admit(old, b"late")
assert gate.queued == []
current = gate.generation
gate.interrupt("speech-start-1")
assert gate.generation == current
assert gate.admit(current, b"new")
gate.end()
assert not gate.admit(gate.generation, b"after-hangup")

Save the snippet to a Python file and run it. A successful exit checks the local ownership rules only; it does not prove that your provider, browser, or handset stopped playing queued audio.

The in-memory deduplication set also needs a bounded lifetime in a real service. Keeping it per call and discarding it after settled shutdown is one simple policy, provided active-call event volume fits the documented resource budget.

The output gate also needs a policy for transport reconnection. Start a replacement media connection with an explicit session identity and discard frames buffered for the previous connection, even when the conversational generation has not changed.

Otherwise a delayed sender can treat the new socket as an empty destination and refill it with old audio. Test reconnection during interruption cleanup and require both the response identity and media-session identity to match before any frame is forwarded.

A production gate needs serialization around state access. If admission can run on multiple threads, or media is sent by another process, use the runtime's actual synchronization and delivery primitives.

Notice what the snippet deliberately leaves to adapters: media clearing, task cancellation, provider history repair, durable action records, and reconnection. The example isolates one invariant so you can test it without claiming to provide a complete voice runtime.

Handle media acknowledgments precisely

On Twilio Media Streams, clear empties buffered media and causes pending marks to return. A returned mark after clearing is not evidence that the corresponding audio was heard, so your mark ledger must record why the acknowledgment arrived.

For a custom player, invalidate queued frames and stop scheduled sources where the playback API allows it. A queue being empty in application memory says nothing about audio already scheduled farther downstream.

Define a controllable boundary for each adapter. Residual sound beyond that boundary contributes to measured interruption-stop latency and must remain visible in tests.

Do not delay stopping playback until a model cancellation acknowledgment arrives. That acknowledgment describes generation lifecycle, while playback can continue consuming already generated audio.

The transport comparison is useful here because a browser, a WebSocket gateway, and a SIP route can have different playback owners. The controller should depend on an explicit adapter contract rather than pretend those paths share the same event semantics.

Conceptual: Ownership checks, media stopping, and business reconciliation protect separate boundaries.

Keep conversation history aligned with heard speech

The assistant's internal context should reflect what the caller had a chance to hear. Otherwise the next response can assume a disclosure, question, or explanation was delivered when interruption stopped it halfway through.

Distinguish generated text, synthesized audio, admitted audio, and confirmed playback. Each stage proves less than the next, and none automatically proves comprehension.

For native audio systems, use the provider's documented history-repair mechanism. OpenAI's Realtime guide describes WebSocket client responsibility for stopping playback and truncating unplayed assistant audio, while its server-managed paths handle that boundary differently.

Do not copy a truncation event between transports without checking current documentation. The same provider can assign playback ownership differently depending on the connection type.

If your pipeline owns text and synthesis separately, maintain a mapping between spoken segments and playback progress. A word-level timestamp can help, but its precision depends on the synthesis output and alignment method.

Do not infer the exact heard word by multiplying character count by a percentage of audio duration. Speech timing is uneven, and that shortcut can turn an interrupted warning into a false record that the warning was complete.

Represent partial delivery

Store a response status such as interrupted, with an associated playback boundary and evidence source. Preserve the full generated text separately only when your diagnostic and retention policies permit it.

The conversation context can then describe the assistant's partially delivered content conservatively. If the required detail was not confirmed as played, the next response can repeat or complete it.

Required disclosures deserve an application-owned rule. The workflow enforcement guide explains how to track required steps outside the prompt, including steps interrupted before their delivery evidence was satisfied.

Playback evidence still differs from legal completion or user understanding. The policy owner must define what the product needs to prove for the actual workflow.

When the caller corrects a fact, preserve both the correction event and the current resolved value. Do not silently rewrite the conversation history so thoroughly that investigators can no longer explain why the old response started.

Keep audit context proportional. A structured record saying the delivery address changed can be more useful and less exposing than unrestricted copies of every partial transcript.

Avoid a second stale context path

Tool results can enter model context even when no audio is played. Apply the ownership check before inserting a result into the active conversation, not only before sending synthesis output.

A canceled availability lookup may still return. If its request used the old date, it cannot be treated as fresh evidence for the corrected appointment request.

Some reads can be reused after a correction, but only under an explicit cache key and freshness policy. Matching a customer name alone does not prove the query's other arguments still match.

Use a complete argument fingerprint or equivalent structured comparison. Keep the tenant and authorization scope in that identity so a reused result cannot cross a business boundary.

The speculative tool design develops this read-reuse policy further. The interruption controller only needs to know whether the result is admissible under the current turn's resolved request.

Conceptual: Use the supported playback boundary and uncertainty when repairing context after interruption.

Protect tools and irreversible actions

A tool operation has a lifecycle distinct from a spoken response. It may be proposed, authorized, dispatched, accepted, committed, failed, or left with an unknown outcome after a network interruption.

Do not collapse those states into one cancel flag. If the service accepted a write and the response was lost, canceling a local task cannot establish whether the write happened.

The correct next step is reconciliation through the business system's supported operation lookup or idempotent retry behavior. Guessing that the action failed can create a duplicate when the agent tries again.

For a booking, keep a stable operation identifier tied to the confirmed business intent. A new response generation can refer to that operation without reissuing it as a new booking.

For a changed request, resolve whether it supersedes an uncommitted proposal or requires an explicit modification to a committed record. That is a business decision grounded in the operation state.

Stripe's idempotency documentation offers a concrete public example of request deduplication semantics. Its guarantees have scope and retention rules, so do not turn one provider's idempotency feature into an unlimited exactly-once promise for every tool.

Separate cancellation from compensation

Cancellation asks unfinished work to stop. Compensation performs a new business operation that counteracts an already completed action, where the business system permits it.

A refund, appointment cancellation, or address correction can have its own authorization, fees, deadlines, and failure modes. The voice controller should request the appropriate workflow instead of pretending to reverse history.

A prompt can explain this policy to the model. Enforcement belongs in the application that accepts tool execution and resolves operation state.

Use the same rule when the caller hangs up. Some approved post-call operations can finish, but a disconnected participant cannot provide fresh confirmation for a new irreversible action.

The cost-per-success guide also needs this distinction. Duplicate writes and corrective work belong to the cost of the system even when the original call sounded quick and confident.

Compare control mechanisms

This table describes the protection each mechanism directly supplies. A cross identifies work that needs another layer rather than a defect in the mechanism itself.

A complete interruption path combines the applicable mechanisms. The table helps reviewers find missing ownership rather than encouraging another broad abstraction around unrelated responsibilities.

Test races with controlled event schedules

An interruption test should make the wrong event order happen deliberately. A happy-path call that pauses politely between turns cannot prove safety when a tool result and a speech-start event arrive together.

Use a controllable scheduler or explicit barriers in local tests. Start a request, hold its result, invalidate the response, then release the result and assert that it produces no admitted output or active-context update.

Run the reverse order as well. A result that arrives just before interruption can create queued audio, so the clear path must invalidate that audio before the next response begins.

Keep logical assertions separate from audio measurements. The ownership test can be deterministic while the physical audio stop test needs a real media path and a documented detection tolerance.

The regression harness guide describes how to combine those layers. A local state test should fail fast before a more expensive authorized call is placed.

Cover the boundaries that change behavior

Interrupt during the greeting. This finds systems that start listening only after their first speech finishes and lose the caller's first request.

Interrupt before first audio. This tests whether the system cancels a pending answer even when no playback exists yet.

Interrupt during synthesis and during queued playback. These cases distinguish the producer's lifecycle from the media consumer's lifecycle.

Interrupt while a read is waiting, after a read returns, and after a write is accepted. Each schedule needs a different expected business outcome even if all three stop the same spoken sentence.

Send duplicate and delayed detector events. Verify that they do not create additional caller turns or invalidate the replacement response unexpectedly.

End the call while interruption cleanup is running. Assert that no cleanup callback restarts playback, and that late tool settlement reaches the approved post-call path.

Add negative assertions

A negative assertion checks that an effect never occurs. For an interrupted response, assert that no old-generation frame is admitted after the invalidation event.

Also assert that no superseded tool result changes the active arguments. Checking only the final transcript can miss a stale result that briefly influences an action before the transcript is repaired.

Preserve the event log when a test fails. A useful failure artifact includes the schedule, identifiers, transition reasons, media clear request, clear acknowledgment, and accepted or rejected outputs.

Use synthetic identifiers and test accounts. A regression suite should not require access to production customer records to prove an ordering invariant.

Test the recovery path

A safe stop followed by permanent silence is still a failed interaction. After the old response settles, assert that the agent can hear the correction and produce a response belonging to the new turn.

Check whether it asks the caller to repeat information unnecessarily. Some repetition is appropriate when recognition was uncertain, but a controller defect that discards valid caller audio should not be mislabeled as model caution.

Measure useful correction completion. The outcome metrics guide keeps that result separate from the mechanical stop interval.

A complete fixture has both a safety assertion and a continuation assertion. The system must stop obsolete effects and make progress on the caller's current intent.

Conceptual: A complete fixture checks both rejection of obsolete effects and useful progress on the corrected task.

Tune detection without hiding false interruptions

Detection quality and controller safety are different dimensions. A perfectly safe controller can stop too often, while an accurate detector can still feed a controller that leaks stale audio.

Evaluate the detector against labeled audio. Include background speech, echo, quiet speech, short agreement sounds, strong corrections, overlapping speakers, and pauses followed by resumption.

For multilingual calls, label the actual interruption intent rather than relying only on an English transcript. The multilingual evaluation guide explains why recognition quality and task behavior need separate checks.

Tune against cohorts. A setting that works for a headset in a quiet browser test may perform differently over a phone channel with background sound and different speaker levels.

Define false-interruption recovery

If a suspected interruption proves false, the controller needs a deliberate resume policy. Resuming the old response is safe only when its content and business context remain valid.

Do not resume from a newly generated beginning unless that is the intended behavior. Repeating a long introduction after every cough can make a technically correct system unpleasant to use.

A short pause can be represented without revoking the response generation, provided your controller keeps suspected and confirmed interruption states distinct. Once a true correction invalidates the generation, resuming it requires a new explicit decision.

LiveKit's turn-handling documentation describes false-interruption behavior as a configurable framework concern. Check the installed version's current options instead of assuming the same defaults across releases or languages.

Avoid unsupported universal targets

There is no single silence threshold or stop latency that establishes correctness for every voice application. A short command interface, a support conversation, and a required disclosure workflow have different costs for a false stop.

Publish the test conditions and decision criteria. If you choose a stop budget for your product, label it as your acceptance target rather than an industry-wide fact.

Track missed interruptions and false interruptions together. Optimizing only one rate can make the other unacceptable while a single dashboard number appears to improve.

For measured stopping latency, retain the distribution and unsuccessful attempts. Calls where the agent never stops must remain failures rather than disappearing from successful-only percentiles.

Operate the state machine across transports

The controller's invariants should stay stable across transports, while the media adapter states what it can observe and clear. This lets you reuse safety reasoning without assuming identical network behavior.

For a browser path, inspect microphone capture, scheduled audio, device changes, and tab lifecycle. For a phone path, inspect gateway queues, codec conversion, disconnect events, and available playback acknowledgments.

The SIP troubleshooting guide helps separate signaling from media behavior. A connected call and a successful cancellation request do not prove the far-end handset stopped emitting audio.

For stream APIs, verify how barge-in messages relate to outgoing frames. An application that forwards media owns the queues it adds, even if the upstream agent correctly invalidates its response.

Qualify managed services by observed behavior

60db Agent's public Agents documentation describes browser tests, stream calls, and interruption-related analytics. Those documented surfaces can support a black-box qualification plan where enabled for your workspace.

They do not prove that the service uses this article's ownership-token implementation. Keep the generic architecture separate from the product's documented behavior and test results.

Use an authorized fixture to interrupt a greeting, a long answer, and a delayed tool turn. Record what the caller heard and which business effects occurred, using the same contract you would apply to any other system.

Do not assume universal inbound access. Confirm workspace and environment availability before planning phone-based tests, and use a supported browser or outbound route when that is the verified surface.

Make failures diagnosable without exposing content

A state-transition log can often explain an interruption defect without preserving raw speech. Record opaque identifiers, event types, relative timing, ownership generations, and rejection reasons.

Keep personal data out of metric labels and operation identifiers. A trace export should not become a second uncontrolled copy of a caller's address or account details.

The local and managed data-boundary guide maps these choices across providers and application stores. Apply the same retention discipline to test recordings and production diagnostics.

Plan for handoff and degraded operation

When interruption handling repeatedly fails, a controlled fallback can be safer than another overlapping response. The supported fallback may be a clarification, a push-to-talk interface, or an offered human handoff.

The warm handoff guide treats transfer as a separate lifecycle. Do not keep ordinary response generation active after another participant takes conversational ownership.

Record which component owns the final turn. A handoff that leaves both the automated agent and a human speaking creates the same ownership problem at a larger boundary.

Close the loop through regression tests. Every confirmed interruption defect should produce a fixture or schedule that fails before the repair and passes afterward, with no private conversation content required.

Frequently asked questions

What makes a voice agent interruption-safe?

It invalidates obsolete responses, stops controllable playback, rejects late results, and preserves the caller's new input. It also tracks business operations separately so speech cancellation cannot be mistaken for an external transaction rollback.

Is stopping the language model enough?

No. Audio already generated can remain in synthesis queues, application buffers, transport buffers, or scheduled playback. You need a media stop path and a stale-output gate as well as generation cancellation.

What is a response generation token?

It is a local ownership value attached to asynchronous work for one response attempt. When the response becomes invalid, the token changes and late work with the old value is rejected at the output boundary.

Does a generation token authorize tool execution?

No. A generation token only identifies conversational ownership. Tool authorization must come from the application policy, current confirmed arguments, caller identity where required, and the business system's own permissions.

Should every VAD event stop the agent?

That is a detector policy rather than a universal rule. Background sound, echo, and conversational acknowledgments can trigger activity, so evaluate the stop decision against labeled fixtures and the product's tolerance for false interruption.

How do I avoid losing the caller's correction?

Keep input capture active while the assistant's output is being stopped. Associate incoming speech with the new caller turn, and test interruptions during greetings and cleanup waits to find capture gaps.

Can I resume speech after a false interruption?

Yes, when the previous response remains valid and the playback system supports a known resume boundary. A confirmed correction invalidates that response, so it should not resume through the false-interruption path.

What happens to a tool result after interruption?

A stale result is rejected from the current response and active conversation unless an explicit reuse policy establishes that it still matches. Cancellation can save work, but rejection protects state when cancellation arrives too late.

Can an interruption undo a booking?

Stopping speech cannot undo a committed booking. Reconcile the operation state, then follow the supported modification or cancellation workflow with the required authorization and confirmation.

Why does the agent remember something it never said?

Its context may contain generated text that playback never delivered. Preserve a heard boundary and use the provider's supported history repair, or an application-owned partial-delivery representation, before generating the next response.

Does a returned playback mark always mean audio played?

No. Some protocols return marks when buffered audio is cleared. Interpret the acknowledgment using the documented cause and your own clear ledger instead of treating every returned mark as heard speech.

How do I test a late TTS chunk?

Hold the chunk behind a test barrier, invalidate its response, then release it. Assert that the playback admission boundary rejects it and that the new response can still proceed.

Do I need a large state machine?

You need enough states to express different permitted transitions. A compact lifecycle plus separately owned tool operations is often easier to inspect than a top-level state for every combination of model, synthesis, and transport status.

What should happen on duplicate interruption events?

The ownership transition should occur once for the same event or logical interruption. Duplicate events may be logged, but they must not cancel the replacement response or create additional business effects.

How do I measure interruption latency?

Measure from the defined caller interruption onset to the final assistant audio at your observation boundary. State whether that boundary is application playback, gateway evidence, or acoustic output, and count cases that never stop.

Does low interruption latency prove conversational quality?

No. An agent can stop quickly and then ignore the correction, repeat itself, or execute old arguments. Check continuation quality and business outcomes alongside the mechanical stop interval.

How does hangup differ from interruption?

Hangup ends the participant's call lifecycle and should make media terminal. Approved post-call work can continue under its own contract, but late callbacks must not restart playback or request new caller confirmation.

Can I test 60db Agent's interruption behavior?

Use a documented browser, stream, or authorized phone path where your workspace supports it. Observe the resulting behavior without claiming that the vendor-neutral controller in this article is its private implementation.

What should interruption logs contain?

Use opaque call, turn, response, and operation identifiers with transition reasons and timing evidence. Raw transcript or audio retention is a separate decision governed by consent, access, and retention requirements.

What should block a release?

Stale audio admitted after invalidation, stale arguments affecting an action, lost correction speech, and media restarting after hangup are strong blocking invariants. Detector trade-offs need explicit product criteria and representative tests.

Make interruption behavior a release contract

An interruption-safe system assigns ownership before it optimizes timing. The controller invalidates obsolete responses, the media owner clears controllable playback, and the business layer reconciles operations that cannot be canceled by stopping speech.

Keep the implementation inspectable. A small ownership gate, explicit lifecycle transitions, and controlled race tests reveal more than a prompt that asks the agent to stop politely.

Your next implementation step is one deterministic fixture: hold an old result, interrupt its response, release it, and prove it cannot affect playback or current state. Then repeat through the real media route and verify that the caller's correction completes the right task.

If you are qualifying 60db Agent, use the documented test surface available in your workspace and apply the same evidence standard. Publish observed behavior and supported boundaries rather than inferring private architecture from a successful demo.