Google's new Jetpacker example shows a cloud agent sending interactive screens into an Android app instead of returning only chat text. Published on September 28, 2026, the booking-assistant walkthrough uses AG-UI for live events and A2UI for descriptions that Jetpack Compose renders as native components. The A2UI AndroidX libraries first reached 1.0.0-alpha01 on September 23; the later post demonstrates how to combine them. For developers, the useful change is a reusable way to display an agent's changing workflow without hard-coding a new screen for every step. It is an alpha sample, not proof that autonomous bookings are production-ready.
The server describes a screen; the app chooses what it can render
In the Android Developers walkthrough, a cloud-hosted Agent Development Kit (ADK) coordinator delegates flight, hotel and other itinerary tasks. AG-UI carries progress and interaction events between server and phone. A2UI carries declarative descriptions of controls such as option pickers and booking-status cards. The Compose renderer turns those messages into native UI from a catalog the app has registered. A server can change the order and content of supported components; it cannot create an arbitrary new native component on a phone that lacks it.
That distinction is the practical value of the A2UI catalog model. The app defines which components and properties are trusted, and the library parses and validates protocol messages rather than running arbitrary code from the agent. The blog's example uses an A2UI v0.9 schema, while the AndroidX packages have a 1.0.0-alpha01 release label: those version numbers describe different things. Google also notes that changing a custom component's properties requires coordinated catalog and Kotlin updates. Dynamic layout therefore reduces some client releases, but does not eliminate compatibility work.
This in-app pattern is separate from Android AppFunctions, which exposes app functions to system-level agents. Here, the Android app is the interface for its own cloud workflow. A team can use one pattern without claiming that every Android assistant or device supports the other.
The sample leaves production responsibilities with developers
The booking code illustrates confirmation before a reservation tool runs, but its sample flight search returns fixed times and its reservation function is a stub. It uses ADK's InMemoryRunner. ADK's session guidance says in-memory state is lost on process restart; a persistent session service is needed if a long-running booking must survive backend failure. Google's statement that a cloud workflow can continue when the mobile app closes should not be read as a guarantee that this sample survives a server restart.
Before using this architecture for purchases or other consequential actions, a team should define user authentication, permission checks for each tool, explicit confirmation, durable state, idempotent transactions and recovery after disconnects. These are engineering implications of the demonstrated design, not features established by the sample. Developers should also test malformed or older A2UI messages against the client catalog, because an agent's UI description crosses a trust boundary even when it is not executable code.
Where to start
The pattern fits a task that spans several steps and needs to show changing options inside a native Android screen, such as an itinerary that can resume after the app is backgrounded. A simple local form or one-step model response may not justify a cloud coordinator and two UI protocols. Start with the Jetpacker example to evaluate component rendering and confirmation flow, then choose a persistent session store and define the exact actions the agent may take before treating the prototype as a service. The September releases offer building blocks; reliability and authority still depend on the application around them.