Why the web is a Device in ARC, not just an application

The previous parts described two sides of one thing. The web began by making publishing direct, then had to learn to execute programs, manage state and carry complex interaction. The problem was never that some step of that evolution was wrong. It is that those capabilities later got bundled into one default premise: to publish a piece of content, first operate an application.

ARC's answer to that premise is to treat the web as a Device. Device here does not compare a website to a keyboard, a screen or a piece of physical hardware, and it does not claim all devices run the same way. It means an output surface the runtime recognises directly: resources, declarations and data that already exist in AFS can become, through a device the system understands, a surface some particular audience can read or operate. For the Web Device, that surface is the publishable, document-shaped web.

Comparing it against a familiar working scene makes it easier to see. A team building a content site usually moves between a code repository, a CMS, a build service, a cloud deployment console, an identity service and a comment plugin. In ARC's model, the site's content, page declarations and data sources land in one set of AFS path semantics first, and the Web Device composes the part suited to public reading into pages. What the reader sees is still an ordinary web page, not a file browser. The change happens between the author and the system: publishing no longer has to begin by assembling a separate web application.

The value of the name is the boundary. A website is no longer assumed first to be an application project inside some framework. It can first be understood as a set of facts waiting to be published. It can of course still connect to applications, invoke actions and read dynamic data, but organising those things into a readable website becomes a responsibility of the runtime.

Two paths to the browser, not one path in different wrapping

The confusing part of ARC is that the browser can carry two completely different jobs.

The first is the Web Device. It faces documents and publishing: what global declarations the site has, which pages and content should be discovered, how HTML gets composed, how previewing, checking and publishing happen. It suits articles, documentation, product introductions, content collections, and any page where a reader first needs a stable URL and readable output. The Web Device does not hold a long-lived browser session. What it produces is publishable output.

The second is the UI Device. It faces interaction still in progress: validating right after a user types, reflowing right after a drag, updating continuously during multi-party collaboration, or an application that has to keep a session and an event channel. It uses AUP, the Agentic UI Protocol, to describe interface and interaction semantics, and a renderer such as a browser presents that within a session. It should not be dressed up as a static page, just as an article should not be forced to become a resident application.

The two share much of AFS's and AUP's semantics while carrying different lifecycles. The Web Device does not presume a continuing session and prioritises stable, checkable, publish-oriented pages. The UI Device uses a continuing session to carry live state and operations. Calling both of them Devices is not meant to blur the difference. It is what lets the system recognise the difference first and then choose the right output path.

This is also why "can the Web Device build every website" is not a useful question. Live collaboration, heavy browser capability, specialised business services and high-frequency state synchronisation still need the UI Device, a provider or another runtime. Conversely, plenty of content pages should not inherit the full weight of an application just because those needs exist somewhere in the system.

What should move down is not a framework, it is the recurring responsibility

A modern web project contains a class of work that shows up nearly every time: identify the current caller, decide what they may reach, read or modify controlled resources, record who created what, and present the result to a reader. Different frameworks give these different names, and each project still ends up wiring in an identity library, permission middleware, form handling and a comment plugin all over again.

ARC's judgement is not that these problems no longer need design. It is that some of them should not be reinvented at the page layer each time. An application using the runtime can obtain verified caller identity and authorization context, and generic operations like comments and reactions can have authorship derived on the server and handled under configured ownership and permission rules. For publishing pages, that means a pre-rendered article can attach to a controlled response surface without assembling a separate system for the sake of one comment section.

That sentence needs stating precisely. Providing identity, roles and operation boundaries does not automatically generate a complete registration flow, a team admin area, a subscription system or a community governance product. Full discussion boards, notification networks, complex feeds and business-specific approvals remain higher-level application choices. ARC has not flattened those differences. What it tries to reduce is the shared groundwork that never should have been rebuilt per site.

The division of labour compresses into a fairly small contract:

This is not the vague promise of writing less code. It pushes code and complexity back to where they are actually different. A site does not have to build its own authentication, build and comment pipelines before publishing an article, and a complex product does not have to pretend it is only a site declaration.

AFS is a shared surface of fact, not a replica of the old directory

What makes this cut workable is not dressing up the traditional folder. AFS is a filesystem abstraction: resources, content, configuration, indexes, data providers and executable actions can be organised inside one addressable space. What it gives the Web Device is a discoverable surface of fact, rather than a requirement that all data become HTML or Markdown on a disk.

A content collection can be expressed by directories and metadata. When querying or indexing is needed, a provider can supply it. When an operation has to run, it goes through an explicit action. The Web Device is responsible for the publishing presentation drawn from that. The value is not a claim that filesystems beat databases. It is that an author does not have to maintain a second copy, detached from its source, just to make the same fact appear on a web page.

For AI agents this shared surface matters too. An agent does not have to guess which private CMS a site hides its content in, which scripts its actions are scattered across, and then learn a separate set of deployment steps. It can work along paths, permissions and declarations the system already exposes. That is not a promise that agents can already operate any interface. AUP's goal is to make interface semantics and significant operations more describable, and actual capability still depends on the implementing renderer, the session and the authorization boundary.

The web once turned publishing from a specialist operations task into an everyday act. What ARC wants to restore is not the technical limits of that era but its reasonable default: publishing is something the computing environment should already do well, and the application is the next layer down, entered when unique logic is actually needed. The next part asks what happens when many sites share this common layer of semantics: how they can talk to each other more easily, and how to keep that convenience from becoming another wall.

Further reading