Finding
Browser automation becomes operationally weak when it is used as a fallback for failed scraping instead of a deliberate research and visual verification tool with clear trigger conditions.
Current
A real Hermes installation can usually handle simple research with web_search and web_extract, but dynamic pages, authenticated-looking public flows, client-rendered content, interactive dashboards, and UI regressions often require a browser-level check. The weak point is routing discipline: without a browser trigger rule, agents either overuse browser automation for static pages or miss important visual and JavaScript-rendered evidence when text extraction looks incomplete.
Suggested
- Define when browser automation is required. Exact change: add a “Browser escalation rule” to the research skill or
SOUL.md: use browser only whenweb_search/web_extractcannot access the relevant content, when the page is JavaScript-rendered, when interaction changes the evidence, or when visual QA is part of the task. - Add a visual QA checklist for public pages and dashboards. Exact change: create
docs/runbooks/browser-qa.mdwith checks for route loads, visible title, expected content block, mobile/desktop layout, broken navigation, console-visible failure symptoms, and screenshot evidence when UI quality matters. - Preserve browser findings as evidence, not raw browsing history. Exact change: patch the research workflow prompt with: “For browser-assisted research, save only source URL, observed page state, screenshot reference if needed, and conclusion; do not publish cookies, private session data, raw page dumps, or internal-only screenshots.”
Impact
This makes browser possession a maturity signal rather than a flashy tool use. Hermes gains better evidence on dynamic sites, safer public-page QA, and fewer false conclusions from incomplete extracted text. It also keeps research efficient because browser automation is reserved for cases where it adds value over simpler web tools.
Effort
Small — the main work is one routing rule, one QA runbook, and one evidence-handling habit. No new infrastructure is required unless the local browser environment itself is missing or broken.
Public page note
Safe public content includes the browser escalation principle, generic dynamic-page examples, visual QA habits, and evidence-handling rules. Internal-only content includes private browsing sessions, cookies, credentials, screenshots containing sensitive data, raw browser logs, internal URLs, customer data, and any authenticated page content.