A2UI Comes to Gemini Enterprise: Agent-Generated UIs for Business Workflows
Gemini Enterprise is integrating A2UI so enterprise agents can render rich, interactive UIs — data entry forms, approval dashboards, workflow automation — instead of plain text. Learn how it works and the current registration-path limitation.
Published on • October 21, 2026
AI Assistant
Most enterprise AI agents today answer questions. The harder, more valuable task — guiding an employee through a multi-step workflow, collecting structured data, surfacing an approval that needs a human decision — still falls back to hand-built forms and dashboards. A2UI, the Agent-to-User Interface protocol, is closing that gap inside Gemini Enterprise, letting agents generate the interface a task actually needs instead of returning a wall of text.
Source: A2UI in the World, the A2UI project.
From answers to interfaces
A2UI standardizes how an AI agent and a client application collaborate on UI. The agent does not just emit prose; it emits a declarative UI specification — components, layout, data bindings, and interaction handlers — that the client renders natively. In Gemini Enterprise, this means an agent can produce a data-entry form, an approval dashboard, or a step-by-step automation interface on the fly.
The value proposition is specific and enterprise-shaped:
- Data entry forms — AI-generated forms for structured collection, rather than a free-text box.
- Approval dashboards — dynamic UIs for review-and-approve processes.
- Workflow automation — step-by-step interfaces for complex, multi-stage tasks.
- Custom enterprise UIs — interfaces tailored to industry-specific needs.
As Fred Jabbour, Product Manager for Gemini Enterprise, puts it: “Our customers need their agents to do more than just answer questions; they need them to guide employees through complex workflows. A2UI will allow developers building on Gemini Enterprise to have their agents generate the dynamic, custom UIs needed for any task, from data entry forms to approval dashboards.”
Why a protocol, not a widget library
The decision to build on A2UI rather than a proprietary rendering layer is deliberate. A2UI is an open protocol with a declarative core, and it decouples the agent from the renderer. The same agent can serve a Flutter mobile app, a web client, and a desktop surface, because each client interprets the same A2UI specification using its own native widgets.
This is exactly how Flutter’s GenUI SDK consumes A2UI under the covers — one agent, native rendering on every platform, brand-consistent design systems. For Gemini Enterprise, the same property means an enterprise agent’s UI is not locked to a single Google surface; it renders on any A2UI-capable client.
A2UI is also designed with the enterprise concerns in mind — a declarative specification that clients can validate, sandbox, and constrain, rather than arbitrary code execution.
The current limitation: registration path matters
There is a real caveat today, and it is worth planning around. A2UI rendering in Gemini Enterprise currently requires self-serve agents registered through the Agent-to-Agent (A2A) path — the a2aAgentDefinition route.
Managed agents deployed on Vertex AI Agent Engine and registered via the adkAgentDefinition path do not currently support A2UI rendering.
If your architecture deploys agents as managed Vertex AI Agent Engine resources and registers them through ADK, you will not get A2UI rendering yet. The workaround is to register the agent through the A2A self-serve path. Watch this boundary: it is the kind of gap that closes as the integration matures, but today it decides whether your agent can emit rich UI at all.
How this fits the broader A2UI ecosystem
Gemini Enterprise is one node in a growing A2UI adoption map. Google Opal uses A2UI to power its AI mini-apps. The Flutter GenUI SDK uses it as the underlying protocol for mobile, desktop, and web. Google ADK’s developer UI renders A2UI components natively and handles A2UI↔A2A message conversion. Partner integrations — AG-UI/CopilotKit with day-zero compatibility, AG2’s A2UIAgent with schema validation and retry — extend it beyond Google’s own stack.
The common thread is standardization: rather than each team inventing its own server-driven UI format, A2UI gives agent-generated interfaces a shared, declarative contract that any conformant client can render.
Key takeaways
A2UI in Gemini Enterprise moves enterprise agents from answering questions to driving workflows — forms, approvals, and automation interfaces generated on demand and rendered natively on any A2UI-capable client. The protocol-based approach keeps agents decoupled from renderers and reuses the same machinery behind Flutter’s GenUI SDK and Google Opal. The one planning constraint today is registration path: A2UI rendering currently requires the A2A self-serve path (a2aAgentDefinition), not the managed ADK path on Vertex AI Agent Engine.