Files
google__adk-docs/docs/live/tools.md
Kaz Sato 03eccf55e0 docs(live): decompose the dev guide and fix staleness vs adk-python main (#2086)
* docs(live): decompose the development guide into capability pages

Split dev-guide/part1-5 into Sessions, Events, Tools, Workflows, Audio and
video, Configuration, Voice, Supported models, and Build a custom server.
Rewrite index.md as the section Overview with a streaming-type decision table.

Implements Phase 2 of the Live Interactions<>ADK documentation revamp.

* docs(live): drop half-cascade model coverage

Half-cascade models are no longer supported for live agents. Remove the
Native Audio vs Half-Cascade architecture framing from Supported models and
the half-cascade caveats from Voice configuration. The eight prebuilt Live
API voices are kept, relabeled as native-audio voices alongside the extended
Text-to-Speech list.

* docs(live): retire the five-part dev guide and rewire navigation

Delete live/dev-guide/ and live/streaming-tools.md now that their content
lives in the capability pages. Regroup the Live nav into Get started / Build /
Ship / Reference, repoint every partN.md cross-link at its new page and
anchor, and add direct redirects for the removed paths (mkdocs-redirects does
not chain, so streaming/* keys point at final destinations).

* docs(live): point at the API reference instead of pinned source

Swap the RunConfig, Event, SequentialAgent, LiveRequestQueue and
Runner.run_live source-reference notes for Python API reference links.
Implementation pointers with line ranges are left as source links, since they
document internals with no public reference equivalent.

* docs(live): fix docs against adk-python main and drop the bidi-demo links

The bidi-demo sample was removed from adk-samples, so all the source links in
docs/live/ were dead. The sample is not shipped here either, so remove every
reference to it instead of repointing the links.

The code snippets themselves are unchanged. What goes away is only the
scaffolding that pointed at the sample:

- 32 code fences lose their linked 'Demo implementation: file.py:NN-MM' title
  and become plain language-tagged fences.
- The 'Complete Demo Implementation' note in custom-server.md and the 'Demo
  Implementation' note in events.md are dropped; both existed only to link out.
- The 'Learn More' note in tools.md and the model setup step in models.md keep
  their guidance but no longer cite the sample's files.
- Prose that named the demo ('The bidi-demo demonstrates how to...') is
  rewritten to describe the pattern directly.
- The Bidi Demo card and its screenshot are removed from the Live demos section
  of index.md; LensMosaic remains.

Staleness fixes verified against adk-python main:

- StreamingMode.BIDI is inert. Only run_async() reads RunConfig.streaming_mode;
  run_live() never does. Remove it from every run_live()-facing sample and
  rewrite the 'StreamingMode: BIDI or SSE' section around the Runner method you
  call. Keeps the old anchor via attr_list.
- configuration.md: run_live(session=...) is gone; use user_id/session_id.
- tools.md: streaming tools are registered lazily on first model call, not
  scanned up front; the input_stream queue is created only for tools annotated
  with LiveRequestQueue, and stop_streaming resets it to None. The old
  runners.py / function_tool.py line references pointed at unrelated code.
- sessions.md: document DEFAULT_MAX_RECONNECT_ATTEMPTS = 5 and the go_away
  reconnect trigger; correct 'automatic closure in SSE mode', which really only
  happens for the internal queue under support_cfc.
- events.md: audio artifacts require RunConfig.save_live_blob=True;
  get_author_for_event() also keys off llm_response.input_transcription.
- configuration.md: document history_config and the
  initial_history_in_client_content=True that ADK sets when seeding history.

Not changed: get-started/streaming-java.md still sets StreamingMode.BIDI, which
could not be verified without an adk-java checkout.

* Refresh the Live API supported-model list

Checked against the Gemini Live API and Agent Platform model docs:

- models.md: replace the model list with a platform/model/stage table covering
  gemini-3.1-flash-live-preview (Preview, Gemini Live API only),
  gemini-2.5-flash-native-audio-preview-12-2025 (Preview), and
  gemini-live-2.5-flash-native-audio (now GA, not "public preview").
- Document what Gemini 3.1 Live does not support: proactivity, affective
  dialog, async function calling, thinking_budget (it uses thinking_level),
  plus multi-part server events and the turn-coverage default change.
- Note that no Gemini 3.x Live model exists on Agent Platform, and that Live
  API models are unavailable in the `global` location.
- voice.md: replace the Platform Compatibility text, which wrongly said
  proactivity and affective dialog are unavailable on Agent Platform, with a
  per-model support table.
- configuration.md: CFC's model check is a literal `gemini-2` prefix match, so
  it rejects Gemini 3.x; refresh the runners.py line anchor.
- bidi-demo: same model table in the README, the 3.1 option and the regional
  location requirement in .env.example, and an expanded model comment in
  agent.py. The default stays on 2.5 native audio because the demo exposes
  proactivity and affective dialog toggles. Re-anchored the agent.py line
  links in models.md, tools.md, and sessions.md.

* docs(live): align docs with current Live API model capabilities

Verified docs/live/ and docs/runtime/runconfig.md against the Gemini Live
API capabilities guide, the Agent Platform Live API docs, and ADK 2.6.3.

Model consistency:

- response_modalities=["TEXT"] was presented as a valid live configuration
  in configuration.md, events.md and sessions.md. Every Live API model ADK
  supports is a native audio model, and those accept AUDIO only. Reframed
  around AUDIO plus output audio transcription, and kept TEXT where it is
  actually correct: the run_async() / SSE path.
- docs/runtime/runconfig.md configured response_modalities=["AUDIO","TEXT"]
  in all three language samples. A session accepts exactly one modality.
- events.md snippets read event.content.parts[0], which drops content on
  gemini-3.1-flash-live-preview because it sends multiple parts per server
  event -- the failure models.md already warns about. All four snippets now
  iterate over parts.
- tools.md gave the streaming-tools root agent model="gemini-flash-latest",
  which has no Live API support, so the example could not run under
  run_live() on either platform. That alias is still used for the one-shot
  generate_content call inside the tool, where it is correct.
- configuration.md "Standard Gemini Models (1.5 Series) Accessed via SSE"
  described a retired model family and labelled gemini-pro-latest /
  gemini-flash-latest as 1.5 with 2M context.
- sessions.md: document that send_client_content is seeding-only on Gemini
  3.x Live, and that ADK reroutes single-part text to send_realtime_input.
- models.md: gemini-live-2.5-flash-native-audio is the only GA Live API
  model on Agent Platform, not the only one.

Coverage and links:

- configuration.md: document explicit_vad_signal, translation_config,
  avatar_config and model_input_context.
- voice.md: note that ADK picks the live API version (v1alpha / v1beta1),
  so proactivity and affective dialog need no http_options.
- Replace redirecting upstream URLs with their current targets:
  live-guide -> live-api/capabilities, live-session ->
  live-api/session-management, live -> live-api, and
  cloud.google.com/vertex-ai -> the Agent Platform equivalents.

Verified correct, left alone: session and context limits, audio and video
specs, the proactivity / affective dialog model matrix, thinking_level vs
thinking_budget, the support_cfc gemini-2 prefix check, and ADK's AUDIO
default in run_live().

* docs(live): trim the response-modality and SSE material

Every Live API model ADK supports is a native audio model, so a live
session's response modality is always AUDIO and there is nothing to
choose. Shrink the section to the one thing that still matters --
reading text off event.output_transcription.

StreamingMode is only read by run_async(); the SSE tutorial that grew
around it here (protocol diagrams, progressive-streaming walkthrough,
mode-selection table, 1.5-series model list) duplicates
runtime/runconfig.md and describes models that no longer exist. Keep
the inert-BIDI warning and the run_live()/run_async() split, drop the
rest.

Document explicit_vad_signal, translation_config, avatar_config and
model_input_context, which had no coverage at all.

* docs(live): cut duplicated and non-ADK material

Six sections carried weight that did not belong to them:

- sessions.md 'Best Practices for Live API Connection and Session
  Management' restated the Session Resumption and Context Window
  Compression sections verbatim, down to the RunConfig snippets.
  Deleted.
- sessions.md 'Concurrency and Thread Safety' + 'Message Ordering
  Guarantees' explained asyncio.Queue at length and reproduced the
  upstream task already in custom-server.md. Condensed to the three
  properties that actually affect calling code, with a pointer to
  the private _queue attribute dropped.
- sessions.md 'Architectural Patterns for Managing Quotas' was an
  ASCII decision tree and a comparison table for two patterns that
  reduce to one sentence each.
- index.md 'Real-world applications' spent five industry vignettes
  making one point.
- events.md 'Deserializing on the Client' pasted 80 lines of the
  bidi-demo's UI code, calling helpers that no longer exist anywhere
  in these docs. Reduced to the event-shape handling it was meant to
  show.
- audio-video.md 'Handling Image Input at the Client' was 130 lines
  of getUserMedia/canvas/FileReader boilerplate plus a seven-point
  recap of it.

Also fix two dead absolute links: /agents/multi-agents/#workflow-agents-as-orchestrators
(the page now redirects to workflows/index.md and the anchor is gone)
and /live/streaming-tools/ (no such page; the content is in tools.md).

* docs(live): restructure the live docs around ADK ownership

The live section had accumulated content it did not own: backend limits
restated on capability pages, Web Audio API implementation presented as
ADK guidance, and shared concepts re-explained rather than linked.

Applies one rule throughout: if a fact would still be true with the ADK
source deleted, it belongs on models.md or behind an upstream link, not
on a capability page.

- audio-video.md is now the format contract only (505 -> 121). The
  browser mic-capture, ring-buffer playback, and camera-frame code was
  Web Audio API with no ADK in it, had no counterpart in adk-python, and
  no test anywhere. Deleted rather than relocated. The twelve numbered
  'Key Implementation Details' lists restated the code comments directly
  above them; deleted. The streaming-tool lifecycle section duplicated
  tools.md; replaced with a link.
- custom-server.md gains 'Connect a client': what adk web handles
  (16 kHz capture, 24 kHz playback, 1 fps JPEG, transcripts, barge-in),
  where it stops, and the /run_live wire protocol, which was previously
  undocumented. Keeps the one JS snippet that shows ADK's event shape.
  Drops 'Client-side patterns'.
- sessions.md hands its platform-limits table and quota numbers to
  models.md, keeping the session-pool design guidance. The same figures
  had been stated in three places across two pages.
- models.md gains 'Platform limits and quotas' as the single source, and
  loses the 'Key characteristics' list that restated configuration.md.
- configuration.md drops the 'Platform Support' column, which read
  'Both' on 13 of 15 rows and labelled the two exceptions as platform
  constraints when they are model constraints.
- tools.md compresses 'Tool execution context' to the one fact that is
  live-specific: an InvocationContext spans the whole run_live() loop,
  not a single turn.
- workflows.md points at graphs/index.md, the ADK 2.0 graph workflow
  page, rather than the v0.1.0 multi-agent umbrella.
- Six internal links used absolute paths, which mkdocs does not
  validate, so --strict had been silently ignoring them. Now relative.
- Fixes class.="grid cards" in get-started/index.md, which was breaking
  the card grid.

* docs(live): standardize page leads and cut duplicated RunConfig prose

Every live page opened by narrating its own table of contents ("This page
covers X, Y, and Z"), which duplicates the rendered TOC, ages badly when
a heading changes, and spends a paragraph before the reader gets a fact.
evaluation.md already did the better thing: state the shared baseline,
link the canonical page, then cover only the delta. That is now the
convention across the section.

- sessions.md, events.md, configuration.md, audio-video.md,
  workflows.md, tools.md, models.md and get-started/index.md now name
  their non-live counterpart in the lead instead of listing their own
  headings. Three pages had no outbound link to the shared concept at
  all: tools.md to Custom Tools, models.md to Models for agents, and
  workflows.md pointed at the v0.1.0 umbrella rather than graph
  workflows.
- configuration.md drops the custom_metadata section (85 lines) for a
  pointer plus the one live-specific consequence: a run_live() call is a
  single invocation, so metadata is stamped on the whole session rather
  than one turn. runtime/runconfig.md already owns the field.
- configuration.md trims max_llm_calls and save_live_blob to the facts
  that are live-specific — max_llm_calls does not apply to run_live() at
  all, and save_live_blob writes ~1.92 MB per minute per session to two
  services — and drops the generic use-case and best-practice lists.
- custom-server.md replaces 'Key concepts', which re-pasted all three
  code blocks from the complete example directly above it, with prose
  explaining why the two tasks must run concurrently.

Live section: 2820 -> 2211 lines.

* docs(live): reframe pages around capabilities, fix eval config key

* Apply batched suggestions from code review

Co-authored-by: Joe Fernandez <931947+joefernandez@users.noreply.github.com>

* Apply suggestion from @joefernandez

* Apply batched suggestions from code review

Co-authored-by: Joe Fernandez <931947+joefernandez@users.noreply.github.com>

---------

Co-authored-by: Stephen Allen <stephenaallen@google.com>
Co-authored-by: Joe Fernandez <931947+joefernandez@users.noreply.github.com>
2026-09-01 17:15:50 -07:00

12 KiB

Tools for live agents

Supported in ADKPython v0.1.0Java v0.2.0

Tools work in a live agent much as they do anywhere else in ADK: you pass functions to an agent and the model calls them. How you write a tool does not change under a live connection, so tool definitions, tool context, callbacks, and authentication all follow Custom Tools.

A live connection adds two capabilities on top. ADK executes tool calls for you inside the run_live() loop, so you never write the function-call plumbing the raw Live API would require. Live agents can also use streaming tools: functions that stay running and push intermediate results back to the agent, so the agent can react to a stock price moving or a person appearing in a video frame without the user asking again.

Automatic tool execution

Define tools on your agent and ADK calls them for you inside the run_live() loop: it detects the model's function calls, runs the tools (in parallel, with your before/after callbacks), formats the responses, and yields both the call and the response as events. You write the function, not the plumbing.

import os
from google.adk.agents import Agent
from google.adk.tools import google_search

agent = Agent(
    name="google_search_agent",
    model=os.getenv("DEMO_AGENT_MODEL", "gemini-live-2.5-flash-native-audio"),
    tools=[google_search],
    instruction="You are a helpful assistant that can search the web.",
)

You observe tool activity through the event stream; you never drive it:

async for event in runner.run_live(...):
    if event.get_function_calls():
        print(f"Model calling: {event.get_function_calls()[0].name}")
    if event.get_function_responses():
        print(f"Tool result: {event.get_function_responses()[0].response}")

Keeping the agent responsive

A slow tool is survivable in a chat window, where the user watches a spinner. In a live voice conversation it is not: if the agent calls a ten-second API and goes silent, the user assumes the call dropped. You need a tool that does not block the conversation while it runs. ADK gives you two ways to do that, plus plain blocking for the fast case:

Your situation Use How
Tool returns in under a second Blocking (the default) A normal return tool
Long wait with nothing to narrate Non-blocking tool Set response_scheduling on the tool
Long wait worth narrating Streaming tool yield progress from an async generator

Non-blocking tools

Some waits have nothing worth narrating: a long analytics query, a batch export, a media generation job. Progress updates the user did not ask for interrupt the conversation for no benefit. Keep your plain return-once tool and set response_scheduling to move it to the background:

from google.adk.tools import FunctionTool
from google.genai import types

async def export_report(region: str) -> dict:
    """Generate and store the quarterly report. Returns when the export finishes."""
    await run_export(region)  # a long, plain return-once operation
    return {"status": "done", "region": region}

report_tool = FunctionTool(export_report)
report_tool.response_scheduling = types.FunctionResponseScheduling.WHEN_IDLE

The agent stays free while the tool runs, answers whatever else the user brings up, and folds the result in when it is ready. A runnable example ships as the live_non_blocking_tool_agent sample.

!!! note "Requires Python 2.4+"

`response_scheduling` was added in adk-python 2.4, and support is per model. See
[Supported models](models.md#live-models).

response_scheduling also controls when a finished result reaches the user:

Value Behavior Use it for
WHEN_IDLE Waits for a natural pause Reports and lookups, the usual choice
INTERRUPT Delivers immediately Alarms, failures, "the transfer failed"
SILENT Enters context, announced only if relevant Background info the model may use later

Streaming tools

A streaming tool stays running and pushes intermediate results back to the agent, so the agent can narrate progress or react to a changing input (a stock price, a person entering a video frame) without the user asking again. Making a tool stream is a one-line change: an async function that yields instead of returns. ADK treats any async-generator tool as non-blocking automatically.

import asyncio
from typing import AsyncGenerator

async def query_sales_database(region: str) -> AsyncGenerator[str, None]:
    """Run the quarterly sales report. Call this once; it streams its own updates."""
    yield "Connecting to the warehouse..."
    await asyncio.sleep(4)
    yield "Aggregating by product line..."
    await asyncio.sleep(4)
    yield f"Done. {summarise(region)}"

Pass it to tools=[...] like any other tool. The model gets each yield as a live update, so instead of silence the user hears "let me pull those up... still aggregating... got it: EMEA did $4.81M, up 12.4%." This suits RAG pipelines, multi-stage aggregation, and build-and-test runs, anywhere the progress is worth telling.

Add ADK's reserved stop_streaming tool (an empty function ADK intercepts by name) so users can cancel: "never mind, cancel that."

Video streaming tools

Add an input_stream: LiveRequestQueue parameter and ADK feeds the user's realtime input into a dedicated queue for that tool, so it can pull video frames and react to them.

Requirements for any streaming tool:

  • It must be an async function typed to return an AsyncGenerator[T, None], where T is the type you yield.
  • For video, add input_stream: LiveRequestQueue; ADK fills it in.

The pattern below drains the queue to the newest frame, discarding stale ones, and yields only when the answer changes so the agent stays quiet otherwise.

=== "Python"

```python
import asyncio
import os
from typing import AsyncGenerator

from google.adk.agents import LiveRequestQueue
from google.adk.agents.llm_agent import Agent
from google.adk.tools.function_tool import FunctionTool
from google.genai import Client
from google.genai import types as genai_types

PROMPT = "How many people are in this image? Reply with a number only."


async def monitor_video_stream(
    input_stream: LiveRequestQueue,
) -> AsyncGenerator[str, None]:
  """Report how many people are visible, whenever that number changes."""
  client = Client()
  last_count = None

  while True:
    # Drain the queue and keep only the newest frame; older ones are stale.
    latest = None
    while input_stream._queue.qsize() != 0:
      req = await input_stream.get()
      if req.blob and req.blob.mime_type == "image/jpeg":
        latest = req

    if latest is not None:
      response = client.models.generate_content(
          model="gemini-flash-latest",
          contents=genai_types.Content(
              role="user",
              parts=[
                  genai_types.Part.from_bytes(
                      data=latest.blob.data, mime_type=latest.blob.mime_type
                  ),
                  genai_types.Part.from_text(text=PROMPT),
              ],
          ),
      )
      count = response.candidates[0].content.parts[0].text.strip()
      if count != last_count:
        last_count = count
        yield count

    await asyncio.sleep(0.5)


# ADK intercepts this by name; the body stays empty.
def stop_streaming(function_name: str):
  """Stop a running streaming tool.

  Args:
    function_name: The name of the streaming function to stop.
  """


root_agent = Agent(
    # Streaming tools run under run_live(), so the root agent needs a Live
    # model. gemini-flash-latest above is only for the one-shot call in the tool.
    model=os.getenv("DEMO_AGENT_MODEL", "gemini-live-2.5-flash-native-audio"),
    name="video_monitoring_agent",
    instruction=(
        "You monitor the user's video stream. Call monitor_video_stream once when"
        " asked, then report each update it sends. Never call it again to poll."
    ),
    tools=[monitor_video_stream, FunctionTool(stop_streaming)],
)
```

=== "Java"

```java
import com.google.adk.agents.LiveRequestQueue;
import com.google.adk.agents.LlmAgent;
import com.google.adk.tools.Annotations.Schema;
import com.google.adk.tools.FunctionTool;
import com.google.genai.Client;
import com.google.genai.types.Content;
import com.google.genai.types.GenerateContentConfig;
import com.google.genai.types.Part;
import io.reactivex.rxjava3.core.Flowable;
import java.util.Arrays;
import java.util.Map;
import java.util.concurrent.TimeUnit;

public class StreamingTools {

  private static final String PROMPT =
      "How many people are in this image? Reply with a number only.";

  // `inputStream` is a reserved parameter name; ADK passes the video stream in.
  @Schema(description = "Report how many people are visible, whenever that number changes.")
  public static Flowable<Map<String, Object>> monitorVideoStream(
      @Schema(name = "inputStream") LiveRequestQueue inputStream) {
    Client client = Client.builder().build();

    return inputStream
        .get()
        .filter(req -> req.blob().isPresent()
            && "image/jpeg".equals(req.blob().get().mimeType()))
        .sample(500, TimeUnit.MILLISECONDS)  // newest frame every 0.5s
        .map(req -> client.models().generateContent(
                "gemini-flash-latest",
                Content.builder()
                    .role("user")
                    .parts(Arrays.asList(
                        Part.builder().inlineData(req.blob().get()).build(),
                        Part.fromText(PROMPT)))
                    .build(),
                GenerateContentConfig.builder().build())
            .text())
        .distinctUntilChanged()  // yield only when the count changes
        .map(count -> Map.of("result", count));
  }

  // ADK intercepts this by name; the body stays empty.
  @Schema(description = "Stop a running streaming tool.")
  public static void stopStreaming(
      @Schema(name = "functionName", description = "The streaming function to stop.")
      String functionName) {}

  public static void main(String[] args) {
    LlmAgent rootAgent =
        LlmAgent.builder()
            .model("gemini-live-2.5-flash-native-audio")
            .name("video_monitoring_agent")
            .instruction(
                "You monitor the user's video stream. Call monitorVideoStream once when"
                    + " asked, then report each update it sends. Never call it again to poll.")
            .tools(Arrays.asList(
                FunctionTool.create(StreamingTools.class, "monitorVideoStream"),
                FunctionTool.create(StreamingTools.class, "stopStreaming")))
            .build();
  }
}
```

Try it by asking the agent to monitor how many people are in the video stream, then walking in and out of frame.

Tool execution context

A tool or callback receives an InvocationContext for state, history, and artifacts. It works the same as in any ADK agent — see Agent context — with one difference that matters live: one InvocationContext spans the entire run_live() loop, created when you call run_live() and living across every agent and every turn until the session ends. In a request/response agent an invocation is a single turn; in a live session it is the whole conversation.

Two fields come up most in live tools:

Field What it gives you
context.run_config The session's configuration — response modalities, transcription, limits
context.end_invocation Set to True to terminate the whole streaming session immediately