[Feature Request] Support inline action buttons/cards in ADK Web chat messages

[midnightnnn]

[Feature Request] Support inline action buttons/cards in ADK Web chat messages

Is your feature request related to a specific problem?

ADK Web currently does not provide a supported way for an agent/tool result to render first-class action buttons inside the chat transcript.

For production workflows that require explicit user approval, such as order submission, the host application needs to show an action like "Approve order" next to the assistant's proposed action. Without inline chat actions, the host app has to render an external modal/side panel and then bridge the result back into ADK Web.

I ran into this while embedding ADK Web into my own investment advisory/execution app. The app already has its own navigation/auth/account context, but ADK Web provides the chat transcript, tool traces, session handling, and developer/debug experience that I want to reuse instead of rebuilding from scratch.

The missing piece is an inline action primitive in the chat itself. Because that primitive is not available today, I had to implement a host-side workaround:

1. The agent validates an order draft through a tool.
2. The host page polls for pending order drafts outside the ADK iframe.
3. The host page renders a floating approval card beside the ADK Web chat.
4. When the user clicks the approval button, the host page submits the approval through a host API.
5. The host page then programmatically injects a follow-up message into the ADK Web chat so the agent can explain the result.

That workaround works, but it has real reliability and UX problems in this project:

• The approval UI is outside the chat transcript, so the user sees the decision outside the conversation where the order was proposed.
• The host page has to depend on ADK Web DOM details such as the chat textarea selector, send button selector, and loading/progress indicators.
• The host page has to synthesize a follow-up chat message just to tell the agent that an external button was clicked.
• If the injected message is sent while /run_sse is still updating the session, SQLite session storage can reject the update with a stale-session error:

The last_update_time provided in the session object is earlier than the update_time in storage. Please check if it is a stale session.

• If the follow-up message is intentionally generic, to avoid exposing raw approval tokens or broker/internal error details in chat, the agent has to call a status tool to rediscover what happened. That adds another fragile handoff.
• In one failure mode, the approval API returned a broker rejection, but because the result had to be bridged back through a separate status lookup rather than a native chat/session event, the agent initially failed to surface that result correctly.

These are not domain-specific trading UI problems. They are symptoms of an embedded ADK Web app needing a first-class way to ask the user for a structured action inside the chat turn and route the result back through the ADK session/event system.

Describe the Solution You'd Like

ADK Web should support inline action buttons/cards in chat messages or tool responses.

A possible shape:

• Agent/tool/event emits a structured chat action payload:
  • title/body
  • button label
  • action id / correlation id
  • optional payload
  • disabled/loading state
• ADK Web renders the action inline in the chat transcript.
• When the user clicks the action, ADK Web sends a structured event to the backend for the same app/user/session.
• The backend exposes the selected action to the agent/app as a resume event, tool response, or callback.
• The action result appears in the same chat transcript without DOM injection.

This might build on existing ADK concepts such as:

• context.request_confirmation(...)
• EventActions.requested_tool_confirmations
• context.render_ui_widget(...)
• long-running function resume / functionCallEventId

The exact API shape should be decided by ADK maintainers. The key requirement is that ADK Web renders the action inline and routes the click back through the session/event system safely.

Why this belongs in ADK Web instead of a custom host UI

I could build a completely custom chat UI around ADK backend APIs, but ADK Web already provides most of the interaction surface I want to keep:

• chat transcript
• tool call / tool response visualization
• session handling
• event inspection
• eval/debug workflows
• familiar ADK developer experience

Reimplementing all of that only to support one missing interaction primitive, inline user action buttons, would duplicate ADK Web and make embedded applications harder to maintain.

The missing piece is not a domain-specific trading UI. It is a general ADK Web capability: allowing an agent/tool result to ask the user to take a structured action inside the chat turn, then route that action back through the session/event system safely.

This would help any embedded ADK Web use case that needs explicit user approval, confirmation, selection, review, or human-in-the-loop continuation before proceeding.

Impact on your work

I am embedding ADK Web inside an investment advisory/execution app. The assistant can draft an order, but final submission must be explicit, visible, auditable, and safe.

Today I work around this by rendering an external approval panel and then sending the panel result back into the chat. A native ADK Web action button would make this flow safer and cleaner:

• approval stays in the conversation
• no DOM-selector coupling to ADK Web internals
• no synthetic chat-message injection
• fewer stale-session races
• better auditability for user decisions
• easier embedding of ADK Web in production applications

Willingness to contribute

Yes. I can help implement this after maintainers confirm the desired API shape and frontend build workflow.

Describe Alternatives You've Considered

• Building a fully custom chat UI on top of ADK APIs.

  • Technically possible, but it duplicates ADK Web features that already work well: tool traces, sessions, event display, and developer debugging flows.
  • The actual gap is much smaller: ADK Web needs a first-class inline action primitive.

• External host-side panel/modal next to the ADK iframe.

  • Works, but splits context and requires bridging results back into chat.

• Programmatically injecting a message into the ADK iframe input after the external button click.

  • Works as a workaround, but is brittle and can race with session updates.

• Asking users to type a confirmation phrase in chat.

  • Safe, but poor UX for production approval flows.

• Using tool-call traces only.

  • Useful for debugging, but not a user-facing approval UX.

Proposed API / Implementation

One possible API direction:

ctx.request_confirmation(
    hint="Submit BUY 1 GOOGL order?",
    payload={
        "approval_id": "...",
        "ticker": "GOOGL",
        "side": "BUY",
        "quantity": 1,
    },
)

or:

ctx.render_ui_widget(
    ChatActionCard(
        title="Approve order",
        body="GOOGL BUY 1",
        actions=[
            ChatAction(
                id="approve_order",
                label="Approve",
                payload={"approval_id": "..."},
            ),
            ChatAction(
                id="cancel_order",
                label="Cancel",
                payload={"approval_id": "..."},
            ),
        ],
    )
)

ADK Web would render the card inline and route the selected action to the backend/session as a structured event.

Additional Context

In my current workaround, the host app has to:

1. poll for validated action/order drafts outside the ADK iframe,
2. render a floating approval card in the host app,
3. submit the approval through a host API,
4. wait until ADK Web is no longer showing a progress/loading state,
5. inject a follow-up message into ADK Web so the agent can report the result,
6. provide a separate status tool so the agent can rediscover the approval result without exposing internal approval tokens in chat.

This works, but it couples an embedded app to ADK Web implementation details and session timing. A native inline action mechanism would make embedded ADK Web much more useful for human-in-the-loop applications.

Environment Details

• ADK version: 1.31.1
• Python version: 3.12.3
• OS: Linux on WSL2
• Platform detail: Linux-6.6.87.2-microsoft-standard-WSL2-x86_64-with-glibc2.39
• ADK Web embedding mode: ADK Web mounted/embedded inside a FastAPI host application
• Session storage involved in the stale-session failure mode: SQLite session service