When a URL started calling a program
A page on the early web could usually be thought of as a file the server returned. That model fits documents extremely well. An address roughly corresponds to a resource, the resource is read, the browser presents it. But the moment a site has to show different results per request, collect a form, query stock levels, handle a login or generate something personalised, files stop being enough.
This is exactly what CGI was for. It gave web servers a common interface so a request could invoke a program and send the program's response back to the browser. Looking back, the cgi-bin and long query strings that filled early CGI URLs look clumsy, but they record a real expansion: a URL no longer had to point at a page that already existed. It could trigger a computation.
That change should not be written up as the moment URLs broke free of the filesystem. Early CGI usually still started from an executable file on the server, and paths, deployment and permissions stayed tightly related. The more accurate statement is that the web could now combine resources, input and actions. A page was no longer only something stored in advance. It could also be a result produced from context.
From a visitor's point of view the shift was easy to feel. Someone opens a directory page, fills in a search box or a registration form, and clicks submit. The browser carries the input into the request, and the address bar often shows cgi-bin and a long query string. The server invokes a CGI program, the program queries data or processes the form, and a new HTML page comes back. The interface still reloaded a page at a time, but for the first time a page could change based on what I just typed. For developers of that period, a site now contained page files, executables, permissions and input handling all at once, rather than a directory you could copy.
Dynamic pages are not the enemy of static ones
Server-side scripting and templating that followed, PHP and Classic ASP among them, put HTML, data access and program logic closer together. They removed the pain of stitching responses by hand, and let one page reuse a layout, read data and present different content by condition. For a news site, a forum, a shop or an admin system, this was not surplus complexity. It was the precondition for the web being useful.
It is also why "every page should go back to Markdown" was never a serious answer. Content is sometimes an article, sometimes a query result, sometimes form state, sometimes a resource you only see after a permission check. The real challenge is not choosing between files and programs. It is not having to reinvent the boundary between them in every project.
Traditional web frameworks usually design this starting from the application. A developer sets up routes, controllers, templates, database models and identity middleware, then decides which requests return HTML and which return JSON. That gives applications plenty of freedom, and it also pushes a lot of shared responsibility onto every team. A publishing page and a heavily customised business flow end up starting from the same project skeleton.
ARC cuts it differently without denying the programmable web. AFS can hold readable resources and executable actions alike, and providers can mount external systems, data or specialised logic onto unified paths. Computation stops being an exception to the file model and becomes one capability inside the same addressable system. When a page needs to read data, invoke a controlled operation or show some state, it does not have to assume those things live inside the private internals of a traditional web framework.
Putting actions into the model is not the same as hiding complexity
There is an easy misreading here. If actions and providers can be represented in AFS, does that mean any complex application can be replaced by a few lines of declarative configuration? No. Unusual business rules, third-party services, performance-sensitive computation and complex data structures still need clear implementation and runtime boundaries. Providers exist precisely because of that. They are where system capability is extended, not where code is pretended away.
What actually changes is the location of the repeated work. A publishing page can reuse content, site declarations, identity context and publish-time checks. A specialised application can write a provider or application logic for the specialised part alone, instead of starting again from pages, authentication and publishing. For agents this difference matters more than usual: reading, writing, searching and executing all go through consistent system interfaces, which removes the break between "first understand this product's private API" and "then understand its deployment scripts."
None of this makes actions inherently safe. An action is still bound by permissions, caller identity, input validation and capability limits. ARC's value is not in routing around those constraints. It is in expressing them as a shared responsibility of the system rather than a guard clause each page adds on its own.
From programs generating pages to a system generating a publishing surface
That is where the Web Device sits. It is not a general-purpose CGI replacement, and it does not make interactivity in the browser disappear. It targets a different, stable need: when content, structure and site rules already have understandable declarations, the system can assemble them into HTML and run previewing, checking and publishing along the same path.
An interface that must respond continuously to input should still have its session maintained by the UI Device or another application runtime, and a system that needs a dedicated backend should still use a dedicated provider. What the Web Device contributes is that turning managed facts into readable web pages stops being identical to standing up another application service. That is not shrinking the web. It is separating responsibilities that had already become different.
The next part looks at why that separation grew harder. Content management systems, databases, application servers and browser runtimes made the web far more capable, and they also made a small site look more and more like software that has to be operated.