Three generations of software are being sorted by a single test: can your product deliver its core value without a human touching it?
In the summer of 1968, a back-office clerk on Wall Street could spend his entire morning walking stock certificates from one brokerage to another. Leather satchel, crowded sidewalk, physical pieces of paper that each represented ownership of actual shares. He would deliver them to the right firm, wait for a signature, walk back, pick up the next batch. On a good day, everything matched. On a bad day — and by that summer, most days were bad — the certificates piled up in hallways, landed at wrong addresses, or vanished entirely. Daily trading volume had hit twelve million shares, and the back offices could not keep up.
The NYSE did something almost unthinkable: it closed on Wednesdays. For months, from June through December, the exchange shut down one day a week to let clerks dig out from the backlog. Trading hours were shortened on other days too. It wasn’t enough. Dozens of brokerage firms collapsed between 1968 and 1970, buried under paperwork they could not process. At a 1971 Senate hearing, Attorney General John Mitchell cited figures as high as $400 million in securities looted by organized crime syndicates from the wreckage. The physical certificate — a piece of technology that had worked adequately for generations — had become the bottleneck in a system that had outgrown it.
The solution was not faster messengers. It was not better filing cabinets. In 1973, the industry created the Depository Trust Company, a centralized electronic system that held securities in immobilized form and recorded ownership changes through book-entry accounting. The physical certificate did not get improved. It got bypassed.
I keep returning to this story because I think every software application built for human users is a stock certificate. A form, a dashboard, a search bar, a settings screen — each one exists because a human needed to see something in order to do something. The entire apparatus of modern software UX is a translation layer: it converts what a machine can do into something a pair of eyes can parse, and converts what those eyes decide back into something the machine can execute. For fifty years, that translation was the product. The interface was not overhead. It was the thing you were selling.
AI agents do not need to see. They need an API call. And that fact is about to sort three generations of software the way the DTC sorted Wall Street: not by improving the old mechanism, but by removing the need for it.
I. The Middlemen
Start with the category most exposed. Generation one apps — the ones whose core value is aggregating information for a human to browse.
You know the experience. It is eleven at night, you are booking a trip, and you have six browser tabs open — Kayak, Expedia, Booking.com, Google Flights, the airline’s own site, and a fare tracker you found on Reddit. You scan prices, squint at layover durations, weigh trade-offs by eyeballing grids. The interface was the product. The whole business rested on being the place where a human with limited patience could see enough options to make a decent choice.
That deal is already eroding. Expedia and Booking.com now operate as apps inside ChatGPT — real-time travel search running inside someone else’s interface, their own front-end conceded. Kayak went the other direction, launching “AI Mode” in October 2025: a conversational search experience embedded on its own site, fighting to remain the surface the user touches. Two strategies, same confession. The visual comparison grid — the thing these companies spent decades refining — is becoming optional. An agent that knows your budget, your schedule, your preference for window seats and morning departures does not need to see a grid. It needs structured data and an API.
Yelp, TripAdvisor: aggregated reviews for a human reader who would scroll, skim, weigh star ratings against written complaints, develop a gut sense of whether the Thai place on Elm Street was worth the trip. An agent digests sentiment data. It doesn’t scroll. It doesn’t need the review to be written in engaging prose. It needs a reliable signal extracted from a thousand reviews, delivered as structured output.
Zillow, Rightmove: valuable because a human needed to see the listing. The photos, the floor plan, the map with the little pin. An agent needs square footage, price history, commute time to the office, school district rating, and flood zone status — all as queryable fields. The beautiful listing page is a translation layer for human eyes. Remove the eyes, and you’ve removed the reason the translation exists.
The mechanism underneath all of these is the same. These companies translated raw data — airline schedules, hotel inventories, restaurant reviews, property records — into something a human eye could parse. When the eye is removed from the loop, the translation is wasted work. Not wasted in a philosophical sense. Wasted in a compute-and-bandwidth sense. The agent is doing extra work to extract structured data from a page that was built to present it visually.
There is a useful distinction here: “browse” versus “retrieve.” Browsing implies a human scanning possibilities, forming impressions, noticing things they weren’t looking for. Retrieval implies a machine querying for specific attributes against defined criteria. Generation one apps were built for browsing. The agent economy runs on retrieval. The browse layer doesn’t add value for a machine. It adds latency.
This matters commercially because the aggregator’s revenue model depends on being the surface. Kayak makes money when you see the ad next to the flight result. Zillow makes money when the listing agent pays for premium placement that catches a human eye. TripAdvisor makes money when the restaurant buys a featured review position. Every dollar flows through the assumption that a person is looking at the page. When the agent retrieves the data through an API, the page never loads. The ad never renders. The revenue model does not have a line item for “machine queried our data and left.”
Some of these companies will adapt by becoming the API itself — the data provider behind the agent’s answer. But a data provider earns infrastructure margins, not interface margins. The difference between being Kayak the travel search destination and being Kayak the flight-data API is the difference between building the store and stocking someone else’s shelf.
II. The Stripe Test
There is a clean test for whether a product survives the transition, and it is worth stating bluntly: can your product deliver its core value through an API call with zero user interface? If yes, you are infrastructure. If no, you are a middleman wearing an infrastructure costume.
Stripe passes. Its value was always the action — moving money from one party to another while handling compliance, fraud detection, tax calculation, and settlement across borders. The dashboard was convenient. The API was the product. And Stripe is already building for the agent economy explicitly. In late 2025, it launched the Agentic Commerce Suite with Shared Payment Tokens — a new payment primitive that lets applications like ChatGPT initiate a payment using a buyer’s saved payment method without exposing their credentials. Each token can be scoped to a specific seller, bounded by time and amount, observable throughout its lifecycle. In parallel, Stripe co-developed the Agentic Commerce Protocol with OpenAI — an open standard for connecting buyers, their AI agents, and businesses to complete purchases. Leading brands from Etsy to URBN are already onboarding. Stripe did not pivot to serve agents. It noticed the dashboard was always the wrapper, not the gift.
Twilio passes. It sends an SMS. The API call is the product. No human needs a dashboard for the message to arrive. The dashboard exists for monitoring, debugging, analytics — functions that are themselves increasingly performed by agents.
AWS passes. It computes, stores, serves. The management console is a convenience layer. The infrastructure underneath runs whether a human is logged into the console or not. Most production workloads on AWS are already managed through infrastructure-as-code and API calls, not through a person clicking buttons.
Plaid passes. It is a data pipe between financial institutions and applications. The interface is a developer tool. The pipe is the product.
Many SaaS companies think they belong in this category but don’t. The tell is straightforward: if you removed the dashboard and no human ever touched your product again, would the core value still be delivered? For Stripe, the answer is obviously yes — money still moves. For most of the enterprise tools that salespeople, HR managers, and project leads use daily — the CRMs, the project trackers, the expense systems — the answer is murkier. The value is entangled with the interface in ways that are hard to separate. The dashboard is not a window into the product. The dashboard is the product.
Satya Nadella has been saying this out loud. In a recent appearance on the BG2 podcast, he described traditional business applications as databases with a layer of business logic on top, and argued that the logic is migrating to what he calls an “AI tier” — agents operating across multiple databases, independent of the applications they query. The agents won’t discriminate between your sales system and your accounting system. They will update both, keeping all the logic in the AI tier, and neither application’s user interface will be involved.
That is either a prediction or a threat, depending on whether you sell the database or the dashboard.
The uncomfortable implication for most SaaS companies is that if you apply the Stripe test honestly, most of the subscription revenue in enterprise software is being paid for interfaces, not for actions. The database underneath could often be replaced by a simple, well-designed data store. What justifies the $50-per-seat-per-month pricing is the form layer, the workflow builder, the drag-and-drop interface, the color-coded status tags. All human accommodations. All unnecessary for a machine. When agents can operate on the database directly, the per-seat pricing model starts to look like a toll on human fingers — and agents don’t have fingers.
III. The Four Survival Layers
Not everything with a user interface dies. The question is not whether a product has a UI. The question is why.
The action layer. Some products do things in the physical or legal world that an agent cannot do on its own. Stripe moves money across regulated financial rails. Twilio sends messages through telecom infrastructure. AWS runs servers in physical data centers. Shopify — which now offers MCP servers implementing the Universal Commerce Protocol it co-developed with Google, Walmart, Target, and twenty other partners — fulfills and ships physical goods. These products are the hands. The agent is the brain. A brain without hands is a thought experiment. Hands without a brain are just labor. The action layer survives because the agent needs it to act.
The trust layer. Some decisions carry stakes that demand human-accountable systems of record. Banking, medical records, identity verification, legal filings. An agent can prepare a loan application — gather the documents, fill the forms, run preliminary credit analysis. But a human institution must approve it, because approval means accepting liability, and liability requires a legal person on the hook. I traced the accountability argument in Cheap Thinking: when thinking commoditizes, the premium on being the person who signs off increases. The trust layer is where that premium lives. The systems of record that serve it — core banking platforms, electronic health record systems, land registries — survive not because their interfaces are good but because their audit trails are legally binding.
The experience layer. Some products exist because using them is the point. Video games, music production software, creative tools, social media feeds, drawing apps. Nobody asks an agent to play a video game on their behalf. Nobody delegates the experience of making music to a machine and considers the task complete. The interface is not a means to an end. The interface is the end. UI survives where the verb is “experience” and dies where the verb is “accomplish.”
The context layer. Some products hold deep, proprietary state that agents depend on to function. CRMs with years of customer interaction history. ERPs with supply chain configurations. Internal wikis with institutional knowledge. The agent queries these; it doesn’t replace them. The data is the moat. But this layer is the most contested of the four, because it faces an uncomfortable question: if the data can be extracted and held by the agent itself, does the application retain any value beyond being a read-only database? If the agent can ingest your entire CRM into its context window, query it faster than your search bar, and cross-reference it against data from three other systems simultaneously — what, exactly, is the CRM’s interface contributing? The context layer survives only as long as the data cannot be cheaply replicated or absorbed. For many applications, that clock is ticking.
IV. What Actually Dies
The previous sections describe a mechanism. This section names the casualties.
Every form, dashboard, search bar, and settings screen is a concession to a human who cannot speak machine natively. An agent can. What dies is the concession — the translation apparatus that made database operations palatable for a person with eyes and a mouse. Data-entry apps: the form layer, the validation prompts, the “Are you sure?” dialogs, the toast notifications. All replaced by a well-documented API. Configuration screens: the toggles, the dropdowns, the nested menus that translate parameter files into something a human can click through. All unnecessary when the consumer of the configuration is a machine that can write the parameter file directly.
Dashboards are the same concession in visual form. A chart exists because a person cannot see the trend in ten thousand rows, but a person can see a line going up. The agent does not need the line. It needs the rows. Dashboards were never the data — they were the data’s costume, dressed up for an audience that could not process it raw. And search interfaces are the same concession applied to navigation — a search bar is a confession that the system’s data is too complex for a human to navigate directly. An agent queries the database with precise parameters at the speed of an API call. I traced this dynamic in The Reader Without Eyes — the web is already being translated in place for machine readers, human-facing pages converted to stripped-down text at the moment of request. The search interface is the same artifact in miniature: a human concession being silently bypassed.
V. Where This Breaks
I have been building a case that the UI is a translation layer and the translator is being fired. The argument has a clean internal logic. But clean internal logic is not the same as being right, and there are at least three genuine objections that threaten the thesis in ways I cannot dismiss.
The interface is the thinking. For many knowledge workers, the dashboard is not just a display. It is a cognitive workspace. A project manager staring at a Kanban board is not passively receiving information. She is noticing that two tasks in the “In Progress” column have been there for nine days. She is sensing that the cluster of red labels in the bottom row means the backend team is overloaded. She is forming an intuition — one she could not articulate as a query — that this sprint is going to slip, and that the cause is not any single task but a pattern in the distribution of effort across the board. The board is an instrument of thought, not a display of results.
A spreadsheet is not a “nice form for a database.” For millions of users, it is the primary tool through which they reason about numbers, test assumptions, and build mental models. Removing the interface does not just remove a translation layer. It removes a cognitive workspace that the human’s thinking depends on. The agent can query the data. But the data was never the point. The act of looking at it — of arranging it, filtering it, staring at it until something clicked — was the point.
This objection does not kill the thesis, but it limits it severely. The apps that die are the ones where the interface mediates between the user and an outcome the user wants. The apps that survive are the ones where the interface mediates between the user and their own thinking. The distinction is real, and it is not always obvious which side a given product falls on.
Agents are terrible at ambiguity. The thesis assumes agents can replace human judgment in browsing and choosing. But try this: “Find me a hotel my mother-in-law would approve of but I’d actually enjoy.” That query requires taste, social awareness, knowledge of unstated family dynamics, and the ability to optimize across two contradictory preference functions simultaneously. An agent can retrieve hotels. It can filter by price and rating and location. It cannot navigate the minefield of an intergenerational vacation without a map that doesn’t exist in any database.
The middleman apps — the generation one aggregators — survive in the gap between what an agent can query and what a human actually needs. That gap may narrow over time. But it is wide today, and for queries that involve social context, aesthetic judgment, or preferences the user cannot fully articulate, it may remain wide for a long time. The aggregator’s interface was never just a translation layer. It was also a thinking environment where the human resolved their own ambiguity by looking at options they hadn’t considered. You don’t always know what you want until you see what’s available. The browse is where the want takes shape. An agent that returns a single optimized result has solved the wrong problem when the user didn’t know what problem they were solving.
There is a harder version of this point. If agents handle the retrieval and the aggregator’s visual interface atrophies, the influence game doesn’t disappear — it migrates to whoever shapes what the agent retrieves. The middleman’s interface was at least visible. You could see the sponsored listing, evaluate the promoted result, decide for yourself. When the agent curates, the curation is invisible. The aggregator’s visual interface, whatever its flaws, was a space where the human maintained sovereignty over their own choosing. The post-interface world may be more efficient. Whether it is more honest depends entirely on who writes the agent’s instructions.
The API layer does not exist yet. This is the most practical objection and possibly the most damaging. Most SaaS applications were not built API-first. They were built interface-first, with APIs bolted on later as an afterthought — incomplete, inconsistent, rate-limited, poorly documented. The value of these products is entangled with their interfaces in ways that cannot be cleanly separated without an architectural rewrite.
Migrating from “app with optional API” to “API with optional app” is not a feature toggle. It is a fundamental rearchitecture. Shopify has done it — its MCP servers, its Universal Commerce Protocol with Google, its agentic commerce integrations demonstrate what an API-first commerce platform looks like. But Shopify spent years building that foundation. Most companies are not Shopify. Most companies have a decade of technical debt, a UI that encodes business logic in frontend code, and an API that exposes maybe 40% of what the product actually does.
The thesis is directionally correct. But the timeline is uncertain and the transition costs are real. The 1968 paperwork crisis took five years to produce the DTC. The internet took well over a decade to contract the traditional travel agency industry from its peak — and even then, the contraction was uneven, with certain niches (luxury travel, complex itineraries) resisting longer than anyone predicted. Software’s rearchitecture around agent-first consumption will play out over years, not quarters. Some companies will get there fast. Many will discover that their interface was not a layer on top of the product but a load-bearing wall, and tearing it out brings down the building.
There is a subtler version of this objection too. Even when the API exists, even when it’s well-documented and fully featured, there is the question of trust. An enterprise IT director approving an agent’s access to the HR system is making a different risk calculation than approving a human employee’s login. The human can be fired. The human understands context. The human will probably not accidentally delete three hundred employee records because a prompt was ambiguous. The agent might. The interface was never just a translation layer. It was also a guardrail — a set of constraints that prevented certain classes of error by limiting what a user could do at each step. Dropdown menus, confirmation dialogs, required fields, role-based access — all of these are safety mechanisms that operate through the interface. Remove the interface, and you need to rebuild every one of those guardrails in the API layer, which many APIs do not currently do. The transition from “app with guardrails” to “API with equivalent guardrails” is not just an engineering problem. It is a trust problem. And trust problems move slowly.
VI.
I began on the floor of the New York Stock Exchange in 1968, watching clerks physically carry pieces of paper that represented ownership of shares in American companies. The system had worked for decades. Generations of traders, brokers, and messengers had built careers around the physical certificate — had developed expertise in handling it, institutions for storing it, regulations for transferring it. The certificate was not just a piece of paper. It was the center of gravity around which an entire industry organized itself.
Then trading volume exceeded what the paper could handle, and the paper went from being the foundation to being the bottleneck. The solution was not faster paper. The solution was recognizing that the paper had never been the point. The point was the ownership transfer. The certificate was a concession to the fact that, in 1968, there was no other way to make ownership transfer legible, auditable, and trustworthy. The moment an electronic system could provide legibility, auditability, and trust without the physical artifact, the artifact became dead weight.
Software is in the same position. For fifty years, applications have been designed for a human with eyes, a mouse, and a limited attention span. The entire UX profession, the entire SaaS business model, the entire apparatus of forms and dashboards and onboarding flows and tooltip tours — all built around the assumption that a person is on the other end. That a person needs to see in order to act. That the translation from machine-readable to human-readable is where the product lives.
That assumption is expiring. Not immediately — the objections in the previous section are real, and the transition will be messy and slow in places that matter. Not completely — the experience layer, the trust layer, and the cognitive workspace will persist because they serve purposes that have nothing to do with translating machine output for human eyes. But structurally, the direction is legible. The agent does not need the translation. And when the translation is no longer needed, the products built around it face the same reckoning the stock certificate faced in 1973.
The app that thrives in the next decade is not the one with the best UI. It is the one that realized its UI was never the product. The product was the action — the money moved, the message sent, the server provisioned, the record updated. The interface was a concession to the human in the loop. A necessary concession, for fifty years. A generous one, even. The UX designers who made software usable performed a genuine service, translating alien machine logic into something a person could navigate without an engineering degree.
But concessions to a participant who is leaving the loop have a shelf life.
This is part one of a three-part series. Part two — “Before the Panic” — examines what institutions have to be invented when machines become economic actors. Part three — “One Thing Well” — examines where the deepest value concentrates when horizontal software commoditizes.