APIs are delegation. Browser automation is impersonation.

Cristiano Sacchi

Heurivon Blog Post

APIs are delegation. Browser automation is impersonation.

Yesterday Amazon blocked Meta's Muse agent from its retail site. Muse launched on September 8th... so that's about two weeks.

I'm not writing this to pile on Meta. Muse is a serious product, and it topped the US charts with over 900,000 downloads in six days. I'm writing it because this was predictable. Not "Meta got unlucky" predictable. Structural predictable. And if you're about to pay for an AI assistant to run parts of your business, it's worth knowing why.

Two ways for an agent to get in

An AI agent can reach a service like Amazon, your bank or your CRM in one of two ways.

Through an API. The service publishes a door for software. You give the agent a key. The service knows it's software, knows who it's working for, and decided ahead of time what that software may do. That's delegation. You hand over a specific task, the counterparty agrees, and everyone knows who is who.

Through the browser. The agent opens the website, reads the screen, clicks the buttons and types into the boxes... pretending to be you. The service thinks a human is there. That's impersonation. Maybe benign, maybe well-meant, but impersonation.

This isn't a technical detail. It decides whether the thing keeps working.

One is a partnership, the other is an arms race

With an API, both sides want it to work. The service built the door because it wants the traffic, the integrations, the ecosystem. If it breaks, somebody on their side gets paged.

With browser automation, the other side is trying to stop you. Not by accident... that's their job. They have bot detection, CAPTCHAs, rate limits, lawyers. And they have good reasons: the agent skips their ads, their recommendations, their upsell, their whole relationship with the customer. Amazon doesn't want a Meta product standing between it and its shoppers. Why would it?

So each improvement to the agent gets met by an improvement in the blocking. Better models don't end that. They escalate it. As an engineer I am always concerned about reliability, and something that may not just accidentally break, but that is bound to break, is just asking for trouble.

Muse also isn't the first. Amazon sued Perplexity over its Comet shopping agent last November, won a court order blocking it in March (Perplexity has since won on appeal, and the fight continues), and has been shutting out ChatGPT's bots too. The pattern holds: the counterparty controls the door and closes it when it wants to.

The part nobody talks about: permissions

There's a second problem, and for a business it matters more.

When I connect an agent to QuickBooks through its API, I get a scoped token. That's a written list of what the agent may touch: read invoices, yes; delete the company, no. I can revoke it tomorrow. The boundary is declared, and the service enforces it, not the agent.

When an agent drives your browser while you're logged in, it can do anything you can do. Every button you can click, it can click. There's no list and no scope. The only thing between the agent and "wire the money" is the agent deciding not to.

Would you give a new hire unfettered access to your workstation on day one, or would you give them their own account with limited access? That's the whole difference.

And there's one more drawback that's easy to forget: a screen agent needs a screen. Somewhere, a real or virtual desktop has to be running, logged in, with a browser open, for as long as the agent works. That's more infrastructure to run, pay for... and secure. If the session lives on your own machine, it has to stay on and unlocked while the agent works, and anyone walking by can watch what it's doing, or take over. An API call doesn't need a desktop at all.

What we decided, and what it cost

Heurivon only goes through APIs. Gmail, Calendar, Shopify, QuickBooks, HubSpot, Slack, GitHub, Duffel for travel. Each one is a door the other side built on purpose.

The cost is real, and I won't pretend otherwise: if a service has no API, we can't touch it. Whether it is a game or a government portal, if it has no API, it is meant for humans and not for automation. A browser agent could at least try. We can't. Some users will find that frustrating, and some competitors will demo things we can't.

I made that trade anyway, because serious work requires maximum reliability and speed. APIs are not just more reliable, they offer full access to the scoped features without sifting through menus, and buttons, and forms... I believe that anthropomorphic AI is super cool, but it is not just error-prone, it is not operating in the correct context. Computer networks do not call each other describing transmitted data in plain English... they encode it into binary for reliability and speed. Humans are best at interacting with humans, not at interacting with everything.

Browser automation won't die. It will narrow.

To be fair: computer use works, sometimes impressively. I watched one agent take 17 steps and 7 minutes to generate a single image through Bing... and it got there, with no integration at all. That's remarkable.

But "works sometimes, against a site that doesn't want you there" is a narrow niche, not a foundation. My bet is that browser agents end up where voice assistants did: very useful in the small set of cases where they're reliable, and quietly dropped everywhere else. More on that in a future post.

Three questions to ask before you buy an AI assistant

If you run a small firm and you're looking at these tools, ask the vendor:

  1. "For each service you connect to, is it an API or the browser?" If it's the browser, expect it to break, maybe in two weeks.
  2. "What exactly can the agent do in my account?" A good answer is a list. A bad answer is "whatever you can do."
  3. "How do I revoke it?" It should be one click, per service, without changing your password.

If the answers are vague, the product is impersonating you. Maybe carefully, maybe with good intentions... but impersonating you.

— Cris