If you have ever tried to automate a modern web app, you know the pain. You spin up Playwright or Puppeteer, inspect network requests, write CSS selectors, wrangle cookies, and hope the layout does not shift next week. It always shifts. Then you are back in the DevTools panel, patching selectors at 11pm.
What if you never wrote the browser code at all?
That is the pitch behind Webcmd, an agent runtime that turns websites, logged-in dashboards, APIs, and browser sessions into deterministic CLIs. You hand an AI agent a goal. The agent crawls the target, works out the UI and browser state, finds the useful requests, and packages all of it into a repeatable command. You get a stable CLI instead of a pile of selectors.
Here is how to build one, start to finish, without touching Playwright.
TL;DR
- Install Webcmd where your coding agent can run a shell (
npm install -g @agentrhq/webcmd, Node.js 20+). - Instead of writing selectors, you write a plain-language prompt describing the command you want.
- The agent explores the site, picks a strategy, and generates a verified adapter.
- Logged-in sites use named profiles, so credentials never end up in code.
- When a site changes, you ask the agent to heal the command instead of rewriting it yourself.
1. Install Webcmd
Webcmd runs wherever your coding agent has shell access. It needs Node.js 20 or newer.
npm install -g @agentrhq/webcmd
Before you ask an agent to build anything, check the local runtime, daemon, and browser bridge:
webcmd doctor
If doctor is green, your agent has everything it needs to explore a site and write a command.
2. The "coding" part: prompting the agent
Here is the mental shift. You do not write Playwright selectors. You write a plain-language prompt, and your AI coding assistant crawls, implements, and verifies an adapter (the code that turns a surface into one or more commands).
Example 1: a public scraper
Say you want to scrape job listings. You never open DevTools to find the DOM. You describe the command:
Create a Webcmd CLI for example.com job search. I want:
- command: webcmd example jobs
- input: search query and optional location
- output: title, company, location, salary_text, posted_at, url
- format: JSON-friendly rows
Keep it as a private adapter and verify it with a smoke test.
The agent explores the site, picks the best strategy (PUBLIC for open pages, UI when it has to drive the live page), and writes the adapter. You review a command, not a wall of selectors.
Example 2: logged-in workflows
Authentication is where traditional browser automation gets ugly. Webcmd handles it with profiles, which keep browser identities and login state separate from the adapter code.
To automate a dashboard behind a login, point the agent at a profile:
Build a Webcmd adapter for the logged-in Acme dashboard that lists invoices. Use my `work` browser profile. Return invoice_id, customer, due_date, amount, status, and detail_url. Do not store credentials in code. If I need to sign in, pause and ask me to.
The login lives in the profile, not the command. That one detail is the difference between a demo and something you would run against a real account.
3. Using your new command
Once the agent finishes the exploratory work, you have a stable, deterministic CLI. You (or other agents) call it directly, no browser required:
webcmd acme invoices --format json
Because the output is structured JSON, this command becomes a reliable building block. Pipe it into a cron job, a data pipeline, or another agent, and it behaves the same way every run.
4. Healing broken commands
The real payoff shows up in maintenance. A site updates its UI or renames an API field, and your automation stops working. With a hardcoded Playwright script, that means diffing the new DOM by hand.
With Webcmd, you ask the agent to fix it:
The command `webcmd acme invoices` used to work but now returns empty rows. Diagnose it, repair the adapter, run verification, and explain what changed. Keep the output schema unchanged.
The agent uses Webcmd tracing and browser tooling to find what moved (selectors, API fields, or auth behavior), patches the adapter, and gets the CLI green again. Your downstream scripts never see the change, because the output schema stays fixed.
The takeaway
Traditional browser automation makes you the maintenance crew for every site you touch. Webcmd moves that burden to an agent: it explores once, freezes the result into a command, and repairs the command when the site drifts. You stop babysitting selectors and start working with structured, reliable data.
If you want to try it, the Webcmd quickstart walks through install, webcmd doctor, and your first agent-authored command in a few minutes.
Have you moved any of your Playwright scripts over to an agent runtime yet? I would like to hear what broke and what stuck. Drop a comment.
Top comments (1)
If you're building browser agents, what has been the biggest pain point for you? Playwright selectors? Authentication? CAPTCHA? Curious what everyone is running into.