How to implement HITL (Human-in-the-Loop) with runner.run_live() bidirectional streaming?

[bashiryounis]

Question

I'm trying to implement HITL (Human-in-the-Loop) with runner.run_live() for bidirectional audio streaming. I have a LongRunningFunctionTool that uses tool_context.request_confirmation().

The Problem

When the tool is called in live mode:

• event.long_running_tool_ids contains the function call ID
• But event.actions.requested_tool_confirmations is empty {}
• The confirmation data only appears in the session (via session_service.get_session()), not in the live event stream

Current Workaround

I'm checking the session on each event to detect pending confirmations:

async for event in runner.run_live(...):
    session = await session_service.get_session(app_name, user_id, session_id)
    for session_event in session.events:
        if session_event.actions.requested_tool_confirmations:
            # Found pending confirmation here, not in live event

Questions

• Is this the correct way to detect HITL requirements in run_live() mode?
• How should I send the approval response back? Is live_request_queue.send_content() with FunctionResponse correct?
• Is there documentation or sample for HITL with bidirectional streaming?

Environment

• ADK version: 1.x
• Python: 3.12
• Using: runner.run_live() with LongRunningFunctionTool

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: Your current method of checking the session for pending confirmations is likely necessary because request_confirmation() pauses the agent run. To send the approval, you should initiate a new run with a FunctionResponse, rather than using the existing live_request_queue. There is a human_tool_confirmation sample that demonstrates this exact Human-in-the-Loop (HITL) pattern.

---

Hello! Here is a more detailed breakdown based on the ADK documentation:

1. Detecting HITL Requirements in run_live()

You are correct that the confirmation request does not appear in the live event stream from runner.run_live(). This is the expected behavior. When a tool uses tool_context.request_confirmation(), especially a LongRunningFunctionTool, it signals to the ADK runner to pause the agent's execution until it receives the required confirmation. [1] The run is effectively paused, so no new events related to that run will stream out.

Therefore, your current workaround of polling the session state to discover pending confirmations is a valid approach to detect when human intervention is required.

2. Sending the Approval Response

To send the approval (or denial) back, you should send a FunctionResponse event. However, this should not be sent through the live_request_queue of the original streaming call. The live_request_queue is for sending content during an active conversation stream.

Since the original run is paused, you need to provide the FunctionResponse by starting a new run that includes the confirmation data. The response should contain the name of the function that was called and the response payload with a "confirmation" dictionary. [1]

3. Documentation and Samples

While there isn't a single document that combines bidirectional streaming with HITL, the pieces are available in the documentation.

For a complete, working example of the HITL pattern, you should review the human_tool_confirmation sample agent. [2, 3] This sample demonstrates the end-to-end flow:

• A tool requests confirmation.
• The run is paused.
• The client application checks for the pending confirmation and then sends a FunctionResponse to resume the run.

This sample is the best resource for understanding how to implement this pattern correctly.

[1] Tool Confirmation

[2] Function Tools

[3] human_tool_confirmation sample agent.py

[jagmarques]

The streaming HITL flow is tricky because the confirmation event arrives mid-stream. You need to buffer the stream, pause on confirmation events, wait for user input, then resume. If you are using the web runner, the confirmation state needs to persist across SSE reconnects or you lose the pending approval.

[pandego]

I dug through the current ADK source/tests, and the resume contract is a bit narrower than the session shape makes it look.

What ADK itself treats as the HITL boundary is the synthetic function call adk_request_confirmation, not the original tool call.

Source-backed bits:

• src/google/adk/flows/llm_flows/functions.py builds a synthetic FunctionCall(name="adk_request_confirmation", ...) when requested_tool_confirmations is present, and marks that synthetic call as long-running.
• tests/unittests/runners/test_run_tool_confirmation.py resumes by sending a user FunctionResponse whose id is the synthetic confirmation call id and whose name is adk_request_confirmation.
• src/google/adk/flows/llm_flows/request_confirmation.py then looks specifically for user FunctionResponses with name == "adk_request_confirmation" and uses those to re-execute the original tool.

So the practical shape is:

confirmation_part = types.Part(
    function_response=types.FunctionResponse(
        id=request_confirmation_call_id,      # the synthetic adk_request_confirmation call id
        name="adk_request_confirmation",
        response={"confirmed": True},        # or your payload schema
    )
)

A couple implications for your questions:

1. session_service.get_session() is a reasonable fallback if your live transport is not surfacing the synthetic confirmation call, but I would treat that as a transport gap, not the intended primary API.
2. The thing to send back is not a FunctionResponse to the original tool id. It should target the synthetic adk_request_confirmation call id.
3. For non-live/resumable runs, the documented/sample path is to send that FunctionResponse as a new user message in a follow-up run_async(...) call. For an active run_live() connection, live_request_queue.send_content(Content(role="user", parts=[...])) looks like the analogous transport, but the critical piece is still the adk_request_confirmation id/name pair above.

The closest samples I found were:

• contributing/samples/human_tool_confirmation/agent.py
• contributing/samples/human_in_loop/README.md
• tests/unittests/runners/test_run_tool_confirmation.py

If it helps, I can turn this into a minimal run_live() example that shows the exact event to watch for and the exact send_content(...) payload to send back.