Building Browser Agents That Actually Work: CLI, CDP, and the Sense-Act-Verify Loop

I've been building browser-driving AI agents for a while, and most of the failures I've hit come down to the same root cause: the agent doesn't actually know whether its last action worked. Here's the engineering pattern I've settled on, and why it holds up better than the obvious approach.

CLI Beats MCP for This Job

My first instinct with any agent tool was to wrap it as an MCP server. For browser automation specifically, I've moved away from that, and the data backs it up. A study from Arize AI found that a CLI-based approach and an MCP-based approach succeed at the same tasks about equally often, roughly 83% of the time either way. Capability isn't the differentiator.

Reuse, speed, and cost are. A CLI (shell-based tool calls) can be scripted once and replayed a thousand times without a model in the loop. An MCP server puts the model on every single turn. In that same study, the MCP approach took 71 round trips and about 8 minutes for a task the CLI approach finished in 7 turns, under a minute. Anthropic has separately reported CLI-based tool use running up to 75x cheaper in token cost for comparable work. If your agent is going to run a routine more than once, that difference compounds fast.

Drive the Browser Through CDP, Not a Wrapper Library

The Chrome DevTools Protocol is the same protocol behind the panel that opens when you hit F12. Driving a browser directly through CDP, instead of a higher-level automation library, means your agent's clicks and keystrokes take the same path through the browser that yours would. That matters less for evasion and more for reliability: fewer abstraction layers between "the agent decided to click" and "the click actually happened" means fewer places for things to silently go wrong.

CDP is enormous, dozens of domains and hundreds of methods, but you only need a handful of them, and it helps to think of them as your agent's senses:

• See the page: read the DOM, read the accessibility tree, or take a screenshot when you need actual pixels.
• Hear the page: watch network traffic, console output, and logs.
• Act on the page: click, type, navigate.

The Loop That Actually Makes This Reliable

The pattern I use for every action is: sense, act, verify. Perceive the page state through one of those channels, take exactly one action, then verify through a different channel than the one you acted through. If you clicked something, don't ask the click whether it worked, check the network request it should have triggered, or check what's now on screen. Then sense again and repeat.

This one habit, verifying through a different channel than you acted through, has fixed more of my agent's silent failures than anything else. Agents that only check "did the click function return successfully" miss the cases where the click technically fired but nothing actually happened.

A Real Use Case: Personalized Email at Scale

Here's where this actually paid off for me. I needed to send a batch of personalized emails through a web-based Outlook client. There's a real API for this, but in a lot of corporate environments, the Office 365 API requires an app registration and admin approval that a regular employee often can't get. The web login I already had access to was enough to do everything I needed by driving the interface directly.

Since there was nothing actively fighting the automation here, this was the simple case: a scripted sequence opens the compose window, fills it in, and sends it, looped once per recipient. I capture the sequence once and reuse it for 20 emails or 200 without touching it again. The agent's actual job in this flow is just writing the personalized content, the interaction itself is a program, not a model decision on every click.

The Real Takeaway

The specific tools matter less than the discipline: give the agent something scriptable instead of paying model costs on every turn, drive the interface at the lowest level that's reliable, and verify every action through an independent channel instead of trusting that it worked. Once you've worked out a sequence by hand, write it down, as code, or as a reusable skill, so you never have to solve it again. That's the difference between an agent that occasionally works and one you can actually put into a real workflow.