Gaode Qianwen open-sources AGenUI: one set of code runs the Agent UI on three platforms
Amap, together with Alibaba’s Qwen consumer app team, has open-sourced **AGenUI**, which they describe as the industry’s first native A2UI framework integrating cloud and client that supports **iOS**, **Android**, and **HarmonyOS**. With it, developers no longer need to write a separate Agent interface for each platform.
This time, AutoNavi isn’t just playing with AI inside its own app—it’s opening up the underlying tech stack for everyone to use.
On May 13, AutoNavi, together with Alibaba’s Qwen consumer application team, open-sourced AGenUI, positioned as the industry’s first end-cloud integrated native A2UI framework covering iOS, Android, and HarmonyOS. In plain terms: from now on, when you build a client UI for an AI Agent, you don’t need to code it once in Swift for iOS, again in Kotlin for Android, and yet again in ArkTS for HarmonyOS—write it once and it runs natively on all three.
The timing is intriguing. From last year to this year, the Agent field in China has broadly crossed over from the “proof of concept” stage to “actually serving users.” Anyone who’s built one knows the model side is actually the easy part—the pain lies in the frontend. Agent output is dynamic, its structure is unpredictable, it needs to support streaming rendering and access local capabilities, and each extra platform multiplies the pain. AGenUI aims to solve this part of the engineering debt.
What is A2UI, and why do we need a new framework?
Let’s clarify the term first. A2UI stands for Agent-to-UI—it’s a protocol and rendering mechanism that enables an Agent to send its intent, data, and interaction logic to a client, which dynamically generates the native interface. It’s fundamentally different from cross-platform frameworks like React Native or Flutter. Those are “developer-written UIs running cross-platform.” This is “model-determined UIs rendered in real time.”
Why is this layer needed? Because traditional app UIs are hardcoded: where each button goes, what a card looks like, how many fields a form has—all fixed until the next version. But an Agent’s output, by nature, is unpredictable. A user might ask, “Plan me a three-day trip to Hangzhou,” and get back a combination of route cards, hotel lists, weather info, and budget summaries. Ask, “Which nearby Sichuan restaurant has the highest ratings?”—and you get a map, a ranked list of restaurants, and coupons. If each response type requires a product manager to plan and developers to hardcode the UI, the flexibility of AI vanishes behind frontend bottlenecks.
The industry has tried two main paths so far. One uses WebView + H5 rendering: flexible, but sluggish—animations lag, and it feels much worse than a true native app. The other uses a domain-specific language (DSL) plus custom rendering engines: faster, but each platform needs its own version, and HarmonyOS only adds to the maintenance burden.
AGenUI takes a third route: a unified A2UI protocol plus native renderers on all three platforms. The cloud-side Agent outputs a standardized UI description, and SDKs on each platform translate it into native components (SwiftUI for iOS, Jetpack Compose for Android, ArkUI for HarmonyOS). This keeps native performance while reducing cross-platform cost to a single UI description.
Why AutoNavi is the right team for this framework
To understand this, we need to go back a bit. Last August, AutoNavi launched “AutoNavi Maps 2025,” transforming the entire app into an AI-native application. Behind it was a master-subagent architecture co-developed with Qwen: the main Agent, “Teacher Gao,” parses user intent, then delegates to sub-agents for navigation, lifestyle, or cross-scenario needs, which in turn execute tool calls.
Running this architecture at the scale of a billion users meant the UI layer couldn’t rely on WebView hacks. AutoNavi engineers were effectively pushed by real production needs to pioneer the A2UI path—supporting iOS, Android, and HarmonyOS simultaneously, handling dozens of Agent output types and complex layered map visuals. Only after getting this running internally did they extract and open-source it, a far more robust process than a lab-only prototype.
That’s what differentiates AGenUI from “PPT frameworks”: it’s been battle-tested in a massive super app before being open-sourced.
How “three-end native” is achieved
According to public materials, AGenUI’s architecture consists of several parts:
- Protocol layer: Defines the A2UI description format—components, layouts, events, data binding.
- Three SDKs: iOS, Android, and HarmonyOS each implement translation of this protocol into native UI trees.
- End-cloud channel: Supports streaming updates, allowing the Agent to generate and render UI in parallel.
- Capability extensions: Lets developers register custom components, such as AutoNavi’s own map or route cards.
The streaming part is crucial. Users are now accustomed to ChatGPT’s token-by-token generation experience. If an Agent UI still shows a loading spinner for three seconds and then dumps a full page at once, it feels clumsy. AGenUI supports UI streaming, allowing paragraphs, cards, or sections to appear gradually in sync with model reasoning speed.
The HarmonyOS side deserves special mention. HarmonyOS NEXT adoption has been faster than expected this year; major apps almost have to release native Harmony versions. But ArkUI differs significantly from iOS and Android, and many teams either give up or use compatibility layers. By elevating HarmonyOS to a first-class citizen, AGenUI effectively helps smaller teams overcome one of the biggest technical barriers.
What it means for developers
Realistically, AGenUI isn’t for everyone. Its target audience is clear: teams building AI-Agent-style products that require native experiences across three platforms. If you’re web-only or single-platform, its value is limited.
However, for teams building AI assistants, AI search, or AI utility apps—especially those looking to upgrade from H5 wrappers to native apps—the potential workload savings are obvious. Roughly speaking, implementing an Agent UI rendering system for three platforms might take two engineers per platform for three months—a minimum of 18 person-months—before maintenance or component adaptation.
A few key questions to watch:
- Openness of the protocol: If the A2UI protocol only serves AutoNavi’s internal needs, it has limited external value; if it becomes a generic Agent UI standard, its potential grows exponentially. Community feedback will determine this.
- Cost of custom components: Every product has unique UI molds. How smoothly custom components can be registered determines whether the framework is “usable” or truly “developer-friendly.”
- Coordination with model outputs: Ensuring that the Agent stably produces A2UI-compliant descriptions might involve prompt engineering or function-calling strategies—will the framework offer guidance here?
China’s Agent engineering enters the practical phase
Viewed more broadly, AGenUI marks a clear signal in China’s Agent landscape this year: the conversation has shifted from “Can we build Agents?” to “How can we build them efficiently and elegantly?”
Most existing open-source Agent projects focus on orchestration layers (like LangChain, AutoGen) or execution layers (tool use, code interpreters). The UI layer has always been missing—for understandable reasons. Building a UI framework is grueling: you must tackle platform differences, rendering, and compatibility. Research institutions and model vendors shy away from it. AutoNavi’s business-driven approach fills that void.
The A2UI direction will likely heat up further. Google’s Project Mariner and Anthropic’s Computer Use are exploring the “Agent operates UI” path, while A2UI represents the “Agent generates UI” path. Both lead to the same destination: UIs that are no longer product-manager-defined artifacts, but real-time model decisions.
For developers, the practical move right now is to clone AGenUI, run a demo, and study the protocol design, rendering experience, and fit with your Agent pipeline. The beauty of open source is that there’s no need to guess from slides—just read the code. You’ll know within a night whether it works.
As a side note, if you’re still struggling with model integrations for your Agent app, aggregation platforms like OpenAI Hub can simplify things: one key connects you to GPT, Claude, Gemini, DeepSeek, Qwen, and other major models, all using an OpenAI-compatible API. Once the frontend framework is solved, don’t let the backend become your next bottleneck.
References
- How AutoNavi Built the World’s First Map AI – Zhihu Column: background on AutoNavi’s AI transformation and the context behind AGenUI.
