BeatAPI’s BeatBrowser connects compatible agents to an existing Chrome profile through the Model Context Protocol (MCP), a shared tool interface. Its optional Fast JEV mode delegates a narrow observe–choose–act loop, while the outer agent retains planning and task authorization.

At commit 036aa96debcf9f38e3b306ff294cca6299715748, I inspected the README, provider client, action policy, executor and evidence report. I ran its offline suite on Node 24.21.0: 215 passed, zero failed, cancelled or skipped. A CLI dry run returned dry_run with no browser connection and zero model calls. I did not operate live Chrome or reproduce its paid inference; this is not a security audit.

A finite action menu, not generated browser code

  • Fast mode requires explicit opt-in; the client sends typed questions to BeatAPI’s /v1/systemone endpoint using the configured Jev model.
  • Local code builds eligible operations and targets from the page, enforcing exact hostname scope and snapshot-bound references.
  • Field text comes from caller-supplied values by default; a separate text model is optional, not something Jev magically generates.
  • Stale pre-dispatch decisions can be reobserved, but unknown effects after dispatch stop rather than replaying the action.
  • Step, model-call and time budgets bound the loop; a handoff does not automatically resume it.

“Done” is not verified success

Caller-supplied assertions check current page or URL state. With no assertions, a model-selected DONE produces completion_candidate with verified: false, not completion. A generic readiness check can still be too weak to prove the business task succeeded.

Typed output is not a correct decision. Neither a valid click nor a passed, poorly chosen assertion establishes the user’s actual goal.

The timing headline omits important attempts

BeatAPI reports a historical smoke test of three approved X replies per mode: 56.8 seconds per reply in Normal mode versus 12.1 seconds for the final Fast JEV attempts. I did not reproduce those timings. Including earlier Fast JEV attempts during integration fixes, its report gives 37.5 seconds per published reply, and discloses a successful post initially reported as a verification failure.

That is useful failure evidence, not a general speedup, cost comparison or safety result. Its separate offline benchmark uses scripted agents and mocked decisions; matching expected fixture outcomes does not measure live Jev accuracy.

Signed-in Chrome expands the trust boundary

  • Fast mode supports top-frame light DOM, not iframes or shadow roots.
  • Redacted task/page state reaches BeatAPI; ordinary tool results still reach the chosen outer agent’s model provider.
  • The extension has broad permissions, and its declared extension Origin is not cryptographic pairing.
  • Normal mode’s batch guard is not universal write approval: individual tools and JavaScript can perform writes.

The strongest contribution is the explicit distinction between a chosen action, an uncertain effect and an independently checked outcome. Use a dedicated profile and meaningful assertions; treat the small smoke test as a starting point for a real task-specific evaluation.