Explore with an agent, repeat with a script

Once you're driving a real browser, there are two ways to actually do it, and picking the wrong one is where the time goes. One is live: an agent looks at the page and reacts, action by action. The other is a script: the steps are written once and run on command. They're for different moments.

This part absorbs an earlier guide I had comparing the two, and sets them next to the rest of the surfaces.

Live: an agent that sees the page

An agent drives the browser one action at a time. Before it acts, it takes a snapshot: a structured map of the page, its accessibility tree, with a handle on every button, field, and link. So it can say "fill the search box" and "click Create" without brittle CSS selectors or guessing whether a field is an input or a textarea. The snapshot handles scrolling, controlled inputs, and visibility on its own.

This is the tool for figuring a site out: exploring, debugging, reacting to whatever the page does. It's also how you discover the steps you'll later put in a script.

The cost is tokens. Each snapshot goes into the agent's context, and a long, multi-step task adds up. For interactive work that's a fair trade, because the snapshot prevents the blind-guessing failures that cost far more than the tokens do. Don't avoid it to save tokens.

Scripted: steps written once

The other way is a script: the browser steps live in code and run with one command. Twenty actions, one call, nothing streaming into context. This is the tool for a flow you already understand and will run again unchanged: pulling a list of pages, submitting the same form, a job on a schedule.

The catch is that without the live snapshot you're writing selectors blind, and pages resist. Frameworks intercept typed input so a value looks set but the app never sees it. Elements sit below the fold and need scrolling into view first. Single-page apps render hidden duplicate copies of the same element. Debugging those blind can burn more time than the live agent would have. A script earns its keep once it's built and stable, not on the first attempt.

The handoff

Here's the move that makes both worth it. Explore once with the agent to discover the flow, then bake the working steps into a script and run the script from then on. When the site changes and the script breaks, go back to the live agent to find what moved, fix the selectors, and update the script.

Explore with the one that can see. Repeat with the one that's cheap. That handoff is the point.

The token math backs it up: practitioners who've measured it report the scripted path costing several times fewer tokens than the live path for the same known task. The word doing the work is "known." The savings are real only once the flow is stable, so for a task you'll run once, the live agent is usually the better deal anyway.

When to reach for which

Use the live agent for an unfamiliar site, a one-off, debugging, or building a script. Use a script for a stable flow you'll run again. Most real work uses both, in that order.

Next up, Part 4: when you want the agent in your own everyday browser, with your real logins, while you watch.

Sources

• The case for scripting a known flow to cut token cost traces back to a conversation with a developer I trust.