A2UI rendering for ADK agents on Vertex AI Agent Engine / Gemini Enterprise adkAgentDefinition registrations

[dayglo]

Summary

There is currently no way for an ADK agent deployed on Vertex AI Agent Engine and registered in Gemini Enterprise via adkAgentDefinition (provisionedReasoningEngine) to render A2UI in the Gemini Enterprise UI. A2UI rendering in GE appears to work only on the a2aAgentDefinition path (agent card advertising the A2UI extension, UI payloads travelling as A2A DataParts into QueryPart.uiJsonPayload).

The roadmap lists ADK integration as "🚧 In Progress — still designing developer ergonomics". This is a request to make Agent-Engine-hosted ADK agents surfaced through Gemini Enterprise a first-class target of that design, not just local/self-served ADK agents.

Context — production impact

We are a Gemini Enterprise production customer. We had A2UI working end to end in the GE chat panel (interactive investigation forms, live progress checklists) with agents served over Cloud Run A2A using a2ui-agent-sdk's A2A executor integration and an agent card carrying the A2UI v0.8 extension.

We then migrated those agents to the recommended canonical shape — AdkApp on Vertex AI Agent Engine, registered in GE as adkAgentDefinition — and A2UI rendering silently stopped. Tracing it, the whole chain is A2A-specific and the ADK/Agent Engine path has no equivalent for any link:

1. Agent side: a2ui-agent-sdk hooks the A2A agent executor to convert tool-emitted A2UI payloads into A2A DataParts. AdkApp/streamQuery has no executor and no converter, so the A2UI JSON rides along as opaque tool-response content.
2. Registration side: adkAgentDefinition exposes a single field (provisionedReasoningEngine.reasoningEngine) — there is no way to advertise the A2UI extension or any UI capability.
3. Transport side: GE's rendering slot (QueryPart.uiJsonPayload, documented as A2UI-only as of Q1 2026) is populated from A2A DataParts; there is no documented mapping from Agent Engine streamQuery events.

So teams currently face a choice between the recommended ADK/Agent Engine serving shape (losing A2UI in GE) or legacy self-served A2A (keeping A2UI, losing the benefits of the managed path).

Request

Any of the following would close the gap — listed in rough order of preference:

1. A supported mechanism for A2UI on the ADK/Agent Engine path end to end: an ADK-native way to emit A2UI (e.g. the Agents SDK writing A2UI parts into the event stream) plus GE mapping streamQuery events into uiJsonPayload.
2. Native A2A serving on Agent Engine reaching a usable state, so Agent-Engine-hosted agents can register in GE as a2aAgentDefinition with the A2UI extension — making the existing A2A-based A2UI support apply.
3. At minimum: documentation stating clearly that A2UI in Gemini Enterprise requires the A2A registration path, so teams migrating to adkAgentDefinition know the trade-off before they make it.

Questions

• Is GE-surfaced ADK/Agent Engine rendering in scope for the in-progress ADK integration on the roadmap?
• Is there a preview / trusted-tester programme covering this? We are a production consumer of the capability with daily deployments and eval harnesses exercising the full GE wire path, and can turn feedback around quickly.

Environment

• google-adk 2.3.0 (Python), a2ui-agent-sdk 0.2.1 (A2UI v0.8 envelopes)
• Vertex AI Agent Engine (Reasoning Engine, AdkApp), Gemini Enterprise EU
• GE A2UI-over-A2A registration: working (April 2026 preview); adkAgentDefinition: no rendering

[josemontespg]

A2UI Triage: @nan-yu can you look into this? Thanks!