Boundaries of Design.

In 1968, Douglas Engelbart stood onstage in San Francisco and demonstrated a strange vision of interactive computing. Windows. Hypertext. Collaborative editing. Video conferencing. A mouse. At the time, most computing still happened through punch cards, terminals, and operators. The machine lived somewhere else.

A decade later, researchers at Xerox PARC turned many of those ideas into systems ordinary people could actually use. Before systems like the Alto, most people experienced computing indirectly. Programs were submitted in batches. Commands were typed into terminals. The machine remained opaque.

PARC changed that. Bitmap displays, windows, icons, text you could select directly on screen with a mouse rather than type through a terminal. These were not cosmetic additions to computing. They changed where computation happened for the person using it. The interface was not a layer placed on top of the system after the important work was finished. It was how the system became understandable in the first place.

Xerox management famously failed to recognise the significance of what PARC had built. Others did not. After visiting PARC in 1979, Steve Jobs said it was obvious within ten minutes that every computer would eventually work this way. What PARC introduced shaped the next fifty years of software.

The interface did more than organise information on a screen. It compressed intent, behaviour, trust, and control into one visible surface where a person could inspect the system as it worked. Software companies organised themselves around that assumption. Beneath the screen sat the permissions systems, the routing logic, the billing rules, the retries, the ranking models. Design often shaped how judgement appeared rather than how judgement worked.

The gap between how judgement appeared and how it worked mattered less at companies like Apple, where hardware, software, interaction, and business model moved together. Most SaaS companies were different. They sold operational tooling. The customer did the work. The software organised the process. A claims adjuster clicked through the workflow. An operations team corrected mistakes manually. Somebody stayed late fixing exports before month-end close. The human being was still part of the runtime, and as long as people remained the operators of software, the interface stayed at the centre. Design got mistaken for the screen.

Some companies hinted at where software was heading long before agents arrived. A handful of infrastructure businesses, including Twilio, AWS, and Stripe, were valued less for what they showed on a screen than for how they behaved underneath it. Stripe is the clearest case. It did not become important because its dashboard looked better than everyone else's. Developers trusted it because the system behaved predictably under pressure. Payments failed cleanly instead of silently, APIs behaved consistently, retry logic handled transient failures, and documentation explained edge cases before they became support tickets at two in the morning. The product was increasingly below the interface.

Software has started crossing a line from helping people do work to doing portions of the work itself. Once software acts on behalf of people rather than merely guiding them step-by-step, the centre of gravity shifts. Trust no longer sits primarily in the screen. It sits in whether the system behaves correctly when nobody is watching closely.

Agents speed up that shift because they break the interface apart again. They do not experience software the way people do. They move through APIs, tools, memory, permissions, retrieval systems, and instructions. Increasingly, the user describes an outcome and the system decides how to pursue it. Computation becomes mediated again. This is not the old form of punch cards and operators, but a newer and stranger form, with systems acting semi-autonomously on behalf of people who can no longer fully inspect every intermediate step. The machine, for the second time, lives somewhere else.

For years, the interface compressed judgement into something visible. A person could inspect the workflow, pause, verify, intervene. Now that judgement is spreading back out across the system, into ranking models, confidence thresholds, escalation rules, retrieval pipelines, exception handling, audit logs, and the quiet moment when somebody decides whether they trust what the machine just did. A SaaS workflow contains its own friction. The person operating the machine is, in being there, also auditing it. Mistakes surface at the pace of someone clicking through the work. An autonomous system removes that friction. The same error can repeat ten thousand times before anyone realises the confidence threshold was calibrated incorrectly.

The cost of those mistakes lands somewhere. For decades it landed mostly on the customer, because the customer was still operating the machine. If the workflow was inefficient or error-prone, the burden sat with whoever was clicking through it. The late nights and the manual corrections were theirs. As software starts performing work directly, the burden moves with it. A silent failure stops being a usability issue. It becomes a liability.

Questions that once sounded philosophical become operational. Can a person tell when the system is uncertain? Does the software fail loudly or quietly? When it succeeds, do people trust it enough to act? These are not really questions about screens. They shape whether the system is economically viable at all.

Which brings design back to an older definition of the word. To design is to plan and make something for a particular purpose. Engelbart and the researchers at PARC were never really designing interfaces. They were designing what a person could do with a computer.

Now the boundaries are moving again.