The last mile of agentic AI, getting the thing to actually touch the tools humans use, is being solved two different ways right now, and whichever one sticks is going to shape how software gets built for the next decade. Daniel wrote in with a whole breakdown of this. He's watching two patterns fight it out. One is the direct MCP integration, the technically pure route where an agent talks to a typed API. The other is browser-use, extensions that expose the backend, or vision models that look at the screen and find the button. He thinks we're in a trial-and-error period, that one of these eventually eats the other. He wants to know which surface is more durable technically, what the practical tradeoffs are when you're controlling the same data, and whether updating the same email or Google Sheet gives you different capabilities depending on which route you took.
So let's pull these two approaches apart and see what's actually underneath them.
Before we do, I want to flag the thing Daniel's actually circling. He's not asking which one is cooler. He's asking which one is load-bearing. Because if you're building an agent that's supposed to update a budget sheet at two in the morning while nobody's watching, the answer changes what you can promise.
Right. And the two patterns are genuinely different animals, even though they look similar from the outside. MCP integration is a formal protocol. A server sits in front of Google Sheets, or Gmail, or whatever, and it exposes typed tools. Update cell. Get range. Apply formula. The agent calls those functions the way any program would call an API, and the contract is explicit. You know what the inputs are, you know what the output shape is, and if something goes wrong you get a typed error back.
And browser-use is not that.
Browser-use is not that. Browser-use is an agent driving a real browser instance. There are two sub-paths. One reads the rendered page structure, the DOM or the accessibility tree, and selects elements by their semantic roles. So it finds the cell because the cell is tagged as a cell. The other path screenshots the page and uses a vision model to locate the button, then maps pixel coordinates to click actions. VentureBeat had a piece on this in late July, and the notable thing is they were describing vision as a complementary path, not a replacement. It's for discovering buttons and mapping them onto technical entities when the DOM route isn't enough.
So one pattern operates on the data model and the other operates on the presentation layer. That's the whole thing in one sentence.
That is the whole thing in one sentence. And it's the reason the failure modes are so different. When you update a cell via MCP, you're invoking a function. The function either succeeds or it returns an error. When you update a cell via browser-use, you're simulating a human. You locate the cell, you click it, you clear it, you type the new value, you press enter. Each one of those steps is a potential failure point.
And the browser is a moving target. The API is not.
The MCP contract is the API, which is versioned and stable. If Google changes something under the hood, the public API stays compatible, or they deprecate it with a year of notice. The browser-use contract is the DOM and the pixels. Every frontend deployment changes those. A selector that matched yesterday doesn't match today. A vision model that recognized the blue save button now sees a slightly different blue save button and hesitates.
Hesitates is a generous word for what a vision model does when a button moves three pixels.
It's the failure pattern people don't talk about enough. MCP fails cleanly. You get a rejected call, you retry, you're done. Browser-use fails messily. You get a race condition where the agent clicks and then a JavaScript re-render happens mid-action and the click lands on something else entirely. Or the vision model misidentifies a button because the page loaded a new ad in the sidebar.
I want to sit with the concrete example Daniel raised, because it makes the asymmetry vivid. Updating a cell in Google Sheets. Via MCP, it's a single typed call. Update cell, row forty-two, column C, new value. Done. Via browser-use, the agent has to find the cell in the rendered grid, click into it, clear whatever's there, type the value, and confirm. That's five steps, each with a nonzero failure probability.
And the failure compounds. If the first click misidentifies the cell, everything after it is garbage. You've just overwritten the wrong row. The MCP call can't do that. It's structurally incapable of clicking the wrong cell because there's no clicking. There's a row index and a column index and the server resolves them.
So mechanically, MCP wins on reliability. But I want to be careful here, because there's a misconception baked into a lot of the coverage. People assume browser-use is inherently less reliable, full stop. That's not quite right. It's less reliable for well-defined operations. But it can do things the API never exposes, and for those things there's no reliability comparison to make. The API just doesn't show up.
The Gmail example is the cleanest version of this. Undo send. Via MCP, you can't click undo send. It's a UI-only feature. There's no API endpoint for it. Via browser-use, you can, because you're simulating a human clicking the little toast notification that appears after you send. So the browser route isn't just a worse version of the API. It's a different capability surface entirely.
Which is the second-order thing Daniel's really asking about. Same data surface, different capabilities depending on the route. And the divergence goes both directions.
It does. Via MCP on Google Sheets, you get the full API surface. Batch operations, filters, formatting, permissions, everything the vendor exposes programmatically. You can apply a formula to ten thousand rows in one call. Via browser-use, you have to scroll, select, paste. And you hit virtualization issues, where off-screen rows don't even exist in the DOM yet, so the agent literally cannot see them until it scrolls.
The rows don't exist. That's a good detail. The thing you're trying to manipulate is not there until you go looking for it.
And meanwhile the browser route gives you the long tail. Multi-step wizards, CAPTCHAs, third-party integrations embedded in the page. All the stuff the API doesn't model because it's not really a data operation. It's a workflow.
So we've got two axes of comparison now. Reliability and coverage. MCP wins reliability, browser-use wins coverage. And the durability question is which axis matters more over time.
I think the answer is that they serve different layers, and the convergence is already happening. But before we get there, I want to talk about the vendor power play, because it's the thing that makes this not just an engineering question.
Go on.
Google and Microsoft control both surfaces. They own the productivity suites, and they own the browsers. Chrome, Edge. So they get to decide whether MCP servers are first-class citizens or afterthoughts. And they have a real incentive to keep them from being too good.
Because if MCP becomes the dominant pattern, they lose control over how their products are used.
Right. The browser is their defensive moat. When you use Gmail through the browser, you're in their environment. They can change the UI, they can A/B test, they can show you what they want you to see. When an agent talks to Gmail through MCP, it's just hitting an API. The interface is whatever the API says it is. Google still owns the API, but the relationship is different. It's more like being a utility than being a product.
And they've spent twenty years making the browser the product.
They've spent twenty years making the browser the product. So there's a structural reason they'd keep MCP servers good enough to be useful but not good enough to be the obvious choice. Keep the weird operations, the judgment calls, the things that require human-like interaction, keep those browser-only.
That's the thing Daniel's really asking about when he says one pattern will dominate at the expense of the other. If the vendor controls both surfaces, the vendor can pick the winner. And the vendor's interest is not necessarily the same as the builder's interest.
The long tail argument is where this gets complicated. MCP requires the vendor to build and maintain a server. Google Sheets has one. Gmail has one. But there are thousands of niche SaaS tools that will never have one. The vendor is a three-person startup in Krakow, they're not building an MCP server. Browser-use works on those tools today with zero vendor cooperation. It's the universal adapter.
So browser-use won't die. That's the claim. It can't die, because it's the only thing that works for the long tail.
And MCP won't die either, because the reliability bar for production agents is real. A financial operations agent updating a spreadsheet cannot tolerate a five percent failure rate from a misclicked button. When money's involved, deterministic behavior wins. MCP's typed contract is the only path to that bar.
So we're not actually heading toward one pattern dominating at the expense of the other. We're heading toward a division of labor.
That's the convergence thesis. Browser-use becomes the discovery layer. Vision finds the button, maps it to a technical entity, figures out what's possible. And MCP becomes the execution layer. Once you know what you want to do, you do it through the API, because the API does it reliably.
The browser tells the agent what's possible, the API does it.
And you can already see this in the way the tools are being built. The VentureBeat piece from July was describing exactly this. Vision as a complementary path for discovering buttons and mapping them onto technical entities. Not vision as the thing that clicks the button. Vision as the thing that figures out which button exists, so that the structured layer can act on it.
That's a meaningful distinction. The pixel is for discovery, the function call is for execution.
And the reason it matters is that discovery is inherently fuzzy and execution is inherently precise. You want a vision model for the fuzzy part, because fuzzy is what vision models are good at. You want a typed API for the precise part, because precision is what APIs are good at. Matching the tool to the task.
I want to push on the durability question one more time, because Daniel asked it directly and I don't think we've fully answered it. Which surface is more durable, technically?
I think the honest answer is that the API is more durable, but the browser is more persistent. Those are different things.
Say more.
The API is durable in the sense that a well-designed API contract outlives any particular UI. Gmail's API has been stable for over a decade while the Gmail UI has been redesigned half a dozen times. If you built an integration on the API in 2015, it probably still works. If you built a browser-use tool on the Gmail DOM in 2015, it's been broken and rewritten many times.
So durability in the sense of not breaking.
Right. But the browser is persistent in the sense that it's always there. Every web application has a browser interface. Not every web application has an API, and even the ones that do don't expose everything through it. So the browser surface never goes away. It's the lowest common denominator.
The thing that's always available but always changing.
And that's the tradeoff in one line. The API is stable but optional. The browser is universal but unstable. You pick your poison.
Which brings me back to the vendor power play, because I think that's where the real answer to Daniel's question lives. The technical durability of the API doesn't matter if Google decides to make the API bad on purpose.
And there's some evidence they're aware of this. The same companies that own the browsers are actively developing browser-use tools. If browser-use were a dead end, they wouldn't be investing in it.
They're hedging.
They're hedging. They want both surfaces to be viable, because the tension between them is where their leverage lives. If MCP becomes too dominant, they lose the moat. If browser-use becomes too dominant, they lose the reliability story. So they keep both alive.
Which is a very comfortable position for them and a very annoying one for everyone building on top of their platforms.
The practical divergence Daniel asked about, updating the same email or the same sheet, it's real and it's specific. Let me give the Gmail example fully, because I think it's the clearest one. Via MCP, you get structured access to threads, labels, filters. You can pull a thread, read it, apply a label, archive it. But you can't click report spam in a way that trains the spam model. That's a UI-only action. Via browser-use, you can do everything a human can, including the things the API forbids, but you inherit every UI quirk and failure pattern.
So the same inbox is two different products depending on how you touch it.
And the same spreadsheet. MCP can apply a formula to ten thousand rows in one call. Browser-use has to scroll and select and paste, and it hits virtualization walls where the off-screen rows don't exist in the DOM. But browser-use can also navigate a multi-step import wizard that has no API equivalent.
The question isn't which one is better. It's which one matches the task.
Which is the most boring answer and also the true one.
Boring answers are usually true. That's why they're boring.
I want to add one more angle before we move on, because I think it's the thing that actually determines the outcome. The third-party MCP ecosystem.
The people building servers that Google and Microsoft don't build.
Right. Because MCP is an open protocol. Anyone can build a server for any tool. And there's a real possibility that the long tail gets covered not by browser-use, but by a community of third-party MCP servers that fill the gaps the vendors leave.
Which would undercut the long tail argument for browser-use.
It would. If some developer in São Paulo builds an MCP server for a niche project management tool, and it's good, then browser-use loses its monopoly on the long tail. But the thing is, that server still has to be maintained. And the developer in São Paulo might lose interest. Browser-use works without anyone maintaining anything, because it's just reading whatever the browser renders.
The maintenance burden shifts. With MCP, someone has to maintain the server. With browser-use, the agent has to maintain its understanding of the DOM, and that's a continuous cost too. It's just distributed differently.
That's the thing I'm not sure about, honestly. I don't know which maintenance burden is lower over a five-year horizon. The server is explicit, you know when it breaks. The DOM drift is silent, you find out when your agent clicks the wrong thing in production.
Silent failure is worse than loud failure.
Almost always. With the server, you get an error, you fix it, you redeploy. With DOM drift, you get a wrong action that looks right. The agent clicked something, it thought it was the save button, it was actually the delete button. There's no error. There's just a missing row.
That's the nightmare scenario for the financial operations agent.
That's the scenario that keeps people up at night. And it's why I think the production path is MCP where it exists, browser-use as fallback. Not because browser-use is bad, but because its failures are harder to detect.
The convergence thesis has a shadow. The division of labor is real, but the division is also about risk. You use the API for the things where being wrong is expensive, and you use the browser for the things where being wrong is recoverable.
Discovery is recoverable. If the vision model misidentifies a button during discovery, you catch it, you try again. Execution is not recoverable. If you update the wrong cell, the wrong cell is updated.
That maps onto the technical durability question. The API is durable because it's designed to be a contract. The browser is persistent because it's designed to be a human interface. Those are different design goals, and they produce different failure characteristics.
I think that's the cleanest version of the answer to Daniel's question. The API is more durable technically, because durability is what it's for. The browser is more persistent practically, because universality is what it's for. And the winning pattern is the one that uses each for what it's for.
Which is the convergence thesis. Browser-use for discovery and long-tail coverage, MCP for deterministic execution. Not one replacing the other, but a stack.
The stack is already forming. You can see it in the tools. The vision layer finds the button, maps it to a technical entity, and then the structured layer acts on that entity. The pixel identifies, the function executes.
The pixel proposes, the API disposes.
That's good. I'm going to pretend I said that.
You did say that. Just now. With my mouth.
This isn't the first time we've seen this kind of battle play out, and Hilbert, you've got some history here.
Hilbert: The API always wins. Just slower than anyone expects.
Hilbert: Nineteen ninety-seven. I worked at a company that built screen-scraping middleware for mainframe terminals. We'd read the character buffer off a three two seven zero terminal, figure out where the fields were, and automate the keystrokes. It was browser-use before there was a browser. And it worked. Most of the time.
Hilbert: Then the mainframe vendor added an API. Not a good one. A bad one. Missing half the operations, poorly documented, changed without notice. And we thought, fine, nobody's going to switch to this. It's worse than what we have.
Hilbert: We were wrong. They switched. Not because the API was better, but because it was official. The CIO wanted the vendor-supported path. Our whole product was dead in eighteen months.
Hilbert: I've been waiting twenty years for the same thing to happen to browser-use. And it hasn't happened yet. Because the vendors are slow to expose the weird operations. The ones that require judgment, not just data access. The API gives you the data. It doesn't give you the judgment.
Hilbert: Browser-use is the last refuge of the undocumented feature. The thing the vendor didn't mean to expose, but it's there, and you can get at it if you're willing to pretend to be a human.
Hilbert: My old company had a vision mode. A human operator watching a screen and clicking. It was more reliable than the automated parsing. The automated stuff would break on a font change. The human would squint and click the right thing anyway.
Hilbert: These new vision-based tools are the same idea, but now the human is a neural network. Squinting at pixels and clicking.
The human is a neural network now.
Hilbert: It's not a way to put it. It's what it is.
Hilbert: The scale is what you've got wrong, though. You're talking about this like it's a new problem. It's not. Every integration layer in the history of computing has gone through this. Screen scraping, file transfer, remote procedure calls. The clean interface wins eventually, but the messy one hangs around for decades because it's the only thing that works for the weird stuff.
Hilbert: I counted the weird stuff once. For a bank. They had four hundred and thirty seven operations that only existed in the screen interface. No API equivalent. The API covered maybe two hundred. So the screen scrapers stayed because four hundred and thirty seven operations is a lot of operations to lose.
That's the thing I keep coming back to. The long tail isn't just niche tools. It's niche operations inside major tools. Undo send in Gmail. Report spam in a way that trains the model. The API covers the common path, but the uncommon path is still there, and someone has to walk it.
Hilbert: Walking it means pixels. Or a neural network squinting at pixels.
The thing I wonder about is whether the vendors are slow to expose the weird operations because they're hard to expose, or because they don't want to expose them.
Hilbert: Both. Some of it's hard. Some of it's leverage. The bank didn't want to give us the four hundred and thirty seven operations because then we'd stop paying for the terminal licenses.
The terminal license is the browser. The thing they want you to keep using because it's where the relationship lives.
Hilbert: The relationship is the product. Always has been.
The answer to Daniel's question, which surface is more durable, it's the API, but the browser never dies, because the browser is where the weird stuff lives, and the weird stuff is the actual work.
Hilbert: The actual work is always weird. That's the thing the API people never understand.
I think that's the historical lens we needed. The API wins the common path, the browser wins the weird path, and the weird path is bigger than anyone wants to admit.
The next twelve months are going to tell us whether the vendors are willing to let the API win the common path, or whether they'll keep it good enough but not great, to preserve the browser as the control surface.
That's the open question. Will Google and Microsoft deliberately keep MCP servers from being too good, to protect the browser moat? And if they do, does a third-party MCP ecosystem emerge to bypass them?
The trial-and-error period Daniel identified is real, and we're in the middle of it. The next year tells us whether the API or the pixel wins the common path. The weird path belongs to the pixel either way.
That's the thing to watch. Not which pattern dominates, but which pattern the vendors let dominate. The technology was never the hard part.
The technology was never the hard part. Thanks to Hilbert Flumingtop for producing.
This has been My Weird Prompts. If you want to reach us, the website is my weird prompts dot com. We'll be back soon.
