In 1960, J.C.R. Licklider described spending hours preparing data he could interpret in seconds. His proposal, Man–Computer SymbiosisJ.C.R. Licklider · 1960 · §3.1Man–Computer SymbiosisDescribes preparation that took far longer than interpreting its result. This is a personal observation, not a current workforce benchmark.Orchestra editorial summary · reviewed 1 October 2026Open original ↗ (new tab), called for computers to take on more of that preparation.
We have changed the interface many times since. How much of that preparation have we removed?
UI becomes a barrier when operating an app demands effort the task itself does not require. Better interfaces remove that effort and give more people a way to finish.
The menu replaced the memory test
Command-driven systems asked people to remember what to type. Graphical interfaces offered visible objects and actions.
The team behind Xerox Star explained this choice in a 1983 paperBewley and colleagues · CHI 1983Human Factors Testing in the Design of Xerox StarDocuments familiar objects, recognition rather than recall, and user testing. It does not establish that graphical interfaces are best for every task.Orchestra editorial summary · reviewed 1 October 2026Open original ↗ (new tab). Familiar documents and folders would help office workers understand the system. Seeing and selecting could replace recalling a command. The team tested these ideas with users and revised designs that failed.
That was a change in what people had to learn. A visible control could make an action easier to find. The person still had to choose the sequence of actions.
We recognise that work today: locate the information, move it between apps, check the result. A clearer screen helps. An automatic connection between the apps can remove some of those steps altogether.
APIs and command-line tools provide ways to make those connections. They can automate repeated work, but someone still has to define the operations and handle failures.
These approaches coexist. A command line can still suit an expert. A visual comparison can help someone decide what they want.
Faster answers can mean more work
Agents offer another division of work. A person can request an outcome; an agent can select and carry out the steps.
Here is the risk: the effort may move into explaining the request, checking the answer and repairing mistakes. A faster first response can still leave you with more work.
Count the effort it takes to finish.
Five routes, one job. Choose one to follow it through the stages.
Explanation and sources
One job in five stages — want, find, do, check, fix — across five ways to direct an app. With direct controls the person carries every stage. With an API or CLI a program runs the steps the person defines. With WebMCP, voice over an app and the proposed voice through MCP, the app or agent finds and does the steps; checking happens in a view the person shares, and fixing stays with the person. Voice through MCP forks across two apps. Conceptual: who carries each stage, not how fast. The routes coexist.
- Direct controls
- The person chooses controls that trigger app actions, then checks the result.
- API / CLI
- A person or program specifies operations. An adapter calls the app; the result still needs inspection.
- WebMCP
- A compatible browser agent calls actions exposed by the page. The person can inspect the shared page state.
- Voice over an app
- Speech supplies a request. The app-specific voice integration acts and returns feedback.
- Voice through MCP
- Proposed path: speech reaches an assistant, which calls authorised service tools. The result remains reviewable.
That is the argument this series will test. Judge the whole task, including corrections. Ask who can complete it independently. An interface can be quick for one person and unusable for another.
The opportunity is larger than saving a few clicks. Someone may be able to do a task that previously required help. An expert may tackle a problem that used to take too much preparation.
Stop making agents hunt for buttons
An agent that has to find every button inherits some of the same navigation work.
The draft WebMCP proposalDraft Community Group Report · 30 September 2026WebMCPDefines structured actions exposed by web pages for compatible agents. Browser support needs separate verification. It does not establish that an app is accessible.Orchestra editorial summary · reviewed 1 October 2026Open original ↗ (new tab) lets a web page declare structured tools for compatible browser agents. This gives the agent an explicit way to act on the page. Our WebMCP explanationOrchestra · related articleStop making agents hunt for buttonsWebMCP lets a page expose actions to a browser agent. Radar shows how that can keep the person and agent working in the same place.Orchestra editorial summaryOpen original ↗ (new tab) explores that approach through uk.gov Radar.
Voice is another way to give an instruction. Our Commander work includes First OfficerOrchestra · related articleA spoken promise is not a completed actionA Cargo recovery request becomes an action, a checked result and a spoken report. What this bounded demonstration can teach app designers.Orchestra editorial summaryOpen original ↗ (new tab), a voice prototype for fleet operations. Its public Cargo sandbox supports a spoken recovery request, a checked result and a cockpit that follows the conversation. The public write is limited to that demo service.
Next, we want to dictate requests to an assistant using Model Context Protocol (MCP)Model Context Protocol · version 2026-07-28MCP architectureExplains hosts, clients, servers and tool discovery and invocation. Our spoken, cross-app release-note example is a proposed application of these mechanisms.Orchestra editorial summary · reviewed 1 October 2026Open original ↗ (new tab). It would call authorised tools across apps. First Officer currently uses its own voice integration; voice through MCP remains our next experiment.
WebMCP and MCP expose ways to act. They do not, by themselves, make an app accessible.
Progress means more people can finish
A voice-only interface excludes people who cannot use speech. A result shown only as an image can exclude someone using a screen reader. Moving the controls does not remove those barriers.
W3C's draft natural-language accessibility requirementsW3C · Group Draft Note · September 2022Natural Language Interface Accessibility User RequirementsDiscusses input and output choices, understanding and error recovery. This is work in progress, not an endorsed conformance standard.Orchestra editorial summary · reviewed 1 October 2026Open original ↗ (new tab) address alternative inputs and recovery from errors. The lesson is practical: people need access to the evidence and a way to correct the result. They should also be able to change input without losing their work.
That gives us a concrete comparison to make. Take one task through direct controls, then through an agent. Record the help needed and the mistakes. Include the effort of checking and correcting. Repeat with people who use the access methods being claimed.
In 1962, Douglas Engelbart set out an ambition to increase people's ability to solve difficult problemsDouglas Engelbart · 1962Augmenting Human IntellectSets out an ambition to increase human capacity for understanding and solving difficult problems. A research vision, not evidence for our present prototypes.Orchestra editorial summary · reviewed 1 October 2026Open original ↗ (new tab). That is a stronger goal than making each new interface look impressive.
The next advance should leave people able to do more. We should be able to show where it does.
Next, look at the accessibility barriers still preventing people from finishingOrchestra · related articleWeb accessibility: can people finish the job?An accessible button is useful. An accessible way to finish is the point. What the current evidence tells us about agents and access.Orchestra editorial summaryOpen original ↗ (new tab).