What Endures When Everything Evolves?

AFS-UI and the Search for Stable Foundations in Generative UI

Robert Mao · ASE 2026 / HARNESS4GenUI

This is an AFS-UI application.

Built with an AI agent.

The slides. The website. The material afterwards.

Who am I?

Robert Mao

ArcBlock

I have been building through these changes.

The surprise was this: my program could run here, and its interface could appear on your display. “Put your program on my screen.” Today remote interaction is familiar. Back then it made the boundary feel negotiable. In X, the server provides display and input services; applications are clients. A window manager is another client. Computation, presentation and window policy need not be one indivisible thing. AFS-UI borrows that architectural idea, not the X protocol. Here is the Motif Window Manager (MWM), running on X. This reference screenshot was captured on Debian in 2014; it illustrates the window-manager design, not my original Sun workstation. Unix had different window managers with different ways of organizing your work. The applications did not all have to be rewritten just because the window policy changed. That separation stayed with me.

[Screenshot: Huihermit / Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Debian_Motif_MWM_Default.png) · [CC0](https://creativecommons.org/publicdomain/zero/1.0/)

I typed in China. The answer crossed an ocean.

The browser brought that world onto the screen

Input and output were already in the picture

Why AFS, when we already have tools?

Tools invoke operations. Skills explain procedures.

AFS gives the working context an address.

Everything is context.

Find what matters. Bring in what you need.

What about the interface?

Today’s approaches, different emphases

Approach	Main emphasis
OpenAI Intelligent UI	Interactive answers for people
A2UI	Declarative UI for client rendering
MCP Apps / MCP-UI	Interactive tool interfaces in hosts
AFS-UI	UI in an addressable operational context

There is important work happening around us. OpenAI’s Intelligent UI makes interactive answers part of the conversation. A2UI gives agents a declarative way to describe interfaces for clients to render. MCP Apps and MCP-UI connect interactive tool interfaces with host applications. These are distinct projects and contracts; this slide only identifies their main emphasis.

One useful question is: how can an agent explain something or offer an action through an interactive interface? We care about that too. AFS-UI can present generated structure. Our starting point also asks a second question: once an interface exists, how does the agent find its objects, inspect their state, and perform supported operations?

These questions overlap. Other approaches also have structured messages, state, and actions. Nor is structured access new: the DOM, accessibility trees, and APIs already matter. The particular choice in AFS-UI is to put UI into the same addressable operational context as other resources, using the filesystem-shaped model we have just seen.

So I would not read this table as a ranking or a claim that every other agent only sees pixels. Read it as a map of design questions. As generation improves, the contract beneath the generated interface becomes worth examining more carefully.

Remember the opening: this presentation runs on AFS-UI. Here is what that means, using one small object from a real local AUP session.

On the left, a person sees the status “Preparing the keynote.” On the right, an agent reads the path of that same object, its type, and exactly the same content. S is shorthand for the session prefix. This is a UI object, not a filename attached to a screenshot.

Follow just one correspondence: this visible status is that addressable object. The person reads the rendered interface; the agent reads the structure. It does not have to recognize the text in an image and guess which object it belongs to. Vision can still be useful, but it is no longer the only way in.

We are not asking the agent to imitate a person looking at a screen. We are giving both access to the same UI object, through appropriate interfaces and permissions. This is a separate demonstration session, not a live inspection of the slide itself.

So how do we describe these objects and the interactions they support? That brings us to AUP.

These slides are the application.

A small display changes the presentation.