As Software Becomes Autonomous, It Will Also Become Dynamic
For a long time, the interface was the product. Screens were designed, shipped, and frozen. Agents lived underneath — if they lived at all — and the UI stayed a static map of what the software already knew how to do.
That model breaks when software starts acting on its own.
An autonomous agent does not only answer in text. It books, routes, approves, escalates, requests credentials, asks a human to choose among three options that did not exist when the page was designed. If the only channel left is a chat bubble, you get a slow interrogation. If the agent can invent a form, a picker, an approval card — shaped for this task, right now — the work moves at the speed of the decision.
As software becomes autonomous, it will also become dynamic. The UI stops being a fixed artifact and becomes a stream the agent can update. That is the shift Google's A2UI (Agent-to-UI) is built for — and why it already shows up inside Supervaize, starting with how we configure agents like Aidan.
What A2UI is
A2UI is an open protocol (and open-source project) for agent-driven interfaces. Agents do not send HTML or JavaScript for the client to execute. They send a declarative description of UI — structured messages: create a surface, update components, update the data model, delete a surface. The client maps those descriptions onto a catalog of trusted, pre-approved native components (cards, buttons, fields, and whatever the host app has blessed). Our Supervaize catalog is public to operators on the design system: A2UI components.
Three consequences matter for anyone running agents in production:
1. Security across trust boundaries. Remote agents — including agents owned by someone else in a multi-agent mesh — cannot inject arbitrary code into your app. They can only request components from your catalog. UI travels as data, not as executable payload.
2. Native feel. No iframe sandbox that looks like a foreign island. The host renders with its own widgets, styling, and accessibility.
3. Portability. One agent response can render on web, mobile, or desktop clients that speak A2UI. The agent describes what; the client owns how it looks.
Google framed A2UI for exactly the world A2A opened: agents collaborating across organizations, where the agent doing the work often cannot touch your DOM. Text-only back-and-forth is a tax. A date picker and a submit button generated for the task at hand is how autonomous software should meet a human.
Why dynamic UI is a control problem
At Runwaize we spend our days on the other half of autonomy: control. Supervaize is how teams operate agents under scrutiny. Supervaizer is how builders make agents controllable, auditable, and interoperable.
Control is not only logs and kill switches. It is also the moment a human has to step in — approve a spend, pick a path, confirm an identity, fill a field the policy requires. Those moments have historically been bolted on as static screens or buried in chat. Neither scales when the agent invents a new decision shape every hour.
Dynamic UI is how human-in-the-loop stays operative instead of ornamental. The agent proposes a surface. The client renders it natively. The human acts. The decision is logged. The workflow continues. That loop only works if the UI channel is as first-class as the agent-to-agent channel.
How we are using it
A2UI is live in Supervaize Studio today — not as a slide, as the configuration UI itself.
Take Aidan, our AI interviewer. When you open a job and configure a campaign, the Campaign setup surface — campaign template, name, description, anonymized, registration, session-link expiry, end date — is built from A2UI components in our catalog. The agent (and the Studio host) describe the form; Supervaize renders it natively inside the same control plane operators already use for monitoring, escalation, and audit.
Supervaize Studio — Aidan Campaign setup (A2UI Parameters form). Components from our A2UI catalog.
That is the point of the protocol in a product you run every day: when the interviewer's setup shape changes, the surface can change with it — without shipping a one-off screen, and without letting the agent execute arbitrary code in the browser.
On the builder side, we are also wiring A2UI into Supervaizer (the open-source controller agents embed) so dynamic surfaces travel with the controllable runtime — not as a side experiment. Studio is the live proof; the Controller path is how builders get the same pattern at the edge.
The point is not prettier chat. It is that autonomous work and dynamic interface travel together, under the same trust and policy layer.
Protocols are how the stack stays coherent
A2UI does not replace the rest of the agent stack. It sits next to it.
We already treat A2A (Agent-to-Agent) as a first-class interoperability path on the Controller — agents that can collaborate without sharing memory or a codebase. We also support ACP alongside the security primitives builders need (RBAC, secret management). A2UI is the UI-shaped sibling of that story: agents that can talk to each other and present safe, native interfaces to the humans who supervise them.
Transports and neighbors in the wider ecosystem include AG-UI (host/app scaffolding that can carry A2UI payloads) and MCP (tools and resources; MCP Apps take a different, often iframe-based approach to UI-as-resource). We care about the seam: agents, tools, and UIs should speak protocols — not one-off sockets — so the control plane stays coherent as the mesh grows.
The names will keep evolving. The principle will not: autonomy without a protocol story is a demo; autonomy with A2A, A2UI, and a real control layer is an operating system for agents.
What changes for enterprises
When software is static, UX is a design project. When software is autonomous, UX is an operations project:
- Approval and exception paths appear when the agent needs them — not only when a designer foresaw them
- Remote and third-party agents can contribute UI without getting code-execution rights in your app
- The same control, audit, and policy story covers the decision and the surface that collected it
- Teams stop choosing between "chat forever" and "ship another fixed screen"
That is the enterprise case for dynamic UI. Not novelty. Continuity of control as the interface starts moving.
The shape of what is coming
We are early. Specs will move. Catalogs will grow. Competitors will ship their own agent-UI surfaces. That is healthy.
What we are betting on is simpler: the agents that win in production will not only reason well — they will present well, safely, inside systems operators already trust. A2UI is how that presentation stays declarative. Supervaize — and the Controller path we are wiring for builders — is how it stays under control.
Autonomous software was never going to live forever behind a fixed UI. Dynamic interfaces are not a feature on the side. They are what autonomy looks like when it meets a human — and a protocol.
— Alain Prasquier
Founder & CEO, Runwaize