71–80 of 80 posts
In a context where you're chatting with an LLM, I suppose the user would expect some lag, but it would be unwelcome in regular apps.
This also means that a lot of other UI performance issues don't matter - form submission is going to be slow anyway, so just be transparent about the delay.
A few days ago I was predicting to some colleagues a revival of ideas around "server-driven UI" (which never really seemed to catch on) in order to facilitate agentic UIs. Feels good to have been on the money, but I'm also glad I didn't start a project only to be harpooned by Google straight away
Server Driven UI has absolutely caught on. Not including all the Electron apps out there, things like Instagram's native mobile apps have about half of their screens being SDUI at this point because Meta needs to be able to change them instantly, not with a 3 week release cycle.
Earlier quoted context omitted.
AGUI sounds similar: https://github.com/ag-ui-protocol/ag-ui
Same team! AGUI uses a2UI as the protocol under the hood.
AG-UI is a launch partner of A2UI, but it is a separate project by CopilotKit, not google.
We have a day-0 handshake between AG-UI & A2UI
Earlier quoted context omitted.
Well it is open source and they expect the community to add more renderers. So if you are a sveltekit specialist this could actually be an opportunity.
Plus 1! We’d love community contributions here!
https://github.com/google/A2UI/pull/352
Thanks for the recommendation.
Earlier quoted context omitted.
Same team! AGUI uses a2UI as the protocol under the hood.
Hi, one of the AG-UI authors here. AG-UI is a launch partner of A2UI, but it is a separate project by CopilotKit, not google. We have a day-0 handshake between AG-UI & A2UI
I think AG UI is great if you are building the UI and the Agent at the same time and want a high bandwidth sync between them and the UI supports AG UI as an adaptor layer (they have done a lot of work making this easier for folks).
A2UI is most interesting for it's LLM generation options (not tools but structured output), it's remote message passing options (if you don't own the UI), and it's general-purpose-ness (same fairly simple standard which can work for many models, transports, and renderers).
They do fit nicely together. Sorry the naming conventions are complicated. There are 2 hard things in computer science: naming things, cache invalidation, off by one errors.
So there's MCP-UI, OpenAI's ChatKit widgets and now Google's A2UI, that I know of. And probably some more... How many more variants are we introducing to solve the same problem. Sounds like a lot of wasted manhours to me.
Unlike many of those approaches which concern themselves with delivery of human-designed static UI, this seems to be a tool designed to support generative UIs. I personally think that's a non-starter and much prefer the more incremental "let the agent call a tool that renders a specific pre-made UI" approach of MCP UI/Apps, OpenAI Apps SDK, etc for now.
Making an agent call a tool to manipulate a UI does feel like normal application development and an event driven interaction... I get that.
What else drives your preference?
So there's MCP-UI, OpenAI's ChatKit widgets and now Google's A2UI, that I know of. And probably some more... How many more variants are we introducing to solve the same problem. Sounds like a lot of wasted manhours to me.
Obligatory https://xkcd.com/927/
I can justify A2UI as doing something not otherwise accomplishable in the market today, but you saw how long the blog post was trying to explain that. :shrug:
> A2UI lets agents send declarative component descriptions that clients render using their own native widgets. It's like having agents speak a universal UI language . (emphasis mine) Sounds like agents are suddenly able to do what developers have failed at for decades: Writing platform-independent UIs. Maybe this works for simple use cases but beyond that I'm skeptical.
platform independent UIs exist - HTML and Electron
> A2UI lets agents send declarative component descriptions that clients render using their own native widgets. It's like having agents speak a universal UI language . (emphasis mine) Sounds like agents are suddenly able to do what developers have failed at for decades: Writing platform-independent UIs. Maybe this works for simple use cases but beyond that I'm skeptical.
platform independent UIs exist - HTML and Electron
I see how useful a universal UI language working across platforms is, but when I look at some examples from this protocol, I have the feeling it will eventually converge to what we already have, html. Instead of making all platforms support this new universal markup language, why not make them support html, which some already do, and which llms are already trained on. Some examples from the documentation: { "id": "se…
A key challenge with HTML is client side trust. How do I enable an agent platform (say Gemini, Claude, OpenAI) to render UI from an untrusted 3p agent that’s integrated with the platform? This is a common scenario in the enterprise version of these apps - eg I want to use the agent from (insert saas vendor) alongside my company’s home grown agents and data. Most HTML is actually HTML+CSS+JS - IMO, accepting this is a…
Just like you do with your web browser. A web browser is a Remote Code Execution engine.