What Endures When Everything Evolves? — manuscript

19 main slides, budgeted for 28 minutes plus 2 minutes of buffer. Reserve the remaining 15 minutes of the 45-minute session for questions or an optional live inspection. This is a rehearsal budget including pauses and visual explanation, not a measured read-aloud duration. Slides 7–11 use captures of a real local AUP session; the prepared talk does not depend on a live model or network demonstration.

English slides · 中文胶片 · English speaker script · 中文讲述要点

01 · What Endures When Everything Evolves?

Look at this screen. It looks like a presentation. It is also a running AFS-UI application. The site around it and the material you will explore afterwards use the same system. I want to begin with that fact rather than save it as a reveal. For the next half hour, keep one question in mind: if an AI changes the interface tomorrow, what lets us continue the work we started today?

02 · The screen is one way into the system

Here is a small glimpse behind the screen. On the left is the content that supplies this talk. On the right are names exposed by the UI device. This is a selected structural excerpt, not a live inspector of every pixel. That distinction matters. AFS does not assign a filename to every coloured dot. It gives resources and operations a shared addressing model, and AFS-UI applies that idea to interfaces. You might reasonably ask: why bring something resembling a filesystem into a talk about generative UI? Hold that objection. We will return to a real interface node, read it, move its presentation, and update it through its address. You will see exactly what stays stable, and what this experiment does not prove.

03 · A new layout. The same unfinished work.

Imagine asking an assistant to turn a dense workspace into a simpler view. It succeeds. The screen is clearer. Now ask it to continue the task that was half finished before the redesign. How does it know which object is the same object? Where does the action go? What authority does it have? These questions already arise with hand-written interfaces. Generation makes them more frequent because the view can change during the work. OpenAI’s newly announced Intelligent UI makes this timely: interactive answers can be assembled while a response is generated. That is an important advance in presentation. My question is what contract survives across presentations. This is not a contest over who can make the prettiest card. It is a question about the working system beneath the card.

04 · We have separated these things before

I started on an Apple II, so this photograph is familiar to me. You do not need that memory to follow the argument. A person enters something, a program does work, and the machine returns a visible result. Later, a terminal made another separation obvious: the display could be here while computation happened elsewhere. The useful inheritance is not the green colour, the keyboard, or nostalgia for a difficult machine. It is that the visible surface and the place where work happens need not be the same thing. Today the surface might be a browser, a phone, or an agent’s tool interface. The architectural question is still recognisable.

05 · One application. Another display. Another window manager.

This is a historical X Window desktop. If you have never used one, notice the independent windows rather than the dated appearance. The X server provides display and input services; applications are its clients. A window manager is another client that supplies window-management policy. That arrangement made a very practical experience possible: computation could stay on one machine while its interface appeared on another display. I remember how surprising that felt. More interesting than the surprise is the boundary. The application did not have to own every decision about where and how its windows were arranged. Different window managers could make the same system feel different. We borrow that separation in AFS-UI. We do not claim compatibility with the X protocol, and an AFS-UI display is not simply an X server renamed.

06 · What endured was a boundary, not a look

Unix and Plan 9 offer a related lesson about names. A namespace lets programs refer to resources without reproducing each resource’s physical arrangement. Providers and services can be different behind that boundary. Names are not magic: their lifetime, operations and permissions still need contracts. The Web then taught us how valuable links can be across implementations. Modern interface frameworks made composition much easier. We do not need to replay that entire history today; the visual timeline is in the companion material. These examples give us a design question, not proof that AFS is correct. Which boundary would let a human-facing view change while an agent still has a meaningful way to find and act on the work? That is where we now leave history and enter the implementation.

07 · Let us follow one real node

Here is our deliberately small specimen. This is a browser capture of a real AUP session running in the local ARC instance, not an illustration of a planned product. The status says Preparing the keynote. We are going to ask three narrow questions. Can we read the node that produces that text? Can we rearrange its parent without losing that node? Can we update it and see the result arrive in this connected browser? The test data is synthetic. There is no durable task provider behind this label. Keeping the example small lets us inspect every step. Watch the status line closely; it will be our reference point through the next few slides. The capture is included so that the prepared talk works without waiting for a model or relying on a live network demonstration.

08 · Read the object behind the words

The browser shows words. The AFS interface returns a node with an identifier, a type and properties. The address ends with tree slash demo-status. The omitted prefix identifies this particular session; it is not a universal address valid on every machine. The read result tells us that this node is text and that its content is Preparing the keynote. An authorised program can inspect that structure directly, without inferring the status from pixels. Screenshot-based interaction remains useful for interfaces that do not expose such a contract. Here we have another route. Also notice what we have read: a UI node. We have not magically found a durable business task. If an application has a task provider, its task address is a separate resource and the view must explicitly bind to it. That distinction prevents the word context from becoming a vague name for everything.

09 · Move the presentation. Keep the target.

These are two captures of the same session. In the first the parent view uses a column layout. In the second we changed its layout property to row. The status moves on screen. Its node identifier and AFS address do not change, and a fresh read still returns the same content. This is a small result, but it is the exact kind of result I want an architecture to make easy to test. The operator does not have to search for a new coordinate because a layout changed. Do not generalise too far: deleting and recreating a subtree with different identifiers would not preserve this property. A generator needs to preserve identity deliberately when it intends to preserve the same object. The framework gives us an addressable representation; it does not excuse the application from managing identity.

10 · An operation with an explicit target

Now we invoke aup_patch on this session. The payload contains an update operation, the identifier demo-status, and the new content Ready for review. There is no simulated mouse click and no model deciding where to click. We call the existing action through the AFS interface. This is a UI-state mutation, not a business command to finish a real task. For that, an application would expose an operation on its task provider, and an interface event could call that target with explicit arguments. The useful separation is between the gesture and what the gesture means. A person may trigger an event in the view; an authorised agent may invoke the operation through a structured interface. They can participate in the same system without pretending that their input methods or their permissions are identical.

11 · The result reaches both the read and the view

Here is the outcome. Reading the same node returns Ready for review. The already connected browser also displays Ready for review without a page reload. Those are two separate checks. A successful action response alone would not establish that the display changed. A changed display alone would not establish durable business persistence. We checked the operation, read the node again, and observed the browser. The talk now has a concrete claim you can challenge: in this session, layout change preserved the target, and a structured update reached the connected display. We have not demonstrated restart persistence, cross-session synchronisation or a performance advantage over another framework. Keeping the evidence at this level makes the more ambitious architecture discussion credible.

12 · Three layers, three responsibilities

Now the names should have something concrete to attach to. AFS provides the addressing and operations over resources supplied by providers. It is the broader operational context. AUP, the Agentic UI Protocol, describes the interface as nodes, properties and events. AFS-UI is the architecture connecting that interface with the addressable context. Web Device is a concrete web-facing presentation environment; it is not a synonym for the protocol or a catalogue of protocol primitives. In the small experiment, the UI provider supplies the session and its tree. AUP describes the view and text nodes. The browser renders them. A real application adds business providers and explicit bindings or event targets. This is why we should not reduce AFS-UI to a JSON component catalogue. The catalogue matters, but the architectural proposal is that interfaces remain connected to the resources and operations of a working system.

13 · An address is not permission

There is a useful failure in our rehearsal history. A browser could display a synthetic session, but a mutation triggered through an experimental button was refused with Authentication required. The text did not change. That was not evidence that the operation had succeeded; it was evidence that seeing a surface and holding authority to mutate it are different things. A named path makes an operation discoverable and inspectable. It does not grant permission to execute it. Likewise, a human and an agent being first-class participants does not imply they share credentials or unlimited access. In a serious system, the actor, target, arguments and result have to remain attributable. This is also where a visually convincing generative demo can mislead us: a button appearing is not proof that the underlying command is authorised, or even implemented. The boundary belongs in the main talk because it is part of the design, not an apology at the end.

14 · Why not just a web page and an API?

A fair question is whether a web page and an API can already achieve this. Yes. An application with good resource identifiers, explicit operations and well-designed bindings can preserve these properties. We do not own the idea of stable identity. The issue is how often each surface and integration has to invent and rediscover its own conventions. AFS proposes a uniform addressing and operation model across providers, and AFS-UI makes interface structure participate in that model. That can reduce special-purpose glue when multiple agents, views and services need to work together. It also adds a contract that must be maintained. For a small, fixed page, the benefit may not justify adopting another abstraction. The interesting case is a system whose views and participants change independently. That is the claim we should evaluate, rather than saying that familiar web tools are incapable.

15 · Which boundary are we stabilising?

These approaches meet different needs. Intelligent UI brings native interactive responses into ChatGPT. A2UI focuses on declarative interface exchange. MCP Apps brings tool interfaces into supporting hosts. Our emphasis here is addressable operational context and the projections connected to it. These are entry points, not mutually exclusive boxes, and this slide is not a feature ranking. The newly announced OpenAI experience is particularly relevant because it shows that generating a useful interaction is becoming a normal expectation. That strengthens the question of what persists after the answer is shown. We should compare documented contracts, not speculate about competitors’ internals. The Learning material carries the fuller comparison and sources, so this talk can stay focused on the architectural boundary we have actually examined.

16 · The generator needs room to change

Return to the original redesign request. We want the generator to have freedom to improve presentation. We do not want it to silently change which task an action refers to or what that action does. Our experiment changed layout while preserving a node. At application scale the same intention requires explicit resource identity, binding rules and operation contracts. It does not mean freezing every address forever. Resources may move or disappear; operations may gain new versions. The system has to say what happens then, rather than leaving the agent to infer continuity from a similar-looking screen. The enduring foundation is a maintained agreement that lets other parts evolve. It is work, and it has a cost. That is the software engineering content behind the philosophical title.

17 · Test continuity, not just a beautiful first frame

These are experiments I would like us to discuss as a research community. The first is what our small session demonstrates. The second needs an actual provider substitution and a conformance argument; it is not established by the screenshots. The third needs tests under the relevant actor’s authority, including negative cases. We could measure successful completion after presentation changes, recovery from stale addresses, integration effort and failure visibility. We would also need a strong conventional web-and-API baseline. There is no benchmark victory hidden in this talk. There is an implementation, an architectural proposition, and a way to make its claims falsifiable. If the abstraction merely moves complexity elsewhere, these tests should help expose that too.

18 · Look behind this screen again

At the start, the filesystem-like structure may have looked like unnecessary machinery. We can now read it differently. It is a way of giving software an explicit reference to parts of the environment in which work happens. The human gets a visual, interactive projection. An agent can use structure and operations where those are exposed, without having to reconstruct everything from pixels. The same site also offers articles, the knowledge map and the visual history. Those are real applications of the presentation environment. They do not prove every possible multi-display scenario, and they do not need to. The point is that the architecture is already being exercised by the material you are looking at. The talk is one view into that larger system, not a promise that a system might someday exist.

19 · When the interface changes again,

What endures is not necessarily the interface we can see. It may be the address that lets us find an object again, the operation whose meaning we can rely on, or the separation that lets a new display join an existing system. AFS-UI is our concrete exploration of those foundations for human and agent participation. We have looked at one small part closely enough to see it work and to see its limits. I will stop here so that we have fifteen minutes for questions. We can inspect the operation in more detail, discuss providers and permissions, or explore the running site. The longer history and protocol material are available afterwards; you do not need to absorb all of them from the stage.

Sources and image credits

03 · Source 1

04 · Source 1 · Source 2 · Source 3

05 · Source 1

06 · Source 1

15 · Source 1 · Source 2 · Source 3

Apple II photo and its containing plate: CC BY-SA 2.0 FR. DEC VT100 photo: CC BY 2.0. TWM screenshot: public domain. Historical photographs are embedded unmodified.