What browser automation actually is
A headless browser signed into your account, clicking pages and parsing HTML. It is genuinely general — anything a human can do in the interface, it can attempt. That is its appeal and the source of every problem: it depends on the interface staying exactly as it was, on the session surviving, and on the traffic not looking like what it is.
It breaks on Tuesday
A selector changes, a modal appears, a consent banner moves, and the automation silently does the wrong thing — or nothing, which is worse when nobody is watching. Protocol-level access does not have that failure mode: the shape of a conversation object does not change because a designer moved a button.
The account carries the consequence
Platforms look for the rhythm of automated browsing, and the penalty lands on the account, not on the tool. A restriction on a LinkedIn account used for work is not an incident you roll back. Pacing applied before a request leaves — serialized calls, a daily budget, spaced new conversations — is a different posture from discovering the limit by being throttled.
Structured results versus scraped text
A browser returns a page; an agent then has to guess which text was the sender and which was a timestamp. A tool returns a conversation with its identifiers, so the next action can use them. That is what makes multi-step work possible: resolve a person, find the conversation, read it, answer in it — each step feeding the next instead of re-parsing a screen.
Errors you can act on
A browser failure is a screenshot and a timeout. A structured error says what was wrong and which tool to call again: a stale conversation id, an account to reconnect, a daily limit reached. An agent can recover from the second kind on its own; the first kind needs a human reading logs.
Where browser automation still wins
For an interface with no API and no protocol behind it — an internal tool, a supplier’s portal, an old admin panel — a browser agent is the only option, and it is the right one. The argument here is narrow: for the accounts a person owns on major platforms, driving a browser is the expensive way to get a fragile version of what a protocol already offers.
“Read my LinkedIn conversation with Ada and draft a follow-up.”
“Who do I already know at this company?”
Common questions
Is browser automation against the rules?
Platforms treat automated browsing of a logged-in session as something to detect and restrict. The account bears the penalty, which is the practical problem regardless of how the terms read.
Is MCP slower?
The opposite in practice: no page to render, no waiting for elements. What it adds is deliberate pacing, because the limit that matters is the account’s tolerance, not the API’s speed.
Can MCP do everything a browser can?
No. It covers what the protocol exposes, which for messaging, search, invitations, email and calendars is the useful part. An obscure interface-only setting may not be reachable, and that is an honest trade.
What about an internal tool with no API?
That is where a browser agent belongs. The two approaches are complementary; the mistake is using a browser for accounts that have a protocol.
Related guides
Give Nilyo to your agent.
Paste one setup link. Your agent can guide OAuth, account connection and the first useful action.