# A spoken correction can invalidate pending tool work

Why Gemini 3.8 Live corrections need separate handling for obsolete tool results, cancellation attempts and already committed consequences.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-15
Original announcement: https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-8-live-gemini-3-8-live-extended-thinking/
Canonical URL: https://retrivium.ai/retrospectives/live38-tool-cancellation-intent/

## Conversation could change while tools were working

[Live Translate launched on June 9, 2026](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-live-3-5-translate/), before [Transcribe on August 26](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-5-transcribe/). [The September 15 Live announcement](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-8-live-gemini-3-8-live-extended-thinking/) described background tool work during dialogue. This introduces a race in meaning: the result can arrive after the spoken request has changed. Tool completion proves that an operation returned, not that its result still answers the user's current question. The application needs to preserve that distinction even when the conversation remains natural and uninterrupted.

## A correction can supersede a result without stopping execution

An illustrative assistant searches for a document while the user clarifies that a different project was intended. The original search may still finish. Ignoring its result for the current task is different from physically cancelling the request. A system can handle stale results correctly even when the underlying operation cannot be cancelled. Conversely, requesting cancellation does not prove that it took effect before completion. The precise mechanism must follow the actual tool contract; the release does not justify inventing a universal cancellation primitive.

## Read-only and consequential operations differ

Discarding an obsolete search result is relatively straightforward. An already executed external change requires a different response because its consequence may persist. A spoken correction should therefore not be treated as proof of rollback. The workflow needs to know whether work is still provisional, merely completed or externally committed. This is an analytical state distinction, not a statement that a particular Live API event exposes all of those categories. It prevents a graceful conversational correction from concealing a mismatch in the connected system.

## An illustrative late-result fixture

A practical test uses a mock read-only lookup that deliberately returns after the user changes the target project. Review whether the final answer uses the current target and whether the obsolete result is excluded or clearly identified. A separate mock consequential operation tests accurate reporting when a correction arrives after commitment. No real external change is made and no measured model result is asserted. The fixture distinguishes stale-result handling, cancellation attempts and consequence reporting instead of treating them as one generic interruption behavior.

## Current intent governs use, not historical completion

The release makes concurrent dialogue and work more useful, but it does not remove the need for intent versioning in orchestration. A result belongs to the request interpretation that created it. The retrospective lesson is to track that relationship and decide explicitly whether the result remains applicable. This allows useful background execution without letting late information overwrite a corrected goal. A fluent voice can acknowledge the new request immediately while the application separately handles the state and consequences of work already in motion.

## Related reading

- [Tool completion and action boundaries](/journal/openrouter-tool-calling/)
- [Linking results to request intent](/journal/provider-request-id-trace-context/)