The most capable reasoning systems ever built can plan a trip, synthesize research across hundreds of documents, write production code, coordinate a dozen parallel workflows — and then hit a CAPTCHA and stop completely.
Not because they aren’t smart enough. Because the CAPTCHA wasn’t built for them.
That’s actually where we are. Agents that can think. A web that wasn’t designed to let them act.
The assumption nobody wrote down
Every layer of the modern web — buttons, menus, dashboards, hover states, loading spinners, modal dialogs — was designed for one specific user. A person sitting at a screen, with hands and eyes and the ability to scan a page and infer what the primary action is supposed to be.
That assumption was so universal it became invisible. Nobody debated it. It was just the shape of software.
Agents are not that person.
When an agent needs to complete a task, it doesn’t browse. It doesn’t scroll to get context. It doesn’t notice the CTA button is blue or that the pricing is tucked at the bottom. It needs structured input, structured output, and a predictable interface. Everything else — the gradient, the hero image, the personalized copy — is noise it has to filter through or work around.
Right now, almost all of it has to work around.
The wrong instinct
When most builders hit this realization, the instinct is to add AI to what they already have. A chat window in the corner. An “Ask AI” button. An AI-generated summary at the top of the dashboard.
That’s not the shift.
Adding AI features to a human interface is like adding a phone line to a restaurant because customers are now ordering by delivery app. Sure, it works. People can still call. But the kitchen is what matters now, not the phone.
The shift is that the primary consumer of software is changing. Not someday. Already. Agents are calling APIs, reading data, triggering workflows, and acting across systems at speeds and scales that no human interface was designed to handle.
The question for builders isn’t only “is this easy for a human to use?” anymore. It’s also — and increasingly — “can an agent reliably operate this?”
Those are different questions. They produce different answers.
What friction looks like on the other side
Here’s what a routine workflow looks like for an agent trying to do something simple.
The agent needs data from a SaaS dashboard. The dashboard requires login — cookies, session tokens, probably a two-factor prompt. The data itself is rendered inside a JavaScript single-page app, meaning the HTML the agent fetches is mostly empty divs that populate after JS executes. So the agent has to simulate a full browser, run the JS, parse the visual DOM, and extract what it actually needs — a process that breaks every time the dashboard changes its layout.
All of that, to get a table of numbers sitting in a database somewhere as a JSON object.
The agent never needed the UI. It needed the data. The UI was built for humans who want to see the data visualized nicely. For an agent, the UI is just latency and fragility stacked between it and the thing it’s actually trying to reach.
What building for agents means in practice
It doesn’t mean removing the human interface. Most products still have human users who need all of that — the buttons, dashboards, visual hierarchy, all of it. Keep it.
It means building a second interface alongside it. One designed for the other type of user that now exists.
For agents, that interface looks different. APIs instead of UIs — direct access to operations, not a visual wrapper around them. Structured data instead of rendered HTML — the JSON the table was built from, not the table. Protocols instead of pages — standards like MCP that give agents a shared language for tool use without reverse-engineering every new integration.
Small, composable operations instead of monolithic apps. Agents work best chaining focused calls together. A 47-item navigation menu isn’t richness for an agent — it’s a search problem it wasn’t hired to solve. Give it a stable set of single-purpose endpoints.
Stable contracts instead of personalized experiences. A human user appreciates an interface that adapts to their context — learns their preferences, surfaces what’s relevant. An agent needs an interface that behaves identically every time it calls. Personalization is a feature for humans. For agents, it’s a source of failures.
Adding the second door
The builders who understand this aren’t simplifying their products. They’re adding a layer.
They’re asking: if an agent needed to do everything our human users can do, what would that path look like? Not as an afterthought. As a first-class concern for a first-class user type.
In practice that means: ship an API alongside the dashboard. Publish a spec. Write error messages that are actually useful — not “something went wrong, please try again,” which tells an agent nothing, but a structured response with a code, a reason, and a suggestion for what to try next.
Make content machine-readable. Plain HTML is better than a JavaScript-rendered SPA when the reader might be software. Well-structured data that doesn’t require browser execution to access.
Think about discoverability. Build tools that describe their own capabilities so an agent can understand what it can do without someone manually reading the docs and configuring the integration by hand.
None of this is exotic engineering. It’s the same discipline that made APIs usable for developers a decade ago. Applied now to a different kind of reader.
The question that’s changing
Jakob Nielsen spent decades defining what usability means — what it takes for a human to find software easy to use. He recently said that traditional UI design becomes obsolete when agents are the primary users of digital services.
Not “might become.” Becomes.
That’s not a criticism of UI design. It’s a description of what changes when the user type changes. The measure shifts. The design decisions that optimize for humans don’t automatically carry over to agents.
Builders who internalize this aren’t abandoning UX. They’re extending what UX means. They’re holding two questions at once instead of one.
Can a human use this easily? Yes. Can an agent reliably operate this?
Most software built today can’t answer the second question. The builders who are asking it — and building to answer it — are the ones building for what comes next.