Agents

jawb is built for machines to read, act on, and see the web, not for people to look at it — the whole point is being the browser an agent calls into, not one a human drives.

What an agent gets today

1. Observe and read. Call jawb observe or jawb read to get a compact, stable-ID element list or Markdown/text/JSON content instead of raw HTML or a screenshot. Fewer tokens in for the model to decide what to do next.
2. Act. click, fill, type, select, check/uncheck, press, hover, scroll, upload, download, submit, and media play/pause — targeted by the same element IDs observe returned, with automatic retargeting if the page rebuilds the node in between. Every action returns a compact diff, not a full re-read.
3. See. viewport, emulate, and screenshot for how a page renders at a given size, color scheme, or locale.
4. JavaScript-rendered content. --js on observe/read, and every Act/See command, run through the compatibility bridge (a real, locally installed Chrome/Chromium) rather than jawb's own native parser.
5. Discover tools. If the page declares WebMCP tools, jawb tools lists their names and descriptions. jawb does not invoke them yet.
6. Diff, don't re-read. Every observation and action carries a revision-scoped diff, so checking "did anything change" costs a fraction of the first look.
7. A policy and confirmation layer. Uploads, downloads, password fields, and form submits are confirmable and can be pre-approved with --yes. Classified purchase-like actions (buying, subscribing, placing an order) use a stricter human-confirmation flow: jawb holds the action, issues no approval token to the agent, and waits for a person to type purchase in their own terminal. --yes never satisfies it.
   Know its limits before you rely on it. It is a safeguard for honest checkout flows, not a guarantee against a hostile page, and a page can still disguise a purchase. The approval credential is a file in the data directory, so a program running as you can still approve until an OS-mediated approval exists. Treat the hold as a guard for a well-behaved agent, not as protection against a prompt-injected one. See Security and trust.

What an agent does not get yet

• Tool invocation. Calling the tools a site declares, behind the same policy checks as a click, is planned. Today jawb only lists them.
• An MCP server in a release. jawb mcp, an MCP server over the same API, is built and ships in the next release. Until then, agents reach jawb through the CLI or its local HTTP API.
• Routing. jawb does not choose a route for you: the command you run decides whether a step runs natively or on the Chrome bridge. A router that picks the cheapest route that works is planned.
• Workflow recording or replay. Recording a sequence of steps once and replaying it without new model calls is planned, not built.
• Content-integrity guardrails. Flagging text a person would not see (hidden, off-screen, zero-width Unicode) and labelling page content as untrusted is planned. Until then, treat everything jawb returns from a page as untrusted input to your model.
• Native execution of Act/See. Today they run on the Chromium bridge; a jawb-native engine for them is future work.
• An approval the agent cannot drive. The purchase-confirmation flow today relies on an interactive terminal and a file-based credential. The desktop app in development adds an Approvals screen, but it uses the same credential file, so it is not a stronger check. An OS-mediated approval the agent cannot drive is planned.

Where to start

Getting started walks through installing jawb and running your first observation. Add --json for machine-readable output. If you're automating jawb from Rust, start with the Rust SDK instead of shelling out to the CLI.