The workflow at a glance
Design task state separately from speech timing. Progress describes completed stages, while completion requires a verifiable result. Interrupted speech does not establish cancelled work. Validate a fixed-answer event simulation before connecting a real Live session.
Respect the official tutorial’s environment
The complete Google tutorial covers streaming tools, background execution and response scheduling. Its example requires google-adk≥2.10.0, gemini-3.8-live on Gemini Enterprise and bidirectional run_live sessions. A request to “talk while working” in an ordinary text prompt does not supply that architecture.
The tutorial also distinguishes user barge-in from stopping background tools. All events, data and reference answers below are original editorial designs. We have not run a Gemini account or reproduced the vendor’s latency measurements.
Prepare material with a completely known answer
The task is to summarize completed records for synthetic batch Q7. R1 has quantity 8 and statuscompleted; R2 quantity 12 andcompleted; R3 quantity 5 andpending; R4 quantity 9 andcancelled. Success means quantity 20 and two included records, with explicit reasons for excluding the others. Quantities are artificial counts, not revenue.
Assign stable taskID Q7-A1. “Is it ready?” should inspect that task, rather than start another identical report. New input needs a new identity; a late response from an earlier report must not become the new answer.
Summarize batch Q7. Input: R1=8/completed; R2=12/completed; R3=5/pending; R4=9/cancelled. Include only completed records. task_id=Q7-A1. Return quantity, included IDs, excluded IDs and reasons. Do not announce final figures before a completed event. Repeated status questions refer to this same task.Accept events, rather than continuous chatter
The following sequence is an expected-state simulation, not a speed test. Progress contains no final quantity. An unrelated question does not change the report filter. Announcing 20 during aggregation fails even if the eventual answer happens to match.
| Event | Internal state | Acceptable behavior |
|---|---|---|
| Request arrives | pending | Acknowledge without final figures |
| Reading finishes | running | Describe only that completed stage |
| User asks another question | running | Answer it while retaining task identity |
| Final result arrives | done: R1,R2; quantity 20 | Deliver figures and exclusions at the chosen time |
| Older result arrives | ID differs from current task | Do not replace the current report |
Give interruption and cancellation separate branches
First editorial branch: the user says “Wait, let me ask something else.” Stop the current audio output but retain the background task; Q7-A1 can still complete. Second branch: “Cancel this summary.” Issue an actual cancellation request and obtain the task state instead of merely speaking a cancellation claim.
Cancellation can race with completion. If work already finished, do not claim it never ran. If cancellation is confirmed, a later old completion packet should not be announced as a fresh success. Retaining taskID, state and resultID makes the boundary reproducible.
For ADK’s specific mechanism, follow the official stop_streaming setup and resource cleanup. An interface mute control does not itself cancel a database query, file operation or connection. If the underlying tool cannot cancel, report that actual condition.
A misleading cancellation design
The user interrupts; the UI says cancelled, while work continues and later speaks the answer
Track speech_interrupted separately from task_cancelled; only actual task state changes the cancellation record
Choose delivery timing, then inspect the result
For a non-urgent report, our recommendation is to deliver at a natural pause. Tasks genuinely needing interruption should be specified separately, rather than making every progress message urgent. Scheduling determines when a response enters the dialogue; it does not accelerate the backend query.
Compare inputIDs, filter states and quantity 20, and verify repeated questions create no second request. The multi-repository task-boundary workflow applies similar scope discipline. For speaking practice without background operations, consider the Gemini Live rehearsal workflow instead.
A real integration still needs separate access, permission, network-failure and cancellation-feedback checks. Synthetic events validate a design rule, not guaranteed model behavior in live calls or achieved latency.
Pass simulation before service integration
- R1 and R2 total 20; other states are excluded
- Repeated status questions retain one taskID
- Barge-in does not fabricate cancellation
- Late cancelled-task results do not overwrite newer work
- Final figures follow a trusted completed event
Common questions
Can prompting fix a blocked execution loop?
It cannot replace the architecture. Instructions describe behavior; tools and session configuration determine what can run during the wait.
What if there is no genuine progress signal?
Acknowledge receipt and say the result is still pending. Do not manufacture percentages or stages from a timer.
Does a passing simulation establish low latency?
No. Real environment and measurement evidence are needed. We have not run the model or claimed measured performance.
