Web QA
Use governed runs for repeatable browser checks, visual verification, and regression evidence.
browser automation · web apps
Browser agents need evidence, not blind clicks.
Muster routes browser and web-app work through setup checks, scoped memory, token receipts, MCP/browser tools, and eval-backed workflows so automation can be reviewed and repeated.
Browser work
Built for web QA, app operators, and enterprise workflows.
Enterprise web apps
Keep app actions behind setup and policy instead of letting a model click without context.
Scoped state
Browser facts can be remembered by tenant, workspace, user, and session instead of global history.
Token and run receipts
Every browser-assisted answer stays visible in the same run ledger.
In practice
A browser agent that cannot show its work is a liability.
Browser automation is the highest-consequence thing most teams let an agent do. A wrong answer in chat is embarrassing; a wrong click in an admin console changes state in a system of record, often with no undo. The difference between a browser agent that is useful and one that is a liability is not model quality. It is whether anyone can reconstruct what it did.
Evidence first, autonomy second
The useful ordering is to make a run reviewable before making it autonomous. That means setup checks that fail loudly when a credential or a target environment is missing, rather than a session that half-works and produces plausible nonsense. It means capturing what the run saw and did as artifacts you can look at afterwards. And it means the run being repeatable — if a check cannot be run again next week and produce a comparable result, it is a demo, not a test.
Where scoped memory earns its keep
Browser work accumulates exactly the kind of facts that should not be global: which environment a tenant uses, which selector on which internal app, which login belongs to which customer. Muster keeps those in lanes — tenant, workspace, user, role, session — with recall filtered by entitlement at retrieval time. A fact learned while working one customer's console does not surface while working another's, which is the failure that turns a helpful automation into an incident report.
The ledger, because browser runs are long
Browser tasks produce a lot of context: page text, DOM fragments, screenshots described back into the conversation. Replayed naively every turn, that context dominates the token bill. Every run records usage, estimated cost, and a replay-waste flag locally. The deterministic benchmark shows the general effect across five scenarios and 170 turns — 875.8k naive tokens versus 355.2k, a 59.4% reduction — and the pattern is most pronounced exactly where browser work sits, on the longest threads.
When the browser run also edits a repository
Web QA and app-operator work frequently ends with a code change. That is where the audit story stops being abstract: measured live across five runs against the Codex app-server protocol, the structured file-change notification reported zero of the real edits while every one of them landed on disk. Muster derives the change set from git and the filesystem instead, catching the edit in 86ms with a diff verified by git apply and a receipt hash that reproduces on a machine that was never there.
Tool access — browser control, MCP servers, custom capabilities — stays behind explicit include and exclude policy with result caps and circuit breakers, so an agent operating a web app is working inside a declared boundary rather than whatever it can reach.
See the observed file-change evidence -> MCP tool policy -> Read the docs ->