UI is the API every product has already shipped

Prathamesh Agrawal — Sat, 20 Jun 2026 17:36:59 +0000

A while back I asked an agent to do the most boring task I had. Go into Framer and enter the author details across a batch of blog posts. Names, roles, links. The kind of thing that takes a human twenty minutes and zero thought.

It couldn't do it.

Not because the task was hard. Because there was nowhere for it to act. Framer had no MCP, no CLI, no API I could point the agent at. It was smart enough to plan the whole job and then sat there with no surface to touch. So I did it by hand, like always.

Framer has since shipped its own MCP, and good for them. That is exactly the point I want to make.

Because one tool shipping an API does not fix anything. I was never going to build my work around waiting for Framer, then waiting for the next tool, then the one after that. The internet is not coming to MCP. Most of it never will, and a lot of it should not have to.

Look at the work you actually do in a day. You open LinkedIn to find one specific person and see who they know. You go through Slack to catch up on three channels. You fill out the same application form for the fifth time. You log into a product to read its analytics. None of that has a clean API. Some of it actively fights anyone who tries. And it is most of the work.

So I stopped asking when everything would ship an API. I started asking what surface already existed for all of it.

There is one. Every tool, even the worst internal dashboard, already shipped one interface. A UI, built for a human, running in a browser. The UI is the API every product already shipped. An API is a smaller, cleaner slice of what the interface can already do. The interface is the complete surface. The API is the part the vendor decided to expose.

Everyone is looking at the wrong two layers

Right now, if you are building agents, you are probably staring at two places for them to do work. MCP and the CLI. Give the model some tools, give it a terminal, let it go. Both are real and both are useful. But almost nobody is looking at the third surface, the one a person uses for most of their day. The browser.

I think about it as two stacks. There is a decision layer, the model and its reasoning, and that layer is crowded and getting cheaper every month. Then there is an execution layer, where intent turns into actual work. That layer is wide open, and the browser is the only candidate that already lives everywhere a human works.

The browser also carries something MCP and the CLI usually do not. Context. When an agent works inside my logged-in browser, it has my real state. My data, my permissions, my accounts, the actual app instead of a sandbox copy of it. It knows the surface of the work and the context of the work at the same time. That pairing is the whole thing.

The obvious objection

The first worry people raise is security, and they are right to. Handing an agent a logged-in browser sounds reckless, and done badly, it is. Raw access to everything you are signed into is a disaster waiting to happen.

That is the entire reason BrowserOps exists. A logged-in browser with proper guardrails is the bridge between agents and the real internet. The hard, valuable part is not pointing a model at a tab. It is the guardrails around it. What it can touch, what it has to confirm with you, what it can never do on its own. Get that right and the logged-in browser stops being a liability and becomes the most capable surface an agent has.

People also tell me computer-use will handle all of this on its own. Maybe some of it. But a demo clicking around a fresh machine is a very different thing from an agent operating your real accounts, with your real data, safely, every day. The demo is the easy 80 percent. The guardrails and the real logged-in context are the 20 percent that actually matters.

Why the gap does not close

This is not a stopgap until the world catches up and ships APIs everywhere. The long tail of software, internal tools, legacy systems, the niche SaaS your team lives inside, will never prioritize an API. There is no business case for it. So the gap the browser fills does not shrink over time. It is structural. That is what makes it worth building on for the next decade instead of the next quarter.

Where this goes

What I am building toward is an execution layer that sits under every agent and already knows how to operate the surfaces people use. The agent decides, the layer executes, and it happens across any tool, logged in, with context, without waiting for anyone to integrate anything. Work gets done faster and far leaner. You stop wiring up one brittle integration at a time and start operating the software you already have.

We started BrowserOps automating small things. Going through my Slack. Filling forms. A few weeks ago I fixed my wifi by letting it log into my router and sort out the settings. Nobody designed it for that. It just worked, because the router has a UI and a login, like almost everything else.

That Framer task that broke at the start runs now, in the browser, the same way I would do it by hand. Not because Framer shipped an API. Because the agent finally has the one surface that was there the whole time.

DEV Community: Prathamesh Agrawal

UI is the API every product has already shipped