After an interruption: continue, summarize, or restart?

TL;DR: Choose resumption from current caller intent, the validity of the old response, playback evidence, and authoritative action state. Continue only at a safe supported boundary, repeat a complete instruction when delivery is uncertain, and generate a fresh answer after a correction; stopping speech never rolls back an external action.

---

The caller says "wait," the agent stops, and the next response begins with the same obsolete sentence. The interruption mechanism worked, but recovery failed because the player treated an audio position as a complete conversation state.

A useful resumption policy asks what changed. The caller may have corrected a value, requested repetition, added a question, produced a harmless acknowledgment, or stopped the interaction entirely.

The interruption safety guide establishes cancellation and stale-result rejection. This guide starts after that boundary and provides a deterministic policy selector, task-aware fixtures, and a delivery record for deciding what to say next.

The examples are synthetic and vendor-neutral. They can support a 60db Agent integration without describing private product behavior or presenting a test plan as a measured benchmark.

As of November 2026, public realtime interfaces expose different interruption evidence. The OpenAI Realtime conversation guide documents transport-specific playback and truncation responsibilities, while Twilio's ConversationRelay messages expose a distinct application event model.

Table of contents

1. Reconstruct the state that matters
2. Choose a recovery with explicit criteria
3. Build a deterministic resumption selector
4. Resume at meaning boundaries
5. Reconcile actions before repeating claims
6. Keep history honest after interruption
7. Test task-aware recovery schedules
8. Measure repair burden and operate safely
9. Frequently asked questions
10. Make the next sentence current

Reconstruct the state that matters

Resumption is a new decision about current conversation state. The old playback cursor is useful evidence, but it cannot tell you whether the sentence remains true or whether the caller still wants it.

Begin with lifecycle. If the call ended or a handoff transferred authority, the old agent should remain silent even if generation completed and a playable tail remains in memory.

The shutdown semantics guide gives that terminal rule. Keep it above every convenience rule for continuing a sentence, because late callbacks can arrive after the participant or owner changed.

Next, determine whether the caller is still speaking. A partial correction can remain incomplete, and recovery should not begin merely because a short gap appeared inside a spelled name or structured answer.

The continuation-cue guide covers those pauses. Preserve the ongoing caller turn rather than racing to fill every quiet interval with a summary.

Then inspect current intent and task revision. A harmless acknowledgment can leave the old explanation valid, while "use the other fictional entrance" changes the facts that its remaining words depend on.

The self-correction guide supplies a field-revision record. A response that refers to an older revision should not resume simply because its audio has already been generated.

Inspect delivery evidence separately. You may know a provider acknowledged a segment, know a local source was stopped, or have only an estimate of the rendered position; those observations support different recovery choices.

The playback evidence guide keeps generated, sent, scheduled, acknowledged, and ambiguous media distinct. Use the strongest supported boundary without claiming that a person understood it.

Finally, inspect external action state. An interrupted explanation can describe a booking that already committed, a pending lookup, or a write whose outcome is unknown after a timeout.

Those states cannot be inferred from the sound. A quiet speaker does not mean a write failed, and a fully played sentence does not mean the underlying operation succeeded.

Record these inputs in a small recovery context. The selector should consume current facts rather than querying arbitrary services from inside a player callback, which would make its behavior hard to test and its authority unclear.

Keep the context versioned or owned by the same serialized controller that admits output. If another correction arrives while recovery wording is being generated, its response needs the same stale-output checks as the original answer.

Conceptual: Recovery uses current conversational facts, supported playback evidence, and separately owned business state.

Choose a recovery with explicit criteria

Use a few clear actions: listen, yield, reconcile, answer fresh, repeat a complete step, continue at a safe boundary, or summarize. The action should come with a reason so operators can distinguish uncertainty from a deliberate user request.

Continue is appropriate when the caller's contribution leaves the response valid, delivery progress is known enough, and a semantic boundary is available. That can apply after a harmless acknowledgment or a brief unrelated clarification that the conversation has already resolved.

Summarize is useful when the main facts remain current but a long interrupted explanation would be tedious to replay. It should preserve the needed task information and avoid pretending the caller received the exact words that were skipped.

Restart a complete step when partial delivery creates meaning risk. A short instruction, confirmation request, or structured identifier can be safer to repeat in full than to resume at an uncertain word position.

Answer fresh after a correction. Reusing valid general knowledge is fine, but the spoken answer must be produced under the current task revision and must not splice in old values from a canceled response.

Yield when the caller asks for silence. A stop request can mean the user wants time to think, so replacing the stopped answer with an immediate long explanation can violate the request even though it uses fresh audio.

The progressive silence guide helps distinguish thinking time from abandonment. Recovery speech needs its own bounded silence policy rather than inheriting an aggressive timer from ordinary question answering.

The table uses ✓ for an action allowed under this guide's candidate policy and ✗ for an unsafe shortcut. It is a decision artifact, not a measured ranking of recovery strategies.

Do not use one generic recovery prompt for every row. A prompt can help phrase the selected action, while the controller must preserve the boundaries that determine whether that action is allowed.

The workflow enforcement guide explains why this matters for consent. A resumption decision should not silently advance a workflow step just because the assistant's old generated transcript contained the expected question.

If intent remains unresolved, listen or ask a short clarification after the caller yields. Avoid interpreting ambiguity as permission to finish the old plan, especially when the interruption contained a negation or a revised identifier.

The figure is a compact view after lifecycle, caller-turn, and action-state gates pass. It omits those earlier gates for readability; the executable selector below keeps them explicit.

Build a deterministic resumption selector

The policy can be small when it consumes a well-defined context. Use Python dataclasses for the immutable input record and enumerations for the finite decision vocabulary.

Save the following as resume_policy.py and run it with Python 3. Every fixture is synthetic, and the selector returns an action rather than performing media, tool, or network operations.

from dataclasses import dataclass, replace
from enum import Enum


class Intent(Enum):
    SAME = "same"
    CHANGED = "changed"
    UNRESOLVED = "unresolved"


class Operation(Enum):
    NONE = "none"
    KNOWN = "known"
    PENDING = "pending"
    UNKNOWN = "unknown"


class Recovery(Enum):
    SILENT = "silent"
    LISTEN = "listen"
    YIELD = "yield"
    RECONCILE = "reconcile"
    FRESH = "fresh-answer"
    REPEAT = "repeat-complete-step"
    CONTINUE = "continue-safe-boundary"
    SUMMARIZE = "summarize-current-facts"


@dataclass(frozen=True)
class Context:
    active: bool
    caller_speaking: bool
    stop_requested: bool
    intent: Intent
    operation: Operation
    old_response_valid: bool
    delivery_known: bool
    safe_boundary: bool
    critical_step: bool
    repeat_requested: bool


def choose(c):
    if not isinstance(c.intent, Intent) or not isinstance(c.operation, Operation):
        raise ValueError("Typed intent and operation required")
    booleans = (c.active, c.caller_speaking, c.stop_requested,
                c.old_response_valid, c.delivery_known, c.safe_boundary,
                c.critical_step, c.repeat_requested)
    if any(type(value) is not bool for value in booleans):
        raise ValueError("Boolean policy facts required")
    if not c.active:
        return Recovery.SILENT
    if c.caller_speaking or c.intent is Intent.UNRESOLVED:
        return Recovery.LISTEN
    if c.stop_requested:
        return Recovery.YIELD
    if c.operation in (Operation.PENDING, Operation.UNKNOWN):
        return Recovery.RECONCILE
    if c.intent is Intent.CHANGED or not c.old_response_valid:
        return Recovery.FRESH
    if c.repeat_requested or (c.critical_step and not c.delivery_known):
        return Recovery.REPEAT
    if c.delivery_known and c.safe_boundary:
        return Recovery.CONTINUE
    return Recovery.SUMMARIZE


if __name__ == "__main__":
    base = Context(True, False, False, Intent.SAME, Operation.NONE,
                   True, True, True, False, False)
    fixtures = [
        (base, Recovery.CONTINUE),
        (replace(base, active=False), Recovery.SILENT),
        (replace(base, caller_speaking=True), Recovery.LISTEN),
        (replace(base, intent=Intent.UNRESOLVED), Recovery.LISTEN),
        (replace(base, stop_requested=True), Recovery.YIELD),
        (replace(base, intent=Intent.CHANGED), Recovery.FRESH),
        (replace(base, old_response_valid=False), Recovery.FRESH),
        (replace(base, delivery_known=False), Recovery.SUMMARIZE),
        (replace(base, safe_boundary=False), Recovery.SUMMARIZE),
        (replace(base, critical_step=True, delivery_known=False), Recovery.REPEAT),
        (replace(base, repeat_requested=True), Recovery.REPEAT),
        (replace(base, operation=Operation.UNKNOWN), Recovery.RECONCILE),
        (replace(base, intent=Intent.CHANGED, operation=Operation.PENDING),
         Recovery.RECONCILE),
        (replace(base, active=False, operation=Operation.UNKNOWN), Recovery.SILENT),
    ]
    for context, expected in fixtures:
        assert choose(context) is expected
    try:
        choose(replace(base, intent="same"))
        raise AssertionError("Expected typed-boundary rejection")
    except ValueError:
        pass
    print("Synthetic resumption policy and precedence checks passed")

The selector's precedence is part of the contract. A terminal call remains silent; ongoing or unresolved caller input retains the floor; an explicit stop yields; unresolved action state blocks fresh claims; only then does the policy choose wording based on validity and delivery.

Operation.KNOWN means the application has authoritative state, not that the action succeeded. The response builder must receive the actual known result and report failure, cancellation, or success truthfully rather than interpreting the enum as a success flag.

delivery_known is also scoped. It means the application has sufficient evidence for the declared recovery boundary, not proof of acoustic hearing or comprehension.

The code intentionally does not infer intent from text. A production input adapter must supply validated intent and revision facts, preserve uncertainty, and avoid treating an unstable partial transcript as a confirmed command.

The partial transcript guide covers that admission gate. If recognition revises "continue" into a correction, the recovery response needs invalidation under the same current-state rules.

After selecting an action, build a new response identity and bind its wording to the current context revision. Recheck that identity at playback admission so another caller event cannot make the fresh response stale before it is heard.

Resume at meaning boundaries

A meaningful continuation starts where the listener can understand it. An exact audio offset can be technically valid while beginning in the middle of a word, leaving a pronoun without its referent, or omitting a condition that controls the next instruction.

Use self-contained steps when possible. A synthetic explanation might say, "Use the fictional blue entrance. Ask for the parcel desk." Each sentence can be repeated without depending on an arbitrary chunk boundary.

A confirmation request often needs a larger unit. If the proposal includes destination, date, and an important restriction, repeating only its final question can leave the caller confirming an unclear or obsolete proposal.

The qualified confirmation guide explains why a caller's answer can revise that proposal. Resumption should preserve the complete current proposal before seeking acceptance again.

Do not estimate a heard word boundary by multiplying transcript length by played-audio percentage. Speech timing varies, and the missing portion can contain exactly the word that changes the task.

If verified alignment exists, retain its source and confidence boundary. A forced alignment estimate remains an estimate, and a provider's documented played position should not be silently replaced with a locally invented character cursor.

The streaming sentence guide helps distinguish syntactic boundaries from transport chunks. A chunk ending after an abbreviation or decimal point can be a convenient payload boundary without being a safe resumption point.

For a long explanation, a summary can reduce repetition. State the current conclusion and the next useful action, then let the caller ask for detail rather than replaying the entire generated paragraph.

For structured identifiers, repeat the whole field under the task's confirmation rules. A partial phone-like identifier or fictional reference code can become misleading if the resumed tail loses its grouping or prefix.

Keep leading zeros and spoken corrections as text under the field contract. Resumption should not reinterpret a structured value through a numeric conversion merely because the speech player wants a short string.

A backchannel needs less repair. If "mm-hm" did not change intent and the old response remains valid, continuing at a safe boundary can preserve flow without forcing another confirmation cycle.

The backchannel guide supplies fixtures for that case. Test it alongside explicit corrections so a policy that restores harmless overlap cannot accidentally restore obsolete content.

A repeated interruption can indicate the response itself is too long or poorly targeted. Use the current caller question to shorten the next answer rather than treating every interruption as a media defect that requires more replay logic.

Conceptual: Repeat a complete current instruction when an arbitrary audio tail would lose meaning.

Reconcile actions before repeating claims

Stopping audio does not undo an external action. A booking, update, or message can commit while the assistant's explanation is interrupted, and the recovery must report authoritative state rather than infer it from the old response.

Keep an operation identifier independent of response generation. One operation can survive cancellation of several speech attempts, while a new caller correction can require a separate compensating operation rather than a retry of the original write.

If a request times out, the outcome can remain unknown. Check the authoritative system or use its supported idempotency and status mechanisms before retrying an action that may already have happened.

The HTTP semantics standard defines idempotence around intended server effects. It does not make an arbitrary business endpoint safe to retry simply because the voice application wants a quick answer.

A provider-specific contract can add useful retry behavior. For example, Stripe's idempotent request documentation describes its own key semantics, which must be followed within that API rather than assumed for unrelated tools.

The example is about operation safety, not payment advice or a recommendation to expose payment details through speech. Keep credentials, real transaction identifiers, and sensitive account data out of fixtures and public incident reports.

The speech lane shows one possible interrupted delivery outcome. It does not assert that every stopped source lacks earlier acknowledgment; the actual media ledger determines the delivered and uncertain portions.

Suppose a synthetic appointment request was submitted before the caller said, "Wait, use the later slot." If the earlier request committed, the application needs a supported modification or cancellation flow, not a claim that the old request vanished because speech stopped.

If the operation remains pending, the agent can say it is checking the current status only when that work has actually started. The truthful waiting-speech guide ties such messages to observable state.

Do not replay a success sentence from generated text after an unknown timeout. Generated wording can predate the final result or refer to an old proposal, so it is weaker evidence than the external system's current state.

The speculative tool guide separates disposable reads from consequential writes. Resumption can reuse an authorized current read result, but it should not turn speculative or stale output into an accepted business action.

If the caller asks to stop, yield speech even while authorized reconciliation continues under its own lifecycle. The user does not need a stream of repeated progress messages for every internal status check.

If the call ends, complete only the post-call work already authorized by the product's rules. A terminal speech session does not grant new authority to contact the person through another channel or create additional actions.

Keep history honest after interruption

History should distinguish generated content from delivery-supported content. Otherwise the next model response can refer to an instruction the caller never received or assume that a confirmation question was completed when it was cut off.

Store the original generated response separately from the conversation view. The conversation view can include the known delivered portion and a compact interruption marker, while the evidence ledger retains the detailed media status.

Avoid filling history with every low-level callback. The language model needs current facts, caller intent, operation state, and relevant uncertainty; it does not need raw socket counters to decide how to phrase a recovery.

If a provider offers a truncation operation, follow its documented item identifiers and supported transport semantics. A local history edit may leave remote realtime state unchanged unless the relevant API operation is also performed.

Keep text alignment limitations explicit. A truncated audio item does not automatically provide a perfectly aligned partial text transcript, so do not invent a word-perfect delivered prefix when the source cannot support it.

For a custom player, retain the local stop reason beside the source completion event. The Web Audio scheduled-source contract allows completion events for stop conditions as well as ordinary ending, which matters when building delivery history.

A useful synthetic history entry might say, "Assistant began the current entrance instruction; delivery of the second step is uncertain after caller interruption." That gives the recovery builder enough context to repeat the complete step without pretending every generated word was heard.

After a correction, history must preserve the revised field as current. Keep the old value in a revision record only when the application needs that audit history, and do not mix it into the fresh spoken answer.

The workflow guide explains why old proposals need explicit invalidation. A prior yes should not silently authorize a revised proposal, and a canceled question should not count as a completed workflow step.

For a false interruption, record the classification and validity check. If the old response is still current, a safe continuation can be selected without creating a fictional new user request from noise or echoed output.

The echo diagnosis guide helps establish that source boundary. A transcript resembling the assistant's own words should trigger diagnosis rather than an automatic belief that the caller repeated the whole answer.

Preserve uncertainty in summaries handed to humans. A receiving agent should know whether a task action committed and whether the caller may still need the final instruction, rather than receiving a polished summary that quietly erases the interruption.

The warm handoff guide provides the ownership and summary boundary. Once transfer is complete, late recovery speech from the original agent should remain rejected.

Test task-aware recovery schedules

Test the selector as a pure decision function, then test the controller that gathers context and performs the chosen action. The pure tests prove precedence under supplied facts; they cannot prove that recognition, playback evidence, or tool adapters supplied correct facts.

Start with a harmless acknowledgment during a valid explanation. The caller yields, the response facts remain current, and a known safe boundary allows continuation without repeating the whole answer.

Change only the intent to a correction. The expected action becomes a fresh answer under the revised facts, and no old response chunk should pass the output gate after invalidation.

Now make the caller's correction incomplete. The system should listen rather than rushing to answer the first recognized fragment, especially when the utterance contains a list or a spelled fictional name.

Test a request for repetition. Keep the task facts unchanged but set the repeat request, then verify that the controller repeats a complete useful unit rather than the arbitrary tail of an audio chunk.

Test uncertain critical delivery. If a short instruction's final segment lacks sufficient evidence, the selector should choose a complete-step repeat under the current facts.

Test unknown operation state together with changed intent. Reconciliation takes precedence over a fresh claim about the action, so the system cannot announce a revised result before checking what the earlier request did.

Test caller stop and call termination separately. A stop yields the floor within an active call, while termination keeps the original media owner silent permanently.

The regression testing guide provides a home for these schedules. Preserve the expected action, prohibited stale outputs, and authoritative operation result beside each synthetic conversation.

Add a delayed recovery completion. Select a fresh answer, begin generating it, accept another correction, then deliver the first recovery's audio and assert that it is rejected as stale.

Add a delayed volume restore from the pre-interruption player. The overlap policy guide explains why gain callbacks need response ownership even after the conversation moved into recovery.

Add a clear-order race before a new response. Fresh media must wait until the old clear has entered the outbound writer's required order, otherwise the clear can flush the recovery audio and leave the ledger with misleading marks.

Use exact synthetic scripts for task assertions. A fixture should verify that the new fictional destination appears and the old one does not appear in accepted output, rather than checking only that the agent spoke something after interruption.

For listening tests, review both caller and assistant channels under consent. A correct policy can still sound confusing if the resume point cuts a word or the output transition masks the start of the caller's correction.

Conceptual: These fixture outcomes use the executable selector's other default context fields; adapter accuracy needs separate checks.

Measure repair burden and operate safely

A fast stop is only one part of useful interruption behavior. Measure whether the caller needed to repeat the correction, whether the next response used current facts, and whether the task completed without an unauthorized duplicate action.

The outcome metrics guide separates task success from intermediate signals. Resumption metrics should explain why a task failed or required effort, rather than replacing the task outcome with a count of successful audio starts.

Track repeated content in semantic units appropriate to the task. Repeating a short critical instruction can be intentional, while replaying a long obsolete explanation is a failure even if both count as one restart.

Keep false-interruption repair separate from genuine-correction repair. A policy can handle backchannels smoothly while failing to apply revised facts, and an aggregate average can hide that distinction.

Report unknown delivery and unknown operation outcomes explicitly. A missing acknowledgment or timed-out write should not disappear from the denominator simply because the call ended before the evidence arrived.

For timing, state the interval and clock boundary. Caller speech end to recovery start, interruption decision to old-output stop, and operation reconciliation time describe different delays.

The latency benchmark guide provides a measurement vocabulary. A short generation interval can coexist with a long player backlog, so local model timing cannot establish perceived recovery speed.

Monitor repeated recoveries within one call. A loop of stop, restart, and stop can indicate that the response is too long, the echo path is unresolved, or the queue admits stale media after every new attempt.

The audio backpressure guide addresses that final case. Recovery should receive the same bounded admission and age checks as ordinary output.

Use a bounded fallback when the evidence remains unusable. A short clarification, a supported handoff, or a visible control can help the caller regain control, while endless restarts spend time without resolving the underlying uncertainty.

Keep recovery language tied to the selected action

The response builder should receive the selected recovery and its supporting context. For a fresh answer, include current facts and the resolved caller request; for a complete-step repeat, include the whole current instruction and the reason its delivery is uncertain.

Do not ask a generative model to infer whether it should retry a write from a vague note that the user interrupted. Provide authoritative operation state and an explicit allowed action so wording cannot accidentally become business execution.

Keep progress statements factual. "I am checking whether that request completed" requires an active status check, while "That is updated" requires a known successful result under the revised proposal.

When the caller asked for quiet, the best next action can be silence. The recovery system should not turn every stop into an apology followed by a new explanation, because that recreates the behavior the caller just rejected.

Treat resumption as a new output attempt

Even when continuing the same subject, create a fresh output attempt with current ownership and delivery tracking. This does not require a new business operation; it requires an identity that separates the recovery media from the canceled attempt.

Bind any reusable text to the current task revision. Reusing a general explanation can save work, but a cached sentence containing an old destination or action claim must fail the same freshness check as a newly generated stale response.

Preserve the link to the interrupted attempt for diagnosis. Operators should be able to see why the recovery happened and which delivery boundary was uncertain without merging both attempts into one misleading completed response.

The cost-per-success guide helps evaluate unnecessary replay. Reusing safe content can reduce work, while repeated failed attempts and additional calls can cost more than generating one concise current answer.

Recheck facts when the caller changes the subject

An interruption can introduce a new question without correcting a field. Preserve any still-valid task state, then decide whether the old explanation remains useful after answering the new question rather than assuming the caller wants every unfinished sentence replayed.

For a synthetic case, the assistant is explaining how to find a fictional room and the caller asks whether another entrance is accessible. The recovery should answer that current question from verified information or state that it is unknown; it should not finish the old route description first merely because its audio is ready.

A subject change can also make a pending read irrelevant. Cancel disposable work where supported and reject its late result from the current answer, while retaining only the diagnostic evidence the application's policy permits.

Avoid merging both questions into an invented request. If the relationship is unclear, ask a concise clarification after the caller yields, then produce a response under the resolved intent revision.

Keep repetition distinct from re-execution

A caller saying repeat that usually asks for speech, not another business action. Bind the repeat to the known result or current instruction and make sure the response builder cannot invoke the original write merely to recreate its spoken confirmation.

This distinction belongs in tests. Submit a synthetic action once, interrupt its result explanation, request repetition, and assert that the operation count remains unchanged while a new media attempt reports the existing authoritative result.

If the result is unknown, the repeat request does not remove the need to reconcile it. Explain the uncertainty under the active workflow rather than replaying an earlier speculative success sentence.

For a corrected proposal, repeat only the current version. Keep the old proposal's identity available for audit if required, but reject it as a source for renewed confirmation or speech after the caller has revised its facts.

Establish a recovery review record

A release record should state the caller behaviors covered, the evidence available at each transport boundary, the selected actions, and the known omissions. Include actual fixture counts only after the test run produces them.

Keep synthetic fixture results separate from provider and hardware trials. The selector's deterministic checks prove policy precedence, while a physical endpoint trial checks audible transitions under its declared device and route.

When a real incident adds a missing case, retain the reduced event schedule and current expectation. Avoid adding a special phrase handler before determining whether the cause was intent revision, delivery uncertainty, queue ownership, or unresolved operation state.

That cause-based record keeps the policy small. A few clear actions with tested precedence are easier to maintain than a growing list of exceptions for every way a caller can say wait, yes, or repeat that.

---

Frequently asked questions

Should an agent always resume where it stopped?

No. Resume only when the old response remains valid and the available delivery evidence supports a safe meaning boundary. A caller correction, stop request, or unresolved external action can require a different next action.

When is a summary better than a restart?

A summary helps when the main facts remain current but replaying a long explanation would add unnecessary effort. Preserve the useful conclusion and next step without claiming the caller received the skipped wording.

When should a complete step be repeated?

Repeat a complete step when partial delivery can change meaning or when the caller explicitly requests repetition. A short instruction or confirmation proposal is usually easier to understand as a whole than as an arbitrary audio tail.

What should happen after a caller correction?

Invalidate output based on the old facts and generate a fresh answer under the revised task state. If an external action may already have occurred, reconcile it before making a new claim or retrying the action.

Does stopping speech cancel a booking?

No. Speech cancellation and business cancellation are separate operations with different authority and state. Query the booking system and use its supported change or cancellation workflow when the earlier request may have committed.

What does unknown delivery mean for recovery?

It means the available evidence does not establish the needed playback boundary. Choose a self-contained repeat, summary, or clarification appropriate to the content instead of inventing an exact heard word position.

Can a played duration be converted into a text cursor?

Only with a verified alignment method whose limitations are stated. A proportional character calculation can cut across words or omit a condition, so it should not support a precise delivery claim.

Should recovery wait for the caller to finish?

The policy should preserve the caller's turn while speech or intent remains unresolved. Structured answers and self-corrections can contain pauses, so a short quiet interval alone is weak evidence that recovery speech should begin.

How should harmless backchannels be handled?

If the backchannel leaves the response and task facts valid, continue at a safe boundary or restore under the declared mix policy. Test that case separately from explicit corrections so harmless overlap cannot revive obsolete speech.

What should a stop request do?

Yield the floor and stop the current output under the media contract. Do not immediately replace it with a long apology or explanation unless the caller asks for that response.

Can an operation remain pending after interruption?

Yes. A read or write can outlive its speech attempt under the application's lifecycle rules. Keep its identifier and authoritative state separate so recovery can reconcile it without blindly repeating the request.

Does idempotency make every retry safe?

No. Follow the specific API's method and idempotency contract, including parameter and key rules. A voice interruption does not add retry guarantees to a business endpoint that lacks them.

What belongs in conversation history after a stop?

Include current intent, known task facts, relevant action state, and the delivery-supported portion or uncertainty marker. Keep full generated text and detailed media events in separate records rather than presenting them all as completed speech.

Should the selector perform network calls?

The example selector is pure and returns an action from validated context. Gather authoritative facts through controlled adapters, then execute the selected action under current ownership and authorization checks.

What does Operation.KNOWN mean in the example?

It means the application has an authoritative result, including a possible failure or cancellation. The response builder must inspect that result and must not interpret the enum as a success flag.

Can another correction invalidate recovery speech?

Yes. Recovery is another output attempt and needs its own response identity and task revision. Reject its late audio if a newer caller event makes the selected response obsolete before admission.

How should a handoff affect resumption?

Once ownership transfers, the original agent should remain silent. Pass the receiving person current intent, action state, and relevant delivery uncertainty instead of letting late callbacks restart the old explanation.

Which tests reveal recovery races?

Test delayed generation, delayed gain restoration, clear ordering, held sender chunks, and a second correction during recovery. Assert the prohibited stale outputs and operation effects, not just that some fresh audio eventually appears.

What should resumption metrics measure?

Measure current-fact accuracy, caller repetition burden, intentional versus unnecessary replay, task outcome, and duplicate-action prevention. Keep timing intervals and uncertainty categories explicit so a fast audio start cannot hide a wrong recovery.

What should a platform evaluation verify?

Verify interruption events, playback evidence, truncation or clear behavior, current-state output admission, and operation reconciliation boundaries. Use synthetic task fixtures and declared endpoint conditions before making claims about a caller's listening experience.

Make the next sentence current

Resumption works when the next sentence follows the caller's current intent and the evidence the system actually has. Keep lifecycle, caller turn, action state, response validity, and delivery progress separate, then select the smallest useful recovery under explicit precedence.

Start with the deterministic selector and paired fixtures for harmless acknowledgment, correction, repetition, and unknown operation state. Add real adapter and endpoint trials for the boundaries the pure function cannot observe, and keep their limitations visible.

For a 60db Agent integration, ask for the public control and evidence surfaces your application can verify. Use them to produce current, coherent recovery speech and a faithful record of what remains uncertain after interruption.