Most browser automation examples start with selectors. Find the button, identify the input, write the script, and hope the page does not change before the next run.
That approach works, but it becomes awkward when a site requires real browser interaction. Some information only appears after a click. Some pages run browser checks. And if the agent is running on a remote server, even launching and maintaining a local browser can become a project of its own.
In this walkthrough, I connected an agent to a Zyte CDP browser through Playwright CLI and gave it instructions in plain language. The interesting part was not simply connecting to a remote browser. It was seeing what the agent could do once it had access to a real, interactive browser session.
Video timestamps are included throughout this post.
The setup: a short instruction file and Playwright CLI [00:18]
I started with a small Markdown file that explains how the agent should use the Zyte CDP browser with Playwright CLI. It tells the agent to make sure Playwright CLI is installed and meets the required version, then gives it the basic connection instructions.
This creates a simple bridge between the agent and the browser. Once the browser is connected, the agent can use the operations available through Playwright CLI: opening pages, finding fields, clicking buttons, entering text, and reading the resulting page.
The difference is that I do not have to write a separate Playwright script for every interaction. I can describe the task and let the agent work out how to perform it on the page.
A deliberately interactive demo site [00:39]
The demo website is intentionally simple. It contains categories, a search box, product controls, and several buttons. It also includes a browser check, which appears briefly when the page loads.
The site has a useful interaction flow:
- Search for products.
- Select products.
- Click a compare button.
- Read the comparison table that appears.
- Open an individual product page.
- Click a button to check availability.
Some of this information might be available through Ajax requests or an underlying API. In a real project, it can be worth investigating those options. But there are also cases where the most reliable path is to use the website as a user would and click through the interface.
That is where a browser-connected agent becomes useful.
Replacing selector work with instructions [01:13]
The traditional Playwright workflow requires you to inspect the page and choose selectors. You need to work out which element is the search field, which button triggers comparison, and which part of the page contains the result.
With the agent, the instruction can be much closer to the actual task:
Go to the website, search for “brake”, and return the products you find.
The agent can inspect the page, locate the relevant field, enter the search term, and read the results. It is still using selectors under the hood, but you do not have to discover and maintain those selectors yourself for each request.
This is especially useful when the task changes from run to run. The instruction can describe the outcome rather than encoding every click in a fixed script.
Connecting the agent securely [01:28]
For the demonstration, I used OpenCode with DeepSeek Flash through OpenRouter. This task does not require a large amount of reasoning. The agent mainly needs to follow the browser instructions and carry out a sequence of actions, so a relatively inexpensive model is enough.
The connection also needs authentication. The API key is read from an environment variable and used to create a short-lived configuration file in a temporary location. That file is passed to Playwright CLI when it connects to the browser.
The important practice here is to keep the key out of the instruction file and out of the agent’s visible working material. The connection configuration should be created securely and cleaned up according to the needs of the environment.
After that, the agent can use the browser through Playwright CLI.
Searching without writing selectors [03:02]
The first task was simple: open the site and search for “brake”.
The agent found the search bar, entered the term, and returned the matching products. During the process, Playwright CLI reported the elements it found and the actions it took. The model was verbose, but the important result was that no custom selector script was needed.
The same approach works when the page is more complicated than the demo. You can describe the field or action in terms a user would understand, and the agent can inspect the current page before deciding what to interact with.
Using the site’s compare feature [04:07]
Next, I asked the agent to take the top three products, use the website’s compare feature, and return the comparison table.
This matters because the table does not appear until the products have been selected and the compare action has been triggered. It is not simply a block of data sitting in the initial HTML.
The agent had to find the product controls, select the relevant items, click the compare button, and read the table that appeared below the results. Again, the instruction described the goal rather than the selectors:
For the top three products, use the website’s compare feature and return the table it shows.
The example is deliberately basic, and the same information might have been available elsewhere on this particular site. The point is to demonstrate the interaction pattern. Once the agent has a browser, it can perform actions that depend on the page’s state and then collect the result.
Checking availability on each product page [05:13]
I then asked the agent to visit each product page and retrieve the availability information.
The product pages include a “check availability” button. The agent can follow the product information it already collected, open each page, find that button, click it, and return the availability result.
This is the kind of task that can become a collection of small scripts when written manually. The agent can handle the sequence from a single higher-level instruction, provided the task is clear and the browser session remains available.
Why use a remote browser? [05:48]
If Playwright can launch a browser locally, why connect to a remote one?
The two main reasons are access and maintenance.
Access to sites that expect a real browser
Some sites do not respond well to a basic automation setup. They may perform browser checks or apply other forms of traffic protection. In the demo, the site was configured so that a standard Playwright launch would not get access, while the remote browser could connect successfully.
There are open-source stealth browser options, and some of them work well. But they need to be maintained. Browser behavior changes, sites change their checks, and the tools need to keep up.
Less local infrastructure to maintain
Running a browser locally can also create deployment work. An agent may be running on a server without a display, which means you may need a virtual display such as Xvfb. Then there is the browser installation, version management, operating system configuration, and the rest of the environment around it.
None of these problems is impossible to solve. They are just extra moving parts, and every extra moving part is another thing that can fail in an agentic workflow.
A remote browser moves much of that browser infrastructure outside the agent’s environment. The agent only needs to connect, perform the work, collect the result, and disconnect.
Session limits and closing the connection [02:28, 07:34]
The browser session in the demonstration lasted five minutes. That limit is important for two reasons: the agent needs enough time to finish its work, and the connection should be closed as soon as the work is complete.
When I spent too long talking through the demonstration, the session expired. The agent reconnected and continued with the task, but this is a useful reminder to design the workflow around short, purposeful sessions.
In a production-style flow, the agent might receive one instruction, connect to the Zyte CDP browser, complete the interaction, return the data, and close the browser. Closing the connection ends the session and avoids paying for unnecessary additional browser time.
This cleanup step should be part of the instructions or application logic, not something left to chance.
The larger idea
The real benefit here is not that an agent can click a few buttons on a demo site. It is that browser automation can be expressed in terms of the work you want done:
- Search for a product.
- Compare the first three results.
- Visit each product page.
- Check availability.
- Return the results.
The agent still needs a browser automation tool, authentication, sensible session limits, and clear instructions. But you do not have to begin by turning every task into a collection of selectors and hard-coded steps.
That makes a remote CDP browser a useful option for agentic web interaction, especially when a site requires clicks, state changes, browser checks, or other behavior that a simple scraping request cannot reproduce.
The instructional Markdown file and the browser CDP resources used in the demonstration are linked below the video. If you are experimenting with browser-connected agents, this is a straightforward pattern to try: give the agent a small set of browser instructions, let it act on the page, and make sure it closes the connection when the job is done.
Zyte CDP browser documentation:
https://docs.zyte.com/zyte-api/usage/cdp.html
Zyte headless browser:
https://www.zyte.com/zyte-api/headless-browser/
Instruction Markdown file:
https://raw.githubusercontent.com/zytelabs/zyte-cdp-examples/refs/heads/main/agent-onboard.md