A live AI session needs a visible stop boundary
Live audio and video assistance needs separate controls for capture, speech and pending actions. Define what stops, what continues and who can authorize work.
By 
Paul. AI and agentic engineering
Interrupting an assistant's voice does not necessarily stop its microphone, screen feed or pending work. A business application that combines those activities needs to explain each boundary. The useful design starts with what a person can stop and what the system confirms afterward. Conversational fluency cannot supply that contract.
Looking back from November 2026, Google's 11 December 2024 developer announcement introduced Gemini 2.0 Flash Experimental and a Multimodal Live API. It described live audio/video inputs, interruptions and tool integration. Those were experimental launch capabilities. They do not establish the availability, reliability or account conditions of a service in 2026.
Capture and conversation are different states
Imagine an internal assistant helping an employee inspect an unfamiliar application screen. The proposed product can receive microphone audio and a selected screen view, explain what it sees and prepare an action. This is an illustrative design, not an AL+ test or customer implementation. The design question is how the employee understands what is leaving the device while the conversation changes.
Capture should have a visible state independent of whether the assistant is speaking. A silent assistant can still be receiving information. A muted speaker therefore should not be presented as a stopped session. Distinguish the microphone from screen sharing too: ending one stream need not end the other. A person trying to exclude a private window needs a control whose meaning does not depend on guessing the model's conversational state.
The interface can show the selected source and whether transmission is active. When the source changes, ask for the appropriate choice again rather than assuming a previous screen selection covers everything newly visible. The required behavior depends on the product and platform, but the principle is concrete: the displayed capture state should correspond to what the application is actually sending.
Interruption answers a narrower question
Simon Willison's same-day account of Gemini 2.0 described his exploration of the streaming experience. His observations and Google's demonstrations show what their authors presented. They are not independent AL+ measurements, evidence about Romanian recognition accuracy or proof that a particular business workflow works end to end.
An interruption lets a person redirect a conversation without waiting for spoken output to finish. In a proposed product, that can mean stopping audio playback and beginning a new turn. It does not logically imply that the microphone is disabled, transmitted data is erased or a tool request has been withdrawn. These are separate effects that require their own implementation and confirmation.
A useful interruption message could state that speech stopped while capture remains active. A different control could end capture. Keep the wording aligned with the real behavior: if the system is waiting for confirmation from the capture component, show a pending state instead of immediately declaring that transmission ended. A reassuring label that precedes the actual transition can mislead at exactly the moment the user relies on it.
Pending actions need their own result
Suppose the assistant has prepared a support message but has not sent it. A stop command can discard the draft locally. If sending has already begun, the application may need to query the destination before claiming cancellation. Once the destination accepted the message, stopping the conversation does not undo delivery. The product needs to describe that completed effect even if the session is now closed.
For that reason, separate permission to observe from permission to act. Sharing a screen so the assistant can explain a form does not authorize submitting it. A proposed tool request can remain pending approval while conversation continues. The user should be able to see which action is awaiting a decision and which action, if any, is already in progress.
On interruption, define what happens to each pending request. Some requests can be discarded; others may continue to completion under an earlier authorization. The application should make that choice visible and retain a result that can be inspected. This is a lifecycle recommendation, rather than a claim that the December API supplied a universal cancellation mechanism.
The business consequence is accountability. An employee who stops a session needs to know whether a customer message still went out. Operations staff need a way to distinguish cancelled, completed and unresolved work. Without those distinctions, a natural conversation can leave the organization with an ambiguous commitment that nobody knows how to reconcile.
Push-to-talk can be the stronger product
Continuous capture has a real counterargument: the task may not require it. If the employee only needs help with occasional screens, push-to-talk and an explicitly submitted screenshot can make the information boundary easier to understand. A deliberate submission can be reviewed before transmission and attached to a particular question.
That approach may make fluid back-and-forth assistance less convenient. A task involving frequent changes could benefit from a live view, and repeatedly selecting captures can interrupt the employee's work. The choice depends on the actual interaction. This article does not claim that one method is universally safer or faster, and it supplies no measured comparison.
Before choosing live capture for an AI assistant project, write the expected result of three user actions: interrupt speech, stop capture and cancel pending work. Walk through an already accepted tool request as well as an unsent one. If the proposed interface cannot explain the difference, simplify the session until the person using it can tell what remains active and what has truly ended.