Editor's Note: This blog is adapted from a session by Ashita Prasad, Developer Advocate at AWS, at thegeekconf mini 2026. Ashita's session explores how AI agents are changing the way people interact with applications and what developers can do to design for both human users and agents. She walks through three approaches to agent-ready applications: Web MCP, MCP Apps, and agent-generated interfaces using the A2UI protocol.
UX Has Traditionally Been Human-Driven
For the past decade, application design has assumed one thing - that a person is operating the application. Every interaction model, API, and interface was designed around that assumption. The user scrolls, navigates, taps, reads, and makes decisions.
That also means developers have to think about the effort required to complete a task. If a user has to click through ten screens, they can get tired or lose track of where they are. Applications were built to respond to human actions.
That is changing.
One reason is the evolution of technology. There is a concept called the technology-human behavior loop that explains this shift. Humans create technology to solve problems, and then that technology changes how humans approach those problems. New behavior creates new problems, which leads to new technology.
The smartphone is a simple example.
It started as a way to make communication portable. It then changed how people maintain relationships, navigate unfamiliar cities, and book a cab. The technology changed the behavior, and that behavior created new requirements for technology.
That is a feedback loop, not a straight line.
ChatGPT and the rise of AI agents are another example. AI has started changing how people interact with software, and those changes are now affecting how developers need to build applications.
Watch the full talk, straight from thegeekconf mini 2026:
AI Is Changing the Way Users Interact With Applications
Think about planning a trip.
Traditionally, you would open several applications, learn how each one works, move between screens, collect information, and build an itinerary yourself. With an AI assistant, you can state the goal instead.
You might tell the assistant where you want to go and what you need. The agent can search for information, work through the options, and bring the result into the conversation. You are no longer navigating the application to find the answer. You are stating your intent and letting the agent work out the steps.
That creates a goal-oriented flow.
There is also a click-driven flow. If you ask an agent to schedule a meeting, it can present a calendar interface in the conversation. You can select a time from that interface, and the selection is sent back to the agent. The agent can also act on your behalf. It can book appointments and, where the required integrations and permissions exist, make payments. The application is moving closer to the conversation instead of asking the user to leave the conversation and find it. This changes what developers need to design for.
The application now has two audiences: humans and agents.
A human might spend time reading a page. An agent can process a large amount of text in a short time. A human may need several clicks to complete a task. An agent may call a tool directly. At the same time, agents can behave in ways that are harder to predict than human users. That creates a new design problem: how do you make an application understandable to an agent without making it harder for humans to use?
That is where agentic experience, or AX, comes in.
Accessibility Already Gives Agents a Way to Understand Your Application
Before thinking about new protocols, look at what your application already exposes. If you have implemented accessibility, your application may already be easier for agents to understand. Assistive technologies use information such as the accessibility tree and ARIA labels to understand an interface. Agentic browser tools can also use this information to understand and interact with interfaces.
A button labelled "Submit order" gives an agent more information than a button whose only identifier is a generic element name. These labels provide context about what an interface element does. They can serve as a useful contract for agents by providing context about what interface elements do. Accessibility is one way to make an application easier for agents to work with.
There are other approaches.
Three Fronts of Agentic Experience
Agentic experience is developing across three areas.
- The first is exposing the capabilities of your website to agents.
- The second is bringing your application into the user's AI client.
- The third is allowing an agent in your application to generate the interface a user needs.
These approaches involve Web MCP, MCP Apps, and A2UI.
Web MCP: Exposing Your Application to Agents
One approach is Web MCP.
Instead of asking an agent to figure out how to navigate a web application through a series of screens, Web MCP provides a way to expose web capabilities as structured tools with defined schemas and properties. The agent can then call those tools and use the capabilities exposed by the application.
This is similar to what accessibility does from another direction, it gives an agent more information about how to interact with your application.
MCP Apps: Bringing the Application Into the Chat
The second approach is to bring the application into the user's AI client.
Think about where the user spends their time. If the user is working on an AI client such as Claude Desktop or Goose, you can bring your application's capabilities into that interface instead of sending the user somewhere else. The user provides an intent. The agent identifies the application or capability that can fulfil that intent and brings the relevant interface into the conversation.
MCP Apps is an extension to the Model Context Protocol that enables interactive UI to be rendered in AI clients.
MCP Apps: A Sales Analytics Example
Consider a sales employee whose manager asks for a Q4 report covering revenue, profit, and order volume across three states.
She opens the company's agent.
That agent has access to three MCP servers.
- The Sales Data MCP Server provides sales aggregation tools such as regional sales and monthly orders.
- The Sales Analytics MCP Server provides analysis tools. It can compare monthly or quarterly KPIs and summarize the results.
- The Forecast MCP Server provides forecasting capabilities for revenue, demand, and other metrics.
The employee gives the agent one request: “Give me the revenue, profit, and order volume for the three states, along with the forecast.”
The agent can return the information, but there is a problem.
The result is a large block of text.
She needs to send the information to her manager, so she now has to find the relevant numbers and present them in a useful format. A better result would be an interactive interface with charts and dashboards. She could select the metrics, choose the states, look at the visualization, and use the resulting analysis without extracting information from a wall of text.
That is where MCP Apps come in.
How MCP Apps Render UI Within an AI Client
MCP Apps allows UI to be sent over MCP and rendered within an AI client. The interface can contain HTML, CSS, and JavaScript, and it can support multi-step workflows.
In the session, Ashita broke the MCP Apps flow into four parts: UI resources, tool logic, the host and AI client, and the view.
- The first is UI resources. These contain the HTML, CSS, and JavaScript needed for the interface.
- The second is tool logic. MCP servers expose tools, and UI resources can be linked to those tools through metadata.
- The third is the host and AI client, which provide the environment where the MCP App runs.
- The fourth is the view, where the UI is rendered.
The view runs within the sandboxed iframe.
Sandboxing provides a security boundary between the MCP app and the host environment. The app runs within the restrictions imposed by the sandbox, while communication with the host occurs through the mechanisms provided by the host.
The view and host can communicate through postMessage, with JSON-RPC used to structure the messages. The host can mediate this communication according to the mechanisms provided by the implementation.
MCP Apps support varies across AI clients, with more clients continuing to add support. In the session, Ashita demonstrated the flow using Goose.
A Sales Dashboard Within Goose
Goose is an open-source AI agent that supports MCP Apps. It can also connect to different LLM providers. For the demo, Ashita used Amazon Bedrock to access foundation models from multiple providers.
She first selected Get Sales Data.
Instead of receiving another block of text, Goose displayed an interface where the user could select the metrics, time period, and states.
After submitting the selection, the demo stored the information in session storage.
The next step was Visualize.
Another tool call produced another MCP App containing the visualization. The interface included charts, data, and tooltips.
The final step generated a PDF report.
The user could preview the PDF, ask the agent to make changes, and download the result.
The difference is simple: the user does not have to describe every interaction through text. The interface handles the interactions that are easier to express through UI.
A2UI: When the Agent Runs In Your Application
The third approach changes the setup again.
Instead of bringing your application into an AI client, you can add the agent to your application.
Imagine a React or Flutter application where the user states an intent and the agent determines which interface should appear.
The user does not have to navigate through several screens to reach it.
One way to build this is the A2UI protocol, or Agent-to-User Interface protocol.
A2UI is an open-source, declarative protocol for describing UI in JSON. It is framework agnostic, so renderers can turn the description into components for web, mobile, or desktop applications.
How A2UI Turns Agent Output Into UI
The flow starts with the user sending a message. The agent interprets the message and determines the user's intent. It then produces A2UI messages describing the interface. These messages are sent to the renderer as JSONL. The renderer translates the messages into native components for the framework being used and displays them to the user. The user can then interact with the interface.
For example, if the user clicks Submit, the interaction is sent back to the agent as a structured event. The agent can then decide what happens next. This matters because the interaction is represented as structured data rather than relying on the agent to interpret another block of free-form text. For Flutter applications, the GenUI SDK can provide the rendering capability. For React applications, the A2UI React library provides a React renderer that implements the A2UI protocol.
A2UI Components, Catalogs, and Validation
A2UI defines UI components using an adjacency-list structure.
Each component has four main fields:
- ID
- Type
- Children
- Properties
The type identifies the component, such as a card, text element, or button. Children define the relationships between components. Properties define the component's attributes and configuration. A2UI uses a flat structure instead of deeply nested UI definitions, which makes incremental updates possible. The protocol supports incremental updates, allowing components to be added, updated, or removed without redefining the entire UI.
A2UI also uses catalogs.
A catalog defines the components and schemas that an agent can use when generating a surface. This creates a boundary around the UI the agent can generate. There is a basic catalog, and applications can also define custom catalogs. A custom catalog allows an application to use its own components and design system. The client advertises the catalogs it supports, and the agent can select a matching catalog. If there is no compatible catalog, the application can fall back rather than attempting to render unsupported components. The A2UI flow also includes validation on both the agent side and the client side before the UI is rendered.
Surfaces Define Where the UI Appears
Components are only one part of the interface. A2UI also has the concept of a surface, which represents a logical UI area where A2UI components are rendered.
This changes how developers can handle new workflows. In a traditional application, a new workflow can require changes to the application, followed by a new deployment. With A2UI, a surface can be defined dynamically using the components and properties supported by the application.
In the sales analytics example, the agent can produce a revenue dashboard containing charts, information bars, and text. The surface brings those components together into one interface.
Transport and Actions
A2UI is transport agnostic.
It does not require one specific transport mechanism. Any transport that can carry the required JSON messages can be used.
The session also distinguishes between local actions and structured events.
- Local actions are handled within the application without informing the agent. Opening a link is one example.
- Structured events are sent back to the agent.
For example, clicking a Submit button can trigger a structured event that is sent back to the agent.
Flutter, GenUI, and A2UI React
The Flutter GenUI SDK provides more of these out-of-the-box capabilities. This includes capabilities for building the transport layer, creating surfaces, handling prompts, and parsing A2UI JSON. In the session, Ashita noted that an A2UI React implementation may require developers to build more of these supporting pieces themselves.
In the demo, the application displayed the A2UI JSON alongside the rendered interface. The first surface allowed the user to select a region and request a visualization. The agent then generated another surface for the visualization.
When Ashita asked the agent to add Karnataka to the data, the surface did not need to change. The agent changed the data while keeping the same UI structure. A third request produced a table containing the data. The UI was generated based on the agent's output while the renderer controlled how those components appeared.
Three Ways to Build for Agentic Experience
The session started with a change in how people use applications and ended with three ways developers can respond to that change.
- Web MCP enables applications to expose capabilities as structured tools that agents can use.
- MCP Apps lets applications bring interactive UI into AI clients.
- A2UI enables generative UI within applications based on user intent.
The shift from UX to AX does not mean removing humans from the experience. Humans still provide the intent, make decisions, and approve actions that require their involvement. The difference is that the interface no longer has to be the only path between a user and the outcome they want.
For developers, that means designing applications that humans can use, agents can understand, and agents can interact with through defined capabilities and structured interfaces. The next layer of application design is about building screens for people and experiences that can work with agents.
