agentrhq/webcmd

Every time an agent visits a website it hasn't seen before, it burns tokens figuring out the navigation, the forms, the quirks. Webcmd attacks that waste directly by treating browser knowledge as something worth caching and compiling, not rediscovering on every run.

The architecture is a four-layer stack. At the bottom sits live Playwright-style browser control - raw exploration when a site is genuinely unfamiliar. Above that, the tool builds a sitemap memory: a structured record of observed pages, states, actions, workflows, APIs, pitfalls, and fallback paths. Once that map exists, a developer or agent can author a reusable CLI adapter for that site, so future agents spend their token budget on the actual task rather than on navigation. The final layer extends those adapters with tailored commands for workflows deterministic enough that no browsing is needed at all. The claimed payoff is up to 90% reduction in browser-agent token spend.

The session model is worth noting. Sessions are independent browser windows within a profile, and profiles are cookie jars - so a logged-in work or social profile persists authentication across runs. Parallel agents get separate sessions; adapter commands default to an adapter-level session unless explicitly routed elsewhere. The CLI syntax for this is clean: create a session, pipe JavaScript to it, close it.

Plugin distribution is npm-based. The core package ships without any site adapters; you search a plugin catalog and install what you need. Community plugins already cover Hacker News, Stack Overflow, GitHub, arXiv, PyPI, Skyscanner, and a handful of others. The plugin surface is intentionally open - the README describes a publish path for community contributions.

The X-to-CLI walkthrough in the README is the clearest illustration of the value proposition. An agent explores the X bookmarks workflow once using a logged-in profile, then crystallizes that exploration into a stable command. Subsequent agents skip the browser entirely and just run the command. That's the loop the whole system is built around: explore once, compile, reuse.

What's missing from the README is any honest accounting of how the sitemap memory is built or stored, how adapter authoring actually works under the hood, or what happens when a site changes its layout and invalidates a compiled adapter. The cloud offering is flagged as unstable and not yet ready. For a tool whose core promise is reliability through determinism, those gaps matter - the README is long on the concept and short on the mechanism.