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 with bitmap displays, windows, icons, and text people could select directly on screen with a mouse. These were not cosmetic additions to computing. They let people see and manipulate what the machine was doing. The interface was not a layer placed on top of the system after the important work was finished. It was how people came to understand the system in the first place.

Xerox did not bring the Alto to a mass market. Others recognised what PARC had built. After visiting PARC in 1979, Steve Jobs later recalled knowing 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 gave people one visible place to tell the system what they wanted, see how it responded, and decide whether to trust it. 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. Designers often shaped how those decisions appeared without being able to shape the machinery behind them.

For a long time, that boundary seemed natural to me. The screen was where people encountered the system and where designers could most directly shape it. Infrastructure mattered, but it belonged to another discipline. Nearmap was vertically integrated in a way few software companies are. We built the cameras, flew the planes, processed the imagery, and made the software that delivered it. Yet when we created the Roof Spotlight Index, the AI and API teams set the confidence threshold that determined which roof layers counted towards the final score, and design worked out how a customer could understand or challenge the result. They set the rule. We made its consequences legible.

Apple had the same kind of end-to-end control and made a different choice with it. It designed the whole product, from the metal to the business model, and treated the screen as one surface among many. Most SaaS companies sold operational tooling instead. The customer did the work and 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. As long as people operated the software, the interface stayed at the centre, and many companies came to treat the screen as the boundary of design.

Stripe showed where software was heading long before agents arrived, and from the opposite position. It controlled no end-to-end experience. It was one layer inside other people’s products. It did not become important because its dashboard looked better than everyone else’s. Developers trusted it because its API made errors explicit, supported safe retries, and documented edge cases before they became support tickets at two in the morning. Much of the product lived below the interface. The boundary was never set by how much of the stack a company owned. It was set by where each company decided design stopped.

Software has started crossing a line from helping people do work to doing portions of the work itself. When software starts doing the work, its behaviour becomes part of the design. The screen still matters, but it is no longer the boundary.

Agents take that shift further because they perform parts of the user’s work, moving through APIs, tools, memory, permissions, retrieval systems, and instructions. Increasingly, the user describes an outcome and the system decides how to pursue it. The person no longer sees each step. This is not the old world of punch cards and operators, but it presents a similar problem. Systems act semi-autonomously for people who cannot fully inspect what happens along the way. The machine, for the second time, lives somewhere else.

That loss of visibility changes what designers are responsible for. A person could inspect a conventional workflow, pause, verify, intervene. Now decisions happen across ranking models, retrieval pipelines, exception handling, audit logs, and the records through which people reconstruct what happened. They come together in the quiet moment when somebody decides whether to trust what the machine just did. A SaaS workflow contains its own friction. By operating the machine, a person is also auditing it. Mistakes surface at the pace of someone clicking through the work. An autonomous system removes that friction. The same mistake can repeat ten thousand times before anyone notices.

Somebody bears the cost of those mistakes. In operational SaaS, it was often the customer because the customer still operated the machine. If the workflow was inefficient or error-prone, whoever clicked through it absorbed the extra work. The late nights and the manual corrections were theirs. As software starts performing the work directly, the company behind it can no longer treat those failures as the customer’s operational burden. A silent failure stops being a usability issue. It becomes a liability.

That is where the division that held at the Roof Spotlight Index starts to fail. Product can define the outcome and the trade-off. Engineering can make the system reliable. Design can make it legible and workable for the person using it. But an agent binds those decisions together. A confidence threshold changes what a person is asked to trust. A permissions rule changes the product’s promise. An escalation path changes the cost of failure. None of them is only an implementation detail.

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 design decisions, even when they leave no mark on a screen. They determine whether the system is dependable enough to use.

This 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 designing interfaces, but the interface was not the limit of their work. They were designing what a person could do with a computer.

A system can behave reliably and still leave the person with little to do beyond describing an outcome and approving the result. As software absorbs more of the work, designers must decide what the machine should do and where people still need room to understand, judge, and contribute. That question is older than AI. It runs through the history of the universal machine.

I do not know where that boundary settles. A system that explains every step may be as difficult to use as one that explains nothing. But wherever a machine acts on someone’s behalf, someone has already made these decisions, whether or not they called them design.