A completion state machine for Gemini 3.8 Live voice agents

Google’s announcement for Gemini 3.8 Live says the model can continue a conversation while tools and API calls execute in the background. It also says Extended Thinking can reason and speak simultaneously, provide verbal progress cues, and coordinate asynchronous function calls without interrupting the live conversation. Those are documented product claims, not evidence from an independent runtime test. Read Google’s announcement.

That concurrency changes the meaning an integration can safely assign to speech. “I’m checking” may acknowledge a request while work remains in flight. Even a fluent transition to another topic does not, by itself, establish that the tool succeeded.

The state machine below is our proposed migration pattern. It is an architectural response to the documented asynchronous behavior, not a state model specified by Google.

Five states for one action

A useful completion model separates these states:

State	What has happened	What the interface can represent
ACKNOWLEDGED	The agent has accepted the request and may have spoken a progress cue.	Work has started or will start; no completion claim yet.
EXECUTING	A non-blocking tool invocation is outstanding.	The request is in progress.
RESULT_RECEIVED	The integration has received a success or failure result tied to the invocation.	A result exists, but the caller has not necessarily heard it.
INTERACTION_IDLE	The interaction reports no active model work.	The interaction is idle; this alone does not establish tool success or caller confirmation.
CONFIRMED	The result has been interpreted and communicated without contradiction from a later event.	The interface may represent the action as complete, failed, or handed off according to the result.

A secondary analysis reports two additional integration constraints: Extended Thinking rejects synchronous tools in favor of NON_BLOCKING declarations, and turnComplete is distinct from interactionStatus: IDLE. The same analysis warns that treating those signals as equivalent can allow caller speech to overlap unfinished reasoning or let a result arrive after the conversational turn has moved on. These are that author’s reported findings, not claims established by Google’s announcement. Read the PacketNebula analysis.

The practical implication is narrower than “speech cannot be trusted.” Speech can accurately acknowledge intent or report progress. It becomes unsafe only when an integration maps that speech to a stronger completion state than the available events establish.

Give completion an event, not a phrase

A compact transition model can keep the distinction explicit:

REQUEST_ACCEPTED -> ACKNOWLEDGED
TOOL_DISPATCHED  -> EXECUTING
TOOL_SUCCEEDED   -> RESULT_RECEIVED(success)
TOOL_FAILED      -> RESULT_RECEIVED(failure)
INTERACTION_IDLE -> INTERACTION_IDLE
RESULT_SPOKEN    -> CONFIRMED(success | failure | handoff)

This model deliberately allows events to arrive in inconvenient orders. INTERACTION_IDLE may precede a delayed tool result. A caller interruption may occur during EXECUTING. A new conversational turn may begin before the prior action reaches RESULT_RECEIVED.

The invocation identifier therefore belongs in the transition record. Without that binding, a late result can be attributed to the wrong conversational turn or summarized as though it answered a newer request. That is a design prescription derived from the asynchronous pattern; neither supplied source specifies this record format.

Migration test table

The most useful migration exercise is a set of event-order tests. Each row below proposes a fixture and a bounded passing observation.

Scenario	Injected sequence	Unsafe representation to detect	Passing observation
Fast acknowledgment, delayed success	Request; spoken acknowledgment; tool dispatch; delay; success result	The action appears complete immediately after acknowledgment.	State remains EXECUTING until the matching result arrives, then reaches CONFIRMED only after the result is communicated.
Progress speech during execution	Dispatch; one or more verbal progress cues; delayed result	A progress cue sets a completion flag.	Each cue preserves the outstanding invocation and leaves completion unset.
Caller interruption	Dispatch; caller speaks before result; result arrives during the new turn	The late result is attached to the caller’s new request.	The result retains its original invocation and action identity; any spoken update makes that context clear.
Tool failure	Dispatch; failure result	The agent confirms success from conversational context alone.	Failure produces a failure or handoff state, never a success confirmation.
Idle before result	Dispatch; interaction becomes idle; result arrives later	Idle is recorded as successful completion.	Idleness and tool outcome remain separate fields; the late result can still advance the original action.
Result before idle	Dispatch; result arrives; model work continues; interaction later becomes idle	Result arrival silently ends the interaction.	Tool outcome is recorded while conversational activity remains independently visible.
Duplicate result	Dispatch; success result; repeated success result	The action is applied or announced twice.	The repeated event is recognized by invocation identity and does not create a second completion.
Competing actions	First dispatch; second request and dispatch; second result; first result	Results are assigned by arrival order.	Each result advances only its matching action instance.

This table does not demonstrate that Gemini 3.8 Live produces every ordering listed. It defines adversarial sequences an integration can simulate because asynchronous execution permits tool work and conversation to overlap according to Google’s description. The exact event schema, retry behavior, and available identifiers still need verification against the integration surface being migrated.

Instrument the gap

The important interval begins when the interface acknowledges the request and ends when it communicates the matching tool outcome. For each attempted action, a migration run can retain:

• action and invocation identifiers;
• acknowledgment timestamp;
• dispatch timestamp;
• tool-result timestamp and outcome;
• observed turn-completion and interaction-idle signals;
• interruptions or later turns that occurred while the tool was outstanding;
• final spoken status and its associated action.

Those fields make three different questions answerable: Did the agent acknowledge the request? Did the tool finish? Did the interface accurately communicate the result? Combining them into one “completed” boolean erases the failure modes this migration needs to expose.

Release the transition logic with the model change

A migration review can treat the model, tool declarations, event handling, and completion-state mapping as one release configuration. The PacketNebula report makes NON_BLOCKING declarations a specific compatibility question, while Google’s announcement supplies the broader reason to exercise overlap between speech and tool execution. Compare the reported constraint with Google’s documented asynchronous behavior.

The bounded release claim is not that fluent conversation proves reliable action completion. It is that the integration preserved action identity across the tested event orders and represented completion only after receiving and communicating the corresponding result.

Teams adapting this pattern to a larger agent system can carry the same separation into their build architecture: conversation progress, background execution, interaction idleness, and confirmed outcomes remain different signals even when they occur within one natural exchange.