The Call Can End Before the Work Does

Consider a fictional room-booking call. You ask an assistant to reserve a meeting room for Thursday. It starts answering, you lose the connection, and you open the text conversation to finish.

The room may already be booked. The assistant may only have prepared the request. Or the request may have reached the booking service without a reply coming back.

All three can leave the same silence.

A product that treats that silence as failure may book twice. One that treats it as success may leave you standing outside a room someone else reserved. The continuation needs something more reliable than the last sentence.

Ending the conversation is a product decision

On September 23, OpenAI's release notes described plugins in Voice and a Work behavior worth noticing: an unfinished task can continue in text after the voice call ends. That is a documented capability, not evidence that any particular interruption is handled correctly. This article does not test ChatGPT's implementation. OpenAI release notes.

For a PM shipping a similar feature, the decision is what survives that transition. The microphone has a lifecycle. The task has another. Closing one should not leave the other in an unexplained state.

My proposal is to preserve the latest authorized request and the backend outcome separately from response playback. For actions that change shared state, this should reduce duplicate actions and recovery work compared with resuming from conversation history alone. That is a hypothesis to test, not a result established by the example below.

The person should be able to tell whether work is continuing, waiting for them, or stopped. Ending a call and cancelling a task need distinguishable controls. If the product cannot reliably carry a task across channels, it should pause and say so.

A good conversation can still leave the wrong result

Smallest AI's September 17 preprint, MTVA-Bench, examines the language model inside a cascaded voice agent. It uses simulated callers and mock backends. Its results distinguish choosing a tool from supplying the right arguments, ordering actions correctly, and describing their outcomes accurately. Those are useful product distinctions even without adopting its leaderboard. MTVA-Bench.

Its limits matter here. MTVA-Bench does not evaluate audio, latency, or real-time interruption handling. It cannot establish that a complete voice product will recover well after a dropped call.

An earlier preprint from Boson AI, IHBench, explicitly studies what an agent does after interruptions in structured workflows. It evaluates task fulfillment separately from recovery quality. Its conversations are synthetic and English-only; recovery scoring concerns response text, not acoustic timing. Both papers come from AI vendors. They provide test ideas, not independent proof of this proposed design. IHBench.

That distinction changes the review. A recording can sound reassuring while the room reservation is missing. A reservation can exist while the caller reasonably believes nothing happened. Both deserve attention.

Cut the same task at three different moments

Here is an original tabletop exercise for a room-booking product. Everything in it is fictional, including the operation and reservation identifiers. It specifies expected behavior; it reports no model performance or customer incident.

Assume Thursday's booking has been authorized. A change of day requires fresh confirmation in this example. The booking service supports looking up an operation by its stable identifier, and the product records whether a request was dispatched. Those are requirements of this exercise, not capabilities every API has.

The middle cut is the awkward one. Unknown is a real state, not a slower spelling of failed. If the lookup finds r-17, the product should report it. If the service authoritatively confirms that nothing was applied, a retry can follow its documented rules. An inconclusive lookup should keep the task unresolved and offer a route to check it.

This is familiar distributed-systems territory. HTTP's semantics standard cautions against automatically retrying a non-idempotent request unless the client knows the operation is effectively idempotent or the original was never applied. A conversational interface does not remove that uncertainty. RFC 9110, section 9.2.2.

An operation identifier alone is not protection. The service must actually support deduplication or authoritative reconciliation. Nor does stopping an audio stream undo a booking. If the caller cancels while a write is in flight, the product must resolve the write before promising that nothing happened.

Save the state, then explain it plainly

The handoff can be small: the current request and its authorization, an operation reference with a confirmed or unknown outcome, and the last confirmation the interface finished presenting. Playback completion is only a delivery signal. It cannot prove that someone listened or understood.

That is enough to change the next response from "Let's try again" to "The room is reserved for Thursday. Here is the confirmation." For the unresolved case, a better response is "The booking request was sent, but I haven't confirmed the result. I'm checking it before trying again."

There is no need to retain every word indefinitely to support this. Keep the minimum task record under the product's access and retention rules. Reuse the booking system's records rather than building a competing source of truth inside the chat.

The cost is real. Reconciliation adds latency and engineering work. For a read-only question, or a draft that cannot affect anyone else, replaying a little conversation may be perfectly adequate. An existing workflow engine may already hold the necessary state. In that case, the product work is connecting the handoff and making its status understandable.

Test whether the extra state earns its keep

Run the three cuts against a transcript-only continuation and a state-aware continuation, using the same sandbox tasks. Add an explicit cancellation and a normal uninterrupted call so the design cannot pass by refusing everything. Check backend records separately from what the interface says.

Then test with people. Count duplicate or incorrect writes per interrupted attempt, and measure the time people spend checking and repairing the result. Include abandonment and unnecessary confirmation prompts. A technically correct handoff that makes every small task exhausting is a poor product.

If the simpler continuation produces the same reliable outcomes with less recovery effort, keep it. The state model has to earn its complexity.

For a team making this release decision, The AI Feature Ship Gate provides the broader acceptance structure. Start here with one action your assistant can actually perform. Cut the call immediately after that action, then inspect what the next channel believes happened.

The booking record and the next sentence should agree.