In the summer of 1994 I helped launch a product called ProShare. It put video conferencing on a desktop PC, years before anyone asked for it. There was no broadband, so we relied on telephone companies to install ISDN lines one customer at a time. And people did not want it. They had faxes. They had flights. Meeting in person was what serious people did, and no amount of engineering was going to change a habit that was working perfectly well for them. It took a pandemic, twenty-six years later, to move that habit, and when it moved it moved in a fortnight.
I have thought about ProShare a great deal this month, because I have been trying to get an AI agent to act as my travel agent, and I have been watching the software industry announce that its products are ready for agents. Both experiences point the same way. The shift from application interfaces to agent interfaces is the largest change in how software gets used since the desktop gave way to the phone, and it is at the stage the phone was at around 2009: everyone can see it coming, most incumbents are responding by shrinking what they already have onto the new surface, and the vocabulary is running ahead of the work. “Headless.” “Agent-ready.” “MCP-native.” These are being used as proof of arrival. They are descriptions of a job that has barely started.
The argument of this essay is that going headless is not a feature you add. It is a business decision most vendors have not yet made, because the graphical interface was never only the way into their product. It was where the seat was counted, where the upsell was shown, where attention was held and rules were enforced and the customer relationship was kept. An agent doing the work removes all five at once. That is why so many “agent-ready” products stop exactly where a real decision or transaction begins, why the pattern is identical in a consumer travel site and an enterprise HR platform, and why the companies that will build genuinely headless products are the ones with the least to lose from the interface going away.
The agent can look. It cannot finish.
Let me start with the journey, because it changed my mind twice.
In August, an AI agent with a browser turned a messy three-person road trip across Europe into a plan that worked. We were flying into Amsterdam and driving to a village in the Gironde to stay with friends, then back to Schiphol with a hard mid-morning deadline. The agent held the human preferences in one hand and the operational constraints in the other, and it kept them there across days of corrections. It found hotels near the motorway with parking and acceptable reviews. It checked a city’s low-emission-zone rules when the official checker refused our rental car’s country of registration, then looked the car up in the national vehicle registry to prove it was compliant. It did all of this by operating the human web: a booking site I was logged into, hotel pages, a municipal form, a government database. I made the bookings myself. The division of labour felt right, and I wrote at the time that the best travel agent is one that can use a browser.
In September I tried to get rid of the browser. Driving websites is slow, interaction-heavy and expensive in tokens, and the industry had spent the summer announcing programmatic surfaces for exactly this. So I set a harder problem, a multi-city itinerary for two people over the Christmas period, and pointed a booking platform’s agent interface at it. It was fast. It returned flight numbers, times, aircraft and durations in seconds, and it surfaced a connecting route the browser search had never shown me. For discovery it was better than a person.
Then it fell over at the moment a decision depended on it. I had asked for my home market in the Gulf. It quoted me from the United States, in dollars, at prices substantially higher than the same platform showed me in a browser, high enough to reverse the ranking of the options. It said “economy” and nothing more: no fare family, no baggage allowance, no change or cancellation terms. It could not assemble the multi-ticket trip, and it had no way of knowing I held status with the airline, because it had never asked me to log in. The agent interface existed. The agent-capable product did not.
Joanna Stern found the consumer version of the same wall in the same fortnight, in conversation with Ben Thompson. Testing Meta’s new personal agent, Muse, she asked it to book her hair appointment. It found the slot, then stopped: it needed her to log in, because the salon would not take a booking from a guest. “So then how much time did I save there?” Her back-to-school shopping test, run across three agents, improved markedly on last year’s and then hit what she called web compatibility: none could buy from the largest retailer, so all of them fell back to others. Thompson’s summary in that conversation is the general form of the problem: trying to get agents to do things that were designed for humans is hard.
I have a third case, from the office rather than the road, and it is the one that taught me the most. In the spring my team at Janus Digital set out to keep a multi-country HR and payroll platform we were already paying for as a headless backend, and to put agent-driven front-ends over it so that line managers would never have to learn the vendor’s interface. It never happened. The platform could not be driven without its screens, and the screens themselves were too complex for the people they were meant to serve, which is the predictable consequence of software built to serve every kind of customer at once, and not something an integrator can fix from the outside. We cancelled it in July and built our own. I will come back to what that cost, because it is the part of this story that vendors’ announcements leave out.
Three domains, three price points, one symptom. The agent can look. It cannot finish.
Transport is not capability
An API, a command-line tool, an MCP server, a plugin, a browser an agent can drive: these are ways into a product. None of them proves the product is complete without its screen. The industry’s mistake, and it is a very natural one, is to count the doors and call the building open.
The useful diagnostic came from choosing a CRM. This summer my colleagues ran a field of about twenty vendors down to a signed pilot in under two months, and the thing that decided it was not features, which were at parity, but what each product exposed to an agent. Every vendor in that market now has an API and most have an MCP server. What they expose is the data plane: create a contact, update a deal, log an activity. What they keep behind the interface is the control plane: who may do what, how the objects and workflows are configured, which webhooks fire, how long data is retained, what the audit log says. One market leader fell out because its official MCP server was read-heavy; an agent could look at the CRM but not run it. Another fell out because any meaningful customisation accumulated in a proprietary language that no agent, and no future migration, could carry anywhere else. The product we chose was three years old and open source, which conventional procurement would have vetoed, and it won because it treated agents as users under the same permission model as people, with a range of operation from full interface to fully headless, and because its open core meant we could leave. The control plane is where the seat is counted and the lock-in lives, so that is precisely where “headless” stops, and it is precisely what we ended up buying.
The website taught the opposite lesson, and it is the one I would ask vendors to sit with. We built the company site ourselves rather than through an agency, on the view that a website is mostly code and code is what agents now write well, and we put it on hosting and edge infrastructure that agents can operate directly: a real command-line tool, a real API, deployments and DNS and redirects all reachable without anyone opening a console. Once that was true, changing the site became a prompt. A new page, a copy fix, a market-specific redirect, a rebuilt component: describe it, review the result, ship. Somewhere in that process we noticed that we might not need the content management system we had also bought. A CMS exists to give people who do not write code a screen through which to change a website without a developer. When the change is a prompt, the screen is no longer the way in; it is the product’s reason to exist, and the reason had just got thinner. We still run one, and the question of what it earns its place for is open. But an entire software category built on giving non-technical people an interface is the clearest case I know of where the interface was the product, and where agent-operable infrastructure underneath it quietly removes the need.
That gives a test any buyer can apply, and I would encourage you to apply it to every vendor that has sent you an “agent-ready” press release this year. Can ninety per cent or more of the product’s transactions, administration included, be carried out programmatically, with proper authentication, with the action attributed to the person who authorised it, with an audit record, and without a human in the vendor’s interface at any point? If the answer is yes, the product is headless. If the answer is “the agent can do everything except”, the product has an API-shaped demo: machine-readable enough to impress, incomplete exactly where a real transaction depends on it.
The signs are consistent across industries. Indicative prices rather than authoritative ones. A market or point of sale that is inferred from a server’s location rather than declared. Inventory that is a curated subset of what the website shows. Missing fare rules, policies, permissions, exceptions. A link-out to a browser at the decisive step. No supported way to modify, cancel or recover what the agent created. Marketing that counts endpoints and tools rather than completed journeys.
Why the incompleteness is rational
It is tempting to read all this as immaturity. Some of it is; the protocols are young. But a good deal of it is a choice, and the choice becomes visible once you ask what the interface was doing for the vendor.
On the consumer side, the screen carries attention, advertising, recommendation, attribution and the relationship with the customer. An agent that completes the purchase takes every one of those. A travel site that let my agent finish would lose the ancillary upsell on the way to checkout, the retargeting cookie, the loyalty capture and the knowledge of what I looked at but did not buy. Its interest is not in a headless product. Its interest is in being the destination the agent hands me to.
On the enterprise side, the screen carries the per-seat price, the upgrade path and the control plane. An agent that does the work makes the seat uncountable. Rich Holmes, whose playbook on headless product strategy is the most practical thing written on this in the last month, puts the consequence plainly: per-seat pricing breaks when the work happens through an agent, so pricing has to move to the action or the outcome. Which gives me the single most useful business test I know for reading a vendor’s announcement.
A vendor’s willingness to go headless is revealed by its willingness to reprice.
A company announcing an MCP server while keeping per-seat pricing has told you where its headless ambitions end. It wants agents as a new kind of user who still needs a seat. A company that has moved to per-action or per-outcome billing has actually made the decision, because it no longer needs the screen to count anything. The reprice is the tell, and it is a far more reliable signal than the length of the tool list.
There is an even blunter version of the same signal. In March this year Amadeus, the largest of the global travel distribution systems, stopped accepting new registrations for its self-service developer programme. In July it switched the programme off entirely, disabling keys and closing the portal, and pointed developers at enterprise accounts with account managers. No reason was given beyond the fact of the decommissioning. The independent tools people had built on that surface, including the agent wrappers, now sit on nothing. Right as agents made open programmatic access to travel inventory valuable, the biggest player withdrew it. That is not immaturity. That is a decision, and it is worth remembering when the next vendor tells you it is racing to be agent-ready.
The buyer’s side of the same decision
If you accept that the vendor’s screen is where the vendor’s value has lived, then the buyer’s question changes shape. It stops being “which product has the best interface” and becomes “which product can my agents run, and can I leave it later.”
At Janus Digital we now evaluate tools on three lenses before anything else. Composability: does it do one thing well and hand off cleanly. Agent operability: is there a real command-line tool, a robust API and a native MCP server, and does the schema live in code rather than only in the interface. Reversibility: if we need to replace it in eighteen months, how hard is the migration. The last one is the discipline that stops the whole approach quietly failing. The strategy works because tools are replaceable; it stops working the moment state accumulates that only one vendor can read. A tool our agents cannot drive does not reduce the coordination overhead we adopted it to reduce. It becomes a dead sensor.
Then the build-or-buy line moves, and it moves toward building. Where a vendor’s data is not a moat and its generality is pure interface cost, we build. Where the domain is regulated, payments, statutory accounting, we integrate and stay well clear. The CRM and the CMS stayed on the buy side of that line because their data is not our moat and both could be left; the HR platform crossed it, and Ben Thompson, in that same interview with Stern, supplied the reason building worked when the vendor arrangement had not. Agents struggle with “stuff that has already been designed for humans,” he said, but shine in greenfield, where “there’s no structure to reproduce; we’re actually imposing structure for the first time.” A company’s own operating rules are that greenfield. No vendor’s screen ever encoded how we actually approve a hire or route a leave request. Building meant writing it down for the first time, in a form an agent could act on.
What the real thing costs
This is where the vendor announcements and the practitioner experience part company, and I want to be honest about it, because the honest version is more persuasive than the triumphant one.
A product with no screen has lost something the screen was providing for free. Which button was visible to which person. Which field was greyed out. Which step came next. What a manager could see that an employee could not. The interface enforced all of this by shape, without anyone writing a rule, and when the interface stops being where the work happens, every one of those rules has to be made explicit and enforced in code, because there is no longer a human looking at a screen to notice when something is wrong.
Building our own HR platform to run headless taught us what that list looks like. One layer of business logic, wrapped by both the web application and the agent tools, so that the two cannot drift apart. Identity taken from the session and never from the request, with acting on someone’s behalf a separate, permissioned act that the record names. Permissions as capabilities rather than role labels, and a single default-deny table for agent tools, so that a tool nobody has classified fails at its first call rather than shipping with full rights. Agents authenticated as first-class actors, with standards-based OAuth, rotated tokens and an audit line for every write and every read of personal data. Approval authority held as data on people records, not in code, so that when someone leaves, they leave every approval chain without a deployment. Separation of duties enforced on anything that moves money. Paid history that cannot be rewritten, with corrections as first-class records that name what they correct.
And one discipline that generalises further than any of the others: declare or refuse, never default silently. When a pay period contains a change the system has not been told how to handle, it refuses and names the reason, rather than picking a plausible interpretation. Its companion rule matters just as much: every refusal has to be clearable by some permitted action, because a refusal nobody can act on gets worked around, and a workaround is where the next audit finding lives.
The honest headline is that headless is harder than a UI, not easier. The interface was doing unpaid work. The evidence that it can be done is that we did it, with a test suite that grew by an order of magnitude and a review method that reproduced every refusal as a failing test before fixing it. When a vendor tells you it added an MCP server in a quarter, that is the measure to hold it against.
Where the interface survives
I do not want to overclaim, because the argument is stronger without it. The screen keeps three jobs.
Observability. The first question any department head asks about an agent-run process is how they will see what is going on, and it is a fair question. The right design is a slider, from full interface through to fully headless, with the dial moving toward headless as agent capability ships, and a dashboard remaining at the far end.
Consent. Some friction is a boundary, not a defect. Approving a hire or moving money should feel different from moving a card across a board, and the interface is a good place for it to feel different. Meta understood this: Muse for Mac will sort your files freely and must ask before deleting or sending anything.
Safety at volume. An agent operating over bad data produces confident wrong answers faster and at greater scale than any human clicking through a screen, because nobody is looking at the screen. That is an argument for making the data trustworthy before removing the human, not for keeping the screen, but it is a real argument and it deserves its place.
The mobile analogy holds here too. The desktop did not die. It became the place you go for heavy, deliberate work. The interface’s afterlife is the dashboard and the approval screen.
Platform shifts are won by whoever moves the developers
Here is where the ProShare story earns its place, because the lesson of a platform shift is not the one people usually draw from mobile.
The winners of the mobile transition were not the companies that made their desktop sites responsive. They were the ones that rebuilt around what the phone made newly possible, location, camera, push, identity in your pocket, and around what it made newly monetisable. Responsive design was the honest interim step, and it was also where most incumbents stopped. Wrapping an existing API one-to-one in an MCP server is the responsive design of the agent era. Rippling, which has thought harder about this than most, calls that approach “a recipe for an unnecessarily high AI bill” (as quoted in Holmes).
But even that is the demand side of the story. Platform shifts are decided on the supply side, by whoever can move the developers, and I have some experience of how hard that is. At Intel in 1989 I ran the company’s relationship with Microsoft, and the work that earned me an award that year was establishing the DPMI standard, which let 16-bit DOS software cross into 32-bit protected mode. It was a developer-migration problem dressed as a specification. A decade later I ran Intel’s consumer software programme, asking Electronic Arts, Hasbro, Mattel and Disney to build for the platform we needed them on. Neither was easy, and both were smaller shifts than this one. ProShare sits between them as the reminder that a platform can fail two gates at once: infrastructure, when the network is not there, and habit, when the people are not ready. The agent shift has the same two gates. Vendors exposing completion is the infrastructure gate. People letting an agent act for them is the habit gate. Stern’s salon fails the first. Thompson’s observation that customers rarely change habits is the second.
Which is why the most important news of the month was not an agent’s capability but a developer programme. On 18 September, ten days after launching Muse, Mark Zuckerberg announced that Meta was opening it to developers to build connectors, and the sentence he used should be read slowly: “You bring the API — Muse brings the agent, the browser, and the context of what the person actually wants. People reach your service just by asking for it, and their agent takes it from there.”
Consider what is in that sentence. The developer supplies a capability and gives up the interface, the relationship and the ranking. Meta supplies the agent, the memory of what you want, and, tellingly, the browser, for every service that has not built a connector and will have its screens driven anyway. The mechanics are App Store mechanics pointed at an agent rather than a home screen: a reviewed directory, editorial placement, Meta-controlled discovery among overlapping connectors. The launch roster already includes Gmail, Google Calendar, Outlook, Spotify, OpenTable, Plaid and Peloton, and the travel connector is Duffel, the flights infrastructure company whose own account of the integration is that a single booking “involves dozens of API calls, identity checks, payment processing and ticketing, and that’s before anything goes wrong.”
Whether this ends up an end-run around Apple’s App Store is too early to call, and consumers change habits slowly. But if anyone can move developers onto an agent surface rather than an app surface, it is the company with the largest distribution on earth and no installed interface business to protect. Meta is spending the one asset nobody else in the agent race has at that scale. The App Store was the control point of the mobile era because it sat between developers and users. The agent that developers build for is the candidate control point of this one.
The two-sided test
Duffel makes the whole argument concrete, because the same supplier can now be reached from two directions. Go to Duffel directly and you get a clean API: search is free to try, and it covers ancillaries, order changes and cancellations. But issuing a ticket in live mode requires either an accredited agency relationship or a managed balance with Duffel, which is to say that the right to complete is gated on a commercial identity most individuals and small companies do not hold. The data plane is open. Completion needs standing. Go through Muse instead and the agent finishes the flight booking, but only for users in the United States, and only on Meta’s terms, with Meta holding the commercial standing the consumer never sees.
And then look at what Muse does for hotels. Skift’s reading of the launch is that flights run through the Duffel integration with a virtual card, while hotels are shopped the old way: the agent drives the consumer booking sites in its browser, because no hotel supplier has given it anything else. Inside the most capable consumer agent yet launched, the last mile is still the browser wherever a vendor has not made the decision. Meta did not solve that problem. It absorbed it.
What all of this says is that “who controls completion” is the real question, and it is being answered right now by commercial arrangements, not by protocols.
The interface was the invoice
Browser control was supposed to be the transitional hack. It has become the last-mile interoperability layer for agents, precisely because the programmatic paths stop short, and that makes it a contested boundary. Sites can block agents, degrade their experience, write contracts against them, litigate, or reserve access for their own agents. The largest consumer platform in the world has just told developers it will drive their screens if they do not build a connector. Every one of those moves is a claim about who has the right to act on a user’s intent.
I began this essay saying that headless is a business-model decision, and I want to end by saying what the decision actually is. It is a decision about where you monetise and where you enforce once the screen is no longer where the work happens. Vendors that have made it reprice, expose the control plane, and treat agents as accountable actors with real identities. Vendors that have not add an MCP server to the edge of a product that still needs its screens, and hope the question goes away. It will not. The people who move the developers will decide it for them.
For my part, I am still going to book my own flights. The agent will look. Whether it can finish is, for now, up to the vendor’s business model, not its engineering. The important test was never whether an agent can press the buttons. It is whether the system stays complete when there are no buttons.
Unabashedly researched and written with the assistance of Claude. Ideas are all mine.