A Letter to Everyone Still Designing Software for the Browser
Recently, I noticed that the way I use Vercel and GitHub had changed.
I used to open a browser, enter a dashboard, find the right project, inspect its state, and perform an action. Now I increasingly give the objective directly to Codex: find out why the deployment failed, inspect the latest changes, commit the code, open a pull request.
The work gets done, and I may never visit the Vercel or GitHub website.
That made me wonder whether we have been placing agents on the wrong side of the product boundary.
Most software companies are asking the same question: How do we put AI inside our product?
The more consequential question may be: If people increasingly use our product through an agent, what should we expose to it?
Those questions sound similar. They point in opposite directions. The first treats the agent as a feature inside the product. The second treats it as a new kind of client.
I am increasingly convinced that the second change will matter more.
A client does more than display a page
For decades, we have grown accustomed to three main kinds of software client: the browser, the mobile app, and the desktop app.
They look different, but they ask the user to do the same thing: learn the language of the software.
You need to know which page contains the feature, what each control means, which field comes first, and which confirmation comes last. You begin with a goal in your head, then manually translate it into a sequence the software can understand.
An agent does not merely change the input box. It changes where the translation happens.
Before, people translated intent into operations.
Now, agents are beginning to translate intent into operations.
When someone says, “Find out why yesterday’s deployment failed,” the agent can decide which deployment to inspect, which logs to read, which commit to compare, and how to present the conclusion. The user does not need to know which pieces of evidence live in which products.
That is what a client has always done: receive human intent, invoke system capabilities, and return a result. The difference is that traditional clients made people adapt to the structure of machines. Agents are beginning to make machines adapt to the goals of people.
Why the IDE changed first
It is not an accident that general-purpose agents grew out of coding agents.
The world of code was already prepared for machines.
Code is text. Files are searchable. Important operations have command-line interfaces. Changes can be reviewed as diffs. Results can be tested. Failures can be rolled back. Git records what changed, tests tell us whether it worked, and the terminal makes complex actions reproducible.
An agent does not need to imitate the mouse movements of a programmer. It can enter the structural layer of software development directly.
That has started to change the job of the IDE.
Without an agent, the IDE handles input, navigation, execution, debugging, and editing. With an agent, more of the writing happens elsewhere. The IDE remains important, but people increasingly use it to inspect files, understand changes, review diffs, and confirm results.
Writing did not disappear. It moved.
This explains a product choice that once would have seemed incomplete: some coding agents include file browsers that can read code but cannot edit it directly. Yet the experience does not collapse. The browser may already be doing the part the person most needs to do—see clearly.
The agent acts. The person understands and judges.
If that division of labor works in software development, why would it stop there?
The browser will not disappear. It will lose its monopoly on action
The easiest objection is that people still need interfaces.
Of course we do.
A map cannot return only coordinates. A design tool cannot return only node JSON. A financial report cannot say merely that everything looks fine. When we need to explore, compare, build spatial understanding, or inspect a high-stakes action before approving it, visual interfaces are irreplaceable.
But “the interface still matters” is not the same as “the interface must remain the main place where operations begin.”
A car has a dashboard, but the driver does not manually control every valve in the engine. The dashboard matters because it turns a complex state into evidence a person can understand.
The browser may increasingly take on that role.
Routine input and control can originate with an agent. The browser can display state, explain results, handle exceptions, and ask for final confirmation when the stakes justify it.
This division is already appearing in protocols. WebMCP lets a site preserve its human-facing interface while exposing selected page capabilities to an agent as predefined tools. Remote MCP goes further: an agent can operate a service even when its website is not open.
This is not AI clicking a web page for you.
It is one system serving two kinds of client: one designed for human eyes and hands, and another designed for agent reasoning and tool calls.
Tools, MCP, Skills, and Plugins answer four different questions
I have watched agents connect to the outside world through several stages. At first, they could call local tools and scripts. The central question was: What can the agent do?
Then came MCP. Different services could expose capabilities through a common protocol. The question became: How does the agent connect to those capabilities?
But connection does not guarantee competent use.
Skills added another layer. They package workflows, experience, templates, and cautions, then load that context only when it is relevant. The question became: How should the agent complete this kind of work?
Plugins bring Skills, MCP servers, authentication, and optional UI into something that can be installed and distributed. They begin to answer a fourth question: How can ordinary users safely acquire and trust this capability?
The progression is not really about four pieces of terminology. It reveals four things an agent needs before it can function as a client:
Capability, connection, experience, and trust.
Trust was the most visible gap in the early MCP ecosystem. Many connections depended on local processes, environment variables, and manually copied tokens. That was enough for experiments. It was not enough for ordinary users or critical systems.
Remote MCP authorization is now converging around OAuth 2.1, resource discovery, scopes, resource binding, and server-side token validation. Plugins organize those connections together with permissions, workflows, distribution, and—when people need it—an interface.
None of this makes for a thrilling demo. Authentication, permissions, and audit logs rarely do.
But when a technology starts taking boring problems seriously, it is often moving from toy to infrastructure.
The data supports the direction—and warns us not to run too far ahead
My own habits make it easy to believe that everyone already works this way. The evidence offers a more disciplined view.
Gallup found that 52 percent of US employees used AI at work in the second quarter of 2026. Most still used it for writing, research, and general problem-solving. Among AI users, only 16 percent reported using it for automation.
McKinsey’s August 2026 survey found that nearly nine in ten respondents worked at organizations using AI regularly in at least one business function, and 44 percent said AI was scaling across the enterprise. At the more specific agent layer, roughly two in ten organizations were scaling AI agents, with a similar share scaling coding agents. Size mattered: 40 percent of large enterprises were scaling agents in at least one function, compared with 22 percent of smaller organizations.
AI adoption is broad. Adoption of agents as a routine operating layer is shallower and uneven.
That can sound like evidence against the new-client thesis. It may instead describe the usual order of technological diffusion: people use a new tool to perform old tasks before they redesign work around it.
First we ask AI to draft an email. Then we ask it to read files, conduct research, analyze data, and make a presentation. Only after that do we connect it to GitHub, Vercel, Figma, Slack, databases, and internal systems and allow it to act.
Anthropic has observed this change in Claude usage. A year ago, most sessions were conversations between a person and an assistant. As Claude Code and Cowork grew, more sessions became long-running agentic tasks.
Conversation did not vanish. It became the starting point for action.
The systems best suited to agents were often not designed for agents
That sounds like another contradiction.
If the agent is a new client, should every company rush to build an “agent-native” version of its product?
Usually, I think the answer is no.
A confused system does not become coherent when an agent connects to it. Without a stable domain model, explicit operations, permission boundaries, auditability, and a way to reverse risky actions, the agent merely amplifies the confusion faster.
A system that works well for agents should first work well without them.
Its state is explicit. Its operations are composable. Its permissions can be constrained. Its errors can be understood. Its results can be verified. The agent does not create these qualities. It uses them through a new communication layer.
This is why AWS has long struck me as a useful example.
The AWS web console is not simple. But AWS has never treated the console as its only entrance. The platform has long been built around APIs, CLIs, SDKs, CloudFormation, IAM, and audit logs. Infrastructure can be described as code. Operations can be reproduced. Permissions can be narrowed. Calls can be traced.
Those decisions predate today’s agents, yet they provide almost exactly the environment agents need.
The AWS MCP Server, generally available since May 2026, lets agents call AWS APIs while remaining inside IAM guardrails and leaving operational evidence in CloudWatch and CloudTrail.
AWS did not gain a new cloud capability because agents arrived. The agent did not invent an operation that AWS could not already perform. What changed is that Codex or Claude can now become a client of those existing capabilities.
That reveals the least fashionable truth about being agent-ready. It is not a layer of AI attached to an old system. It is the result of doing the foundational work of software design unusually well.
GUI automation is a bridge, not the destination
Agents can already use browsers. They can inspect screenshots, identify controls, fill forms, and follow navigation. For systems without APIs, CLIs, or MCP servers, this is essential. It lets agents enter a world that was not built for them.
But we should not confuse an operation being possible with it being the right way to operate.
Asking an agent to use a GUI means repeatedly rendering structured state into pixels and asking the agent to infer structure from those pixels again. Every conversion adds latency, cost, and another opportunity for failure. A small redesign can invalidate a previously reliable path.
It is a necessary detour, not an ideal architecture.
Operation as code preserves the shape of the original intent. The agent receives explicit operations, parameters, permissions, and results. Failures can be located. Execution can be logged. Actions can be replayed.
GUI automation makes an agent imitate a person.
Operation as code lets an agent work like a machine.
This is why an older system with complete APIs, a mature CLI, clear permissions, and accurate documentation may be more agent-native than a new product with an AI button on every page.
The next generation of software will serve two kinds of user
If general-purpose agents become clients, good software will eventually offer two interfaces that cooperate.
The human interface will handle display, exploration, explanation, comparison, confirmation, and exceptions.
The agent interface will provide stable schemas, semantic operations, explicit errors, idempotent writes, dry runs, undo or compensation, least-privilege access, audit logs, and human approval for high-risk actions.
The agent will receive intent, gather context, perform repetitive operations, and coordinate across systems. The person will inspect evidence, understand consequences, and retain responsibility for important decisions.
There is already a small hint of this future in today’s plugin architecture: UI is optional. A background status check may need no visual layer at all. A tool needs to return an interface only when a person must inspect, compare, edit, or approve something.
That sounds like a technical detail. It may be an early description of the interface’s future: the interface no longer surrounds every operation. It appears where human judgment is valuable.
For the first time, users may own the client
Historically, a SaaS product decided how people would use it.
The product designed the navigation, pages, and process. Users learned each product’s language, moved between tabs, and divided one coherent objective into fragments scattered across several pieces of software.
A general-purpose agent changes that relationship.
The user begins to own a client. It knows the user’s goals, context, and preferences, then calls different services on the user’s behalf. GitHub, Vercel, AWS, Figma, and other products no longer have to be the beginning of the user journey. They can become capabilities composed behind the agent.
Software may soon compete for more than homepages, browser tabs, and time spent in the product.
It will compete for another position: which service is easiest for an agent to discover correctly, which operations are defined most clearly, which permission model deserves trust, which results are easiest to verify, and which work can be completed reliably without opening a web page.
The browser will not disappear. The IDE did not disappear when coding agents arrived.
But their position in the workflow will change.
We may be moving from a world where a person operates many pieces of software to one where a person operates a general-purpose agent, and the agent operates many pieces of software.
If that is right, the agent is not merely a feature inside software. It is not another chat window either.
It is a new client between the user and the software world.
Sources
- Gallup: Organizational AI Adoption Jumps Six Points
- McKinsey: The State of AI 2026
- Anthropic Economic Index: Cadences
- Anthropic: Introducing the Model Context Protocol
- OpenAI Developers: Plugin architecture
- OpenAI Docs: Build skills
- OpenAI Docs: Site tools / WebMCP
- MCP Authorization Specification
- AWS: The AWS MCP Server is now generally available