unbrowseThe web spent 30 years learning how to serve humans.
Now it has to serve machines.
I'm Lewis Tham, first author of "Internal APIs Are All You Need" (arXiv:2604.00694). As far as I can tell, this is the current plan:
Every website builds an API.
Then documentation.
Then an SDK.
Then OAuth.
Then an MCP server.
Then every agent integrates it.
Then, eventually, agents can use the web.
There is one problem.
Agents aren't going to wait.
The integration model doesn't scale
Are we really expecting every website to separately decide how agents should interact with it?
Product chooses which capabilities agents get.
Engineering builds the API.
Someone documents it.
Someone maintains the SDK.
Someone builds the MCP server.
Someone configures authentication.
Then the agent integrates it.
Repeat for the entire internet.
On October 1 we checked how far the best-funded part of the internet has got. We probed the Tranco top 1,000. Of the 726 reachable sites, 37 run their own MCP server.
Thirty-seven, among the most valuable websites on earth. Nobody is writing the MCP server for your dentist's booking page.
And when a feature changes, someone works back through every layer.
We're trying to make the entire web integrate with agents. Agents are increasingly able to integrate with the web themselves. And the interface they need often already exists.
Your website already has an API
Open a modern web app. Search for something. Change a setting. Load your transactions. Download an invoice.
Watch the network tab.
In many of these apps, your browser is making structured requests to the website's own first-party APIs. The capability is the HTTP request under the button.
The website already has a machine interface, because the website itself is a machine using it.
Then an agent arrives and we pretend that interface doesn't exist.
The browser can download the invoice today. The agent gets told to wait for the API roadmap.
"We don't expose that capability through our API yet."
I just watched the website do it.
"Yes, that's the first-party API."
Oh, sorry. I didn't realize the request hadn't been introduced to society. Does it need a little sash? Do we take it to a developer conference and formally announce that computers may now send it JSON?
The operation exists. The account can perform it. The service's own client does it all day.
The browser gets the product. The agent gets the product's interpretation of the product.
This isn't rare. We looked at the 425 sites agents already use through Unbrowse. On 85% of them, no official API covers the task agents actually do there, partner programs included.
A wrapper around a wrapper around a wrapper
Look at the stack we keep assembling.
Build an API for your website. The browser talks to it. It works.
Now build an official API over the capabilities you already built, with its own credentials and a separate list of things it supports.
Now build an SDK around that, so developers don't have to write the requests themselves.
Now put an MCP server in front of it, so an agent can use a tool that calls the client that calls the official interface to the capability your browser was already using.
Now package the server as a connector, give it an onboarding flow, and ask the user to connect their account.
Connect to what? The browser is talking to it right now.
Here is the endpoint.
Here is the schema describing the endpoint.
Here is the tool describing the schema describing the endpoint.
Here is the connector exposing the tool describing the schema describing the endpoint.
We are four explanations deep and nobody has downloaded anything.
"First, create a developer account."
I wanted a receipt. When did I become a developer?
"Generate an API key."
Is that my password?
"No, this is a different credential."
Of course it is. The password only works on the website, where the thing I want is currently available.
"Now configure a service account."
I thought I was paying you for the service.
The assistant was supposed to take work off my hands. It has hired me as its integration engineer.
And after all that, perhaps the official API lists invoices but can't download them. Neither can the SDK, the MCP server or the connector.
Congratulations. You've standardized the disappointment.
Your permission, not a partnership
"Permissionless" doesn't mean bypassing authentication, reading someone else's data or ignoring the permissions of the underlying service.
It means using a website on behalf of a user shouldn't require a separate developer relationship with that website.
Think about hiring an employee. You don't email every SaaS company your business uses to ask whether they've implemented Employee Protocol yet. You give the employee appropriate access: their own account, a workspace invitation, delegated access. You explain the job and its limits. The service's existing permissions still apply.
Why should agents be fundamentally different?
Some authentication needs browser state or a human approval. Fine. Handle that. But not every engineering requirement has to come back to the user wearing a setup wizard.
Remove integration permission, not user permission.
And if a site wants paying for the load agents create, it should be paid per call.
Agents integrate with sites
Today:
Website → builds integration → agent → user gets capability
Tomorrow:
User wants something → agent learns website → capability works
The site's own frontend already demonstrates how its product works. Search, filter, create, update, purchase, download: every interaction can teach the machine something.
The frontend is, in effect, an executable specification: a working demonstration of the requests, inputs and state each operation needs.
"But the agent needs to know how to use the API."
You sold me an agent that can write software. Let it write the client.
The browser is the bootstrap
Browser agents were an important breakthrough. The browser is the web's broadest compatibility layer: it lets agents open, understand and operate software that was never designed for them.
But it doesn't have to be the final abstraction.
Say an agent needs an invoice, and the official integration doesn't support the download.
"I'll open the website."
Oh, we're back here. We did the developer account, the API key and the connector so the agent could announce that it needs the website.
Now it opens the browser. Loads the app. Runs the JavaScript. Renders the dashboard. Finds the billing menu. Clicks it. Waits. Finds the invoice. Finds the download button. Clicks it.
The frontend makes one request:
GET /invoices/123/download
The invoice arrives.
Tomorrow the agent needs another invoice. Same eleven steps. Again.
On our own demo booking site, browsing for the result takes a median 36.7 seconds. Replaying the request the site's frontend makes takes 1.97.
Once an operation has been learned and verified, the agent can go from:
intent → browser → DOM → click → frontend → API
to:
intent → API
The browser doesn't disappear. Use it to sign in. Use it to discover. Use it when browser state matters, when something changes, as the fallback.
But the billing animation does not need to finish for the concept of an invoice to exist.
For an operation that can be learned and replayed, the browser is the bootstrap, not the runtime.
Discover once, reuse everywhere
Agent #1 meets a website and works out how it operates.
Agent #2 arrives tomorrow and works it out again.
Agent #3, #4, #5: same site, same menus, same requests, a fresh discovery every time. Imagine millions of capable machines independently reverse-engineering the same interfaces.
Search engines made discovery reusable for people. The thousandth person searching for something didn't retrace the first person's path through the web.
Agents need the same for capabilities. The first agent might have to discover how something works. The thousandth shouldn't.
Share the knowledge of how the operation works. Keep each user's credentials and private data out of it.
Knowing where the invoice lives does not give you permission to read mine.
An index of what the web can do
Google maps:
query → page
Agents need:
intent → capability
"Find my latest invoice." "Cancel my reservation." "Check whether this product is back in stock." "Pull last month's analytics."
Each of those is an operation. Humans need interfaces around operations. Agents increasingly don't.
For agents, the useful primitive becomes:
intent → route + schema + auth + execution
Pages were the primitive of the human web. Capabilities can be the primitive of the agentic web.
APIs and MCP still matter
If you operate a service, make yourself easy for agents to use. Build stable APIs. Provide good authentication. Expose structured data. Build MCP servers when they make things easier.
Official APIs bring stability, documentation and narrower permissions. A first-party interface can change and leave you fixing it. That's a real tradeoff.
MCP doesn't require the wrapper procession above; teams choose that architecture. A shared tool contract can be useful. Packaging an ugly workflow can be useful. Do that work, and show me what disappeared from the user's plate.
The mistake is believing that no official integration means no capability.
And yes, Unbrowse has machinery too. We expose APIs and MCP tools. We haven't defeated abstraction by choosing a shorter name. If our machinery hands the user another integration project, roast us with the same paragraph.
The test is whether the abstraction removes work.
The agentic web won't be built one integration at a time
There is already an enormous machine interface underneath the human web. Browsers reveal how it works. Agents can learn it. And what one agent discovers can become reusable infrastructure for the next.
That's what Unbrowse is built around. Use official interfaces when they exist and do the job. Learn the underlying interface when they don't. Use the browser when the browser is actually needed. Verify what can be reused, and reuse it.
Today, Unbrowse discovers capabilities, learns from browser requests and replays verified routes. Its public registry shares read-only operations that carry no secrets; private sessions and writes stay out of it.
It's one MCP server: unbrowse.ai/mcp. Point your agent at a site it couldn't use, and tell us what broke. The docs show how to connect it.
Search indexed what the web knows.
Unbrowse indexes what the web can do.
The agentic web won't arrive when the last company publishes its MCP server. It won't wait for every API roadmap, or every partnership, or every website to decide it's ready.
The capabilities already exist. The agents are already arriving.
Agents can integrate with sites.
This is the text as posted on X on 10 October 2026. A note on reuse: the invoice route is illustrative. Learned routes still need verification and maintenance; some operations remain browser-dependent. Reusable route knowledge excludes credentials and private data, and each user's access remains their own. Paying sites per call is an opinion here, not something Unbrowse does today.