You are here. See how this question connects to other ideas.
Select a node to open its page · Expand to read within the map
LEARN / AFS + AFS-UI
A task can appear as a card, a row or a tool’s target. Learn how people and agents can work with the same object as its presentation changes.
Start with AFSUnderstand what a task can name, access and operate.
New to AFS · resources and addresses5 questionsConnect what a person sees with the structure an agent can use.
After AFS · connect views and objects5 questionsFollow the architectural questions behind the keynote.
Architecture · agreements that should endure6 questionsUnderstand an interface tree, its protocol and how a website presents it.
Developers · distinguish protocol and website implementation9 questionsPut protocols, SDKs, hosts and design tools in their respective places.
After AUP · compare responsibilities9 questionsDistinguish addresses, capabilities, updates and failures in a shared working environment.
After AFS · resource behavior and reliability6 questionsA TALK THROUGH THE IDEAS
From an X Window memory to shared context, addresses and displays—and research questions that can test those choices.
The argument behind the presentation
30 slides · the story edition
30 slides · the story edition
Each explanation stands on its own. “Builds on” links show the background it uses.
Resources, paths and operations
AFS gives a task a named, inspectable view of the resources it can work with.
A path identifies a resource within a namespace, so operations can refer to it explicitly.
A provider implements resource operations; a mount places that provider in a namespace.
Naming a resource is useful only when consumers can understand what operations on it mean.
A Small World presents the resources relevant to one observer, rather than exposing the whole system.
An entry path and the resource’s original location are different things.
Location, supported operations and caller authority are separate questions.
Reading the same address and receiving changes are separate steps.
A shared address does not decide how stale edits are handled.
Finding relevant content differs from selecting records by explicit conditions.
Missing, unsupported, denied and conflicting operations need different responses.
Views over operational context
AFS-UI treats the interface as a projection over operational context that humans and agents can work with.
A visual control can correspond to named structure, state and actions, rather than only a region of pixels.
Separating context from projection lets multiple views refer to the same operational objects.
A display presents and accepts interaction; a session groups the operational state associated with an interaction context.
Inspection should expose the actual structure of the active view and its relationship to state.
Boundaries that survive change
Follow screens, windows, networks and paths to see what interfaces changed—and what endured.
Computation and the place where a person sees and controls it can be separated.
Compatible resource addresses and operations let parts cooperate without sharing every implementation detail.
Nodes, bindings, events and capabilities
Agentic UI Protocol describes interface structure and its connections to state and actions.
Read identities, types, properties and children through one task card.
Reading resources, writing input and updating properties are distinct connections.
Trace an interface event to an explicit operation target.
Capability declarations and degradation determine how a structure reaches its target.
Eighteen core types provide an entry into the interface vocabulary.
Sites, themes and implementation boundaries
Organizing content and interfaces into a website is another layer of work.
One describes interface contracts; the other organizes a Web site implementation.
Distinguish core primitives, Web-only types and theme components, then browse the default theme.
Eighteen types, one question at a time
view organizes child nodes and expresses their arrangement.
text expresses words, heading levels and supported formats.
media expresses media kind, source and alternative information.
input describes an input control; change represents value changes.
action expresses a triggerable action or navigation entry.
overlay expresses dialogs and other overlaid interfaces, with explicit open or closed state.
table uses column definitions and row data for comparable records.
time expresses dates, clocks, countdowns and related time information.
chart expresses data visualization; Web drawing has its own implementation.
map addresses geographic locations, map centers and markers.
calendar organizes events into month, week, day or agenda views.
chat is a core type, but needs a supporting session target.
rtc reserves a name for real-time communication; it is not yet a usable calling control.
explorer describes a resource-browser subsystem; the runtime must support its expansion and presentation.
editor supports code or text editing; saving depends on explicit connections.
canvas provides freeform drawing; the application connects saving and sharing.
surface provides an embedding boundary for resources or remote AUP.
afs-list presents AFS resource collections as lists, grids and other arrangements.
Protocols, SDKs and design workflows
Compare responsibilities, addresses, state and interaction contracts.
Render agent-provided interface descriptions through client-supported components.
Interactive answers, streamable components and the boundaries to examine alongside AFS-UI.
Bring interactive HTML interfaces from MCP tools into supporting hosts.
Separate the standard from implementation tooling and legacy compatibility.
Agent–application event exchange differs from interface description.
It provides implementation tools for generative interfaces in Flutter.
Compare its design workflow separately from runtime protocols.
Compare scope, resolution and available operations.