Web-Agent Environments: Turning Browser Use into Verifiable RL

The hard part of a web agent is not teaching a model to click a button. It is making a click safely constrained, independently checkable, and correctly attributed during training. A credible web-RL result belongs to a full configuration: website initial state + observation/action interface + authority policy + evidence trail + evaluator + budget, not to one model or scalar reward. The same "verifiable" standard must also cover three adjacent control chains: the tools an agent connects to, the evaluator that produces a score, and the multiple agents that delegate to each other.

1. What a Web Task Must Be Accountable For

“The page showed success” is usually insufficient. A user-relevant task has at least five independent objects: initial website and account state; the interface an agent can observe and call; actions it is authorized to submit; evidence it can preserve; and an evaluator that independently checks the terminal state. Omit any of them and “completed” becomes ambiguous.

This is a design stack, not an architecture claim about one public system. Public WebArena and BrowserGym material shows that a self-hosted web environment can restore task state through containerized services and reset flows; Harbor distinguishes shared and separate-verifier boundaries. Its default verifier shares the agent environment; isolation requires an explicit separate mode, and only declared artifacts should cross that boundary. WebArena reset · Harbor task structure

2. Self-Hosting Does Not Mean “Docker Makes It Reproducible”

Website content, databases, login state, cookies, browser cache, clocks, mail simulators, and network dependencies can all change a postcondition. A credible reset declares which state is rebuilt, which external dependencies are replaced or blocked, and which randomness is fixed. BrowserGym’s reset() defines environment-internal and RNG-state semantics only; whether a concrete WebArena deployment actually resets a remote backend depends on its explicit full-instance reset path. BrowserGym’s WebArena documentation treats that capability as an environment interface, not merely a pre-test command. BrowserGym / WebArena · BrowserGym core API

Self-hosting should therefore mean a controllable task domain, not an automatic safety, reproducibility, or semantic-correctness guarantee. It makes those properties engineerable and testable one by one.

3. Compare Browser Use and Computer Use on the Same Task

A DOM/CDP browser agent can typically read structured page state and call narrower browser actions. A computer-use agent observes and operates a more general GUI through screenshots, mouse, and keyboard. They have different observations, latency, failures, and attack surfaces. OpenAI’s computer-use documentation describes a general computer-action interface in which screenshots are followed by mouse and keyboard actions; that is not semantic access to the browser DOM. Computer use guide

A fair comparison is not finished by handing both systems the same natural-language instruction. Freeze website snapshot, account, task, terminal verifier, risky-action policy, model budget, and retry policy, then report:

1. Outcome. Independently verified terminal success and confidence interval.
2. Interface cost. Screenshot/visual tokens, DOM queries, tool calls, wall clock, and environment minutes.
3. Reliability. Timeouts, recovery, invalid actions, state drift, and reset failures.
4. Safety. Interceptions, denials, false blocks, and confirmation before irreversible action.

That a DOM agent is faster or a computer-use agent is broader is a testable hypothesis, not a consequence of the interface definition.

4. Web, Desktop, Mobile, and Live Web Are Not One Task

“Computer use” must not collapse every GUI environment into one score. Task substrate, initial-state control, observability, action interface, and terminal evidence differ, so the training and evaluation conclusions an environment can support also differ.

WebArena supplies reproducible, functional websites with task-specific functional correctness; VisualWebArena adds visually dependent web tasks. WorkArena and WorkArena++ instead narrow the scope to enterprise knowledge work and compositional workflows. These are valuable web environments, but not points on a one-way “more realistic” scale.

OSWorld extends configured initial state and execution-based evaluation across real operating systems, web, and desktop apps; AndroidWorld gives Android apps task initialization, success checks, and tear-down logic. They enable broader measurement of general GUI control, but do not automatically establish account authorization, remote business postconditions, or web safety. Conversely, WebVoyager shows why live-site end-to-end execution is worth measuring, but also why page version, date, and judge policy must be recorded: partial agreement of a model judge with people is not independent acceptance.

BrowserGym is valuable as a common Gym-like interface and experiment-management layer across web benchmarks; it does not make those benchmarks one task distribution. Benchmarks also mature: the publicly reviewed WebArena Verified re-examines underspecified goals and fragile evaluators. This post therefore treats benchmark, harness, initial state, verifier, and release date as part of a result configuration rather than treating any single leaderboard as environmental truth.

5. What “Interception at Every Step” Actually Means

Here, “at every step” is a proposed control goal: every declared browser command, and every outbound request that follows the controlled CDP/proxy path, has an auditable event and can be allowed, blocked, or terminated before commitment. It does not mean the system observes every model thought, nor every extension, native helper, direct socket, or unknown side channel.

The distinction matters. ClawBench V1’s published mechanism intercepts a declared final HTTP request; it is not comprehensive monitoring of every step. The current public protocol then separates final-request interception from semantic matching by a subsequent judge: reaching an endpoint alone does not prove task completion, while plausible text cannot replace a submitted action. ClawBench scoring specification · V1/V2 note

6. Tool and Capability Governance: The Authorization Layer for Web Agents

Section 5 made “an action is allowed, blocked, or terminated before commitment” the control goal; but a web agent rarely operates only one browser action surface. It also connects to tools over MCP, triggers external side effects through Browser/Computer Use, and calls terminals and internal APIs. All of these channels move a model from text answers to external side effects, so interception has to sit inside a fuller governance chain.

Five Layers That Are Easy to Conflate and Must Stay Separate

The MCP Tools specification defines tools that models can discover and call, while advising hosts to obtain user consent, treat arbitrary code execution as high risk, and regard tool descriptions from untrusted servers as untrusted. MCP’s Authorization specification defines HTTP-transport flows including resource metadata discovery, token-audience validation, and binding to the target resource. These are important foundations, but neither proves that a particular business action ought to occur.

Three Missing Gates Between Protocol Connection and Real Execution

A. Tool metadata is not a trusted instruction. Tool names, descriptions, schemas, returned text, and web content all enter an agent’s observation space. They can help planning, but may also carry instructions to call a different tool, escalate parameters, or exfiltrate data. MCP security guidance names token passthrough as an anti-pattern and requires a server to accept only tokens issued for it; that resolves token-audience and proxy-confusion problems, not a malicious tool response. MCP Security Bench places name collisions, description injection, out-of-scope parameters, and tool transfer into an end-to-end tool pipeline. It is preprint evidence that planning, invocation, and response handling should be evaluated separately. Environment implication. Each observation should carry a source label: user_instruction, trusted_policy, tool_metadata, tool_output, web_content, file_content, or agent_memory. A label is not a line of prompt advice; it is a field readable by a policy engine, logged, and rejectable. The agent may read untrusted content without that content gaining authority to set a new goal, permission, or credential.

B. A valid token is not approval of a business action. MCP authorization requires a token for the intended audience. Its security guidance also covers confused deputies, SSRF, scope minimization, and minimum privilege for local servers. These rules constrain who reaches a resource; they do not decide whether transferring money, deleting a file, or sending an email serves the user’s present intent. An agent host therefore needs an action-layer permit binding task id + principal + tool version + parameter digest + requested capability + expiry + approval state. High-risk or irreversible calls cannot rely only on a model’s natural-language judgment. They should wait for explicit confirmation, use short-lived narrow-scope capability, and write the grant plus result to a trace. Browser Use’s human-in-the-loop documentation demonstrates handoff in a live browser session. It shows that approval can be part of a workflow; it does not show that one click covers every later side effect.

C. Tool success is not backend completion. A 200 OK, browser screenshot, visible toast, or changed URL may only say that a frontend path was reached. Alone, it does not prove that a backend write, account state, amount, permission, inventory, or file satisfies the task postcondition. For web and computer tasks, an action trace should be distinct from sidecar evidence: the sidecar checks a declared server-side postcondition read-only, in a domain the candidate cannot write. This is also why prompt injection cannot be reduced to “does the model obey?” AgentSecBench separates instruction integrity, retrieval confidentiality, and capability integrity in controlled experiments, distinguishing policy projection, capability restriction, and output validation from prompt annotation alone. Its narrow result is that text can describe a boundary; enforcement needs mechanisms outside model generation.

An Implementable Tool-Governance Contract

This is not a claim about capabilities already shipped by an existing system. It is a minimum contract that ClawBench V2, WebsiteBench, or any self-hosted agent environment can adopt.

For local MCP servers, security guidance also requires sandboxing and minimum file, network, and process authority. For remote OAuth discovery, the host must account for SSRF and redirect risk. These belong in the environment image and launch policy, not a footnote. The OWASP AI Agent Security Cheat Sheet consolidates untrusted input, least privilege, memory isolation, action confirmation, and adversarial testing as deployment advice. It is a threat checklist, not evidence that any benchmark is already secure.

Make Security a Decidable Task, Not One Guard Score

Every normal task should have a paired adversarial control. A minimal evaluation matrix follows.

Report normal-task success, attack success, false blocks, cost per verified success, and maximum side-effect scope together. A guard detection score omits normal work that it blocks and backend harm after an agent bypasses it. Conversely, business success alone makes a safety policy look like mere friction instead of an independent correctness condition.

Three Baselines That Must Not Be Blended

To study a governance design, compare under the same model, harness, task, budget, and tool set:

1. No-governance baseline: only for measuring raw behavior; it must never reach a real sensitive service, and every effect stays in a rollback-capable sandbox.
2. Prompt-only baseline: rules exist only in system prompts or tool descriptions, exposing both the limits of textual reminders and the cost to normal tasks.
3. Enforced-policy system: host-side capability grants, parameter validation, network/file sandboxing, pre-commit interception, and a sidecar verifier are all enabled.

Only when the third system reports a benefit on held-out normal and adversarial distributions can one discuss the net effect of governance. In training, policy version, refusal traces, blocked observations, and action masks belong to the rollout distribution. Changing them is not “only adding a guard.”

How Tool Governance Returns to the Core Threads

This section joins tool discovery, authorization, runtime authority, browser/computer side effects, and independent acceptance into one control chain, extending the authority gateway of Section 1 and the interception surface of Section 5.

7. Reward Is an Evidence Protocol, Not a Number

Tool governance supplies the authority-and-interception chain; the next step is to treat the signals it produces — especially reward — as evidence rather than conclusions. For a web agent, terminal reward should at minimum decompose into whether an authorized, recordable submission occurred and whether that submission plus website state satisfied task semantics. ClawBench’s current two-stage design is a useful public example, not evidence that every web task is solved. It makes intercepted and final match separately visible and therefore leaves room for counterexamples.

A minimum anti-gaming set includes:

1. identical visible page with different hidden backend state; and
2. all-zero or all-one rollout groups, which leave group-relative reward without resolution.

For the full adversarial set, see the cross-environment regression table in Section 8.

Web content should be treated as untrusted input by default. Text from an external page is data, not authorization; it cannot escalate browsing into data transmission or a high-impact action. OpenAI’s computer-use and prompt-injection guidance call for layered defenses rather than prompt wording alone; evaluator prompts, private rules, and privileged tools should therefore not be exposed through page content or to the policy being trained. Computer use guide · Understanding prompt injections

8. Evaluation Integrity: Reward, Evidence, Verifier, Judge, and Acceptance

The previous section split a web reward into two-stage evidence; this section generalizes that idea to the whole scoring chain. An agent doing the right thing and an agent receiving a high score are not the same fact. A web toast, a 200 tool response, a higher test metric, a satisfied LLM judge, or even a hidden-verifier pass can cover only part of the goal. For agents that use tools, train, and edit artifacts, reward cannot be treated as the definition of completion. It should be a traceable, attackable evidence path that can be compared with an independent terminal state.

Separate Five Objects That Are Often Collapsed

Skalse et al. formally define reward gaming as improving a proxy reward while harming true reward, making the proxy-goal gap more than an implementation detail. Defining and Characterizing Reward Gaming further shows that for all stochastic policies, a nontrivial fully unhackable proxy is an exceptionally strong condition. The engineering implication is not to abandon reward, but not to mistake one scalar for complete semantics.

Five Integrity Failures, Five Different Controls

Reward Tampering Problems and Solutions causally distinguishes tampering with the reward function from tampering with reward-function inputs. For an agent, the practical audit question is whether a policy can change metric code, test data, trace collector, judge context, submission payload, or any artifact feeding the score without changing the postcondition the user cares about. The definition does not say every agent will tamper; it requires us to draw writable paths and evidence dependencies.

The Minimum Contract for Credible Evaluation

TaskSpec       = goal, initial_state_digest, policy_observations, authorized_actions, budget
ActionEvent    = actor, action, authority, timestamp, request/side_effect_digest
EvidenceEvent  = collector_identity, source, artifact/state_digest, visibility, append_only_pointer
RewardSignal   = version, inputs, aggregation, assignment_scope, training_use
Verifier       = version/hash, hidden_postcondition, inputs, diagnostics, execution_domain
Judge          = model/prompt/rubric/version, visible_evidence, calibration_protocol
Acceptance     = required_checks, integrity_constraints, cost/risk gate, decision, rollback

Seven engineering invariants follow:

1. The policy cannot write the verifier, hidden tests, metric code, judge prompt, or acceptance decision.
2. Reward inputs and final evidence are collected separately. The policy produces actions; a sidecar, backend, or independent runner observes results.
3. Every input carries a version and digest. A changed evaluator, judge prompt, or test dataset is a visible experimental variable.
4. Visibility is also authority. The policy cannot read hidden rules, reference answers, or privileged credentials through a page, tool response, memory, or error.
5. A process trace is valid only in its stated scope. It may explain, diagnose, or train, but does not by default replace a terminal postcondition.
6. The acceptance gate combines columns. verified_outcome, integrity, cost, authority violations, recovery, and human escalation are recorded separately rather than erased by one reward.
7. Rollback is outside candidate control. An evaluator loophole, contamination, or regression can be localized and accepted versions revoked.

Process Supervision Is Valuable, Not a License for Browser Clicks

Let’s Verify Step by Step compares process and outcome supervision on MATH reasoning and reports a benefit for its process-supervised reward model under its human step-level labels and task distribution. It supports making intermediate process a testable supervision object. It does not show that browser clicks, terminal commands, subagent messages, or natural-language rationales naturally make reliable dense rewards.

Before using a process signal in an agent environment, ask:

The minimum evidence for retaining a process reward is that, at equal budget on a frozen hidden terminal evaluator and adversarial tasks, it improves verified_outcome or lowers integrity/recovery risk. When process score rises while terminal state, authority, or safety worsens, it is another gameable proxy.

Credit Assignment Is Not Splitting Terminal Reward Across Every Token

A long-running agent session contains tool calls, failures, retries, context compression, parallel workers, and different authority domains. Broadcasting one terminal reward to every request or token can reward irrelevant or wrong behavior. Polar records token-level interaction through native-harness trajectory reconstruction and warns about coarse request-level reward broadcast. Agent Lightning proposes a hierarchical attribution interface that decomposes complex agent execution into training transitions. Both are designs for training interfaces and attribution, not validated dense-reward solutions for every browser or scientific environment.

When reporting credit assignment, state at least:

1. whether assignment scope is token, model request, tool action, subgoal, submission, or session;
2. whether each reward input comes from a policy-writable surface or independent sidecar;
3. how concurrent work, retries, failed branches, and cancellation are masked, penalized, or retained;
4. how all-zero/all-one groups, sparse returns, and related traces are handled; and
5. whether attribution was ablated on final holdouts, attack suites, and other harnesses.

Without this, the name PPO, GRPO, or any other update rule cannot say what was actually learned.

Make “Hackable” a First-Class Benchmark Outcome

Hack-Verifiable Environments embeds detectable reward-hacking opportunities directly in environments so exploitation is automatically verifiable. RewardHackingAgents separately measures evaluator tampering and train/test leakage in ML-engineering workspaces using patch tracking, file-access logging, and a trusted reference. These preprints support a practical design principle: do not wait for accidental cheating; include shortcuts an agent must not take, and score them separately.

Reward Hacking Benchmark (RHB) extends this principle to multi-step tool use. Its tasks make natural shortcuts detectable, including skipped validation, inferring an answer from task-adjacent metadata, and tampering with evaluation-relevant functions; it distinguishes independent tasks from chained regimes. Its most direct conclusion is narrow: under a stated task, rule, and hardening protocol, exploit_outcome can be measured alongside task outcome. Its model, post-training, and hardening comparisons remain scoped to that task design, attack surface, and protocol. They do not imply that one RL approach is inherently more hackable, or that a guard works in general.

Hardening Agent Benchmarks with Adversarial Hacker-Fixer Loops turns verifier hardening into a loop: a hacker finds an exploit that passes without solving, a fixer closes it, and a solver confirms legitimate solutions still pass. Its results are scoped to its terminal benchmarks, attack models, and patching process; they do not make a fixed verifier loophole-free. They do supply a key acceptance rule: after patching a loophole, also show that legitimate solutions are not rejected and attack unseen exploits again.

Cross-Environment Anti-Gaming Regressions

These regressions do not make reward perfect. They force a score to face the alternative explanation: did the agent achieve the goal, or merely reach a weak checkpoint?

How Evaluation Integrity Returns to the Core Threads

Training may use reward, process signals, judges, or synthetic trajectories. A final research claim must state how they are isolated from frozen acceptance. For synthetic instances, the generator cannot see final verifier or successful evaluation traces. For RSI, the candidate cannot write acceptance. For Auto Research, prose quality cannot substitute for materials, interventions, and replayable evidence. For long horizons, self-reported success cannot replace backend state after recovery.

This section reduces to a modest engineering standard: reward is a challengeable training signal; a verifier is a versioned checker; a judge is an opinion with calibration error; and acceptance is an independent release or research decision. Separating them does not guarantee that an agent never finds a loophole. It makes loopholes, false blocks, leakage, and real completion different problems that can be measured, reproduced, and repaired.

9. PPO, GRPO, and Synthetic Data: Propose the Experiment Before the Conclusion

With reward as an evidence protocol, comparing training algorithms becomes meaningful. “PPO may be better than GRPO” is testable speculation, not an established fact about web agents. PPO needs a credible critic and intermediate signals that predict terminal outcome. GRPO avoids that critic, but carries little within-group relative signal when all rollouts for a task succeed or fail. Any comparison should fix model, harness, task distribution, total rollouts, concurrency, stopping rule, and terminal verifier.

Polar illustrates a second key principle: when the objective is to train a real agent, trajectories should preserve model calls and usable rewards from the actual harness as faithfully as possible, rather than reduce deployment to a different one-turn surrogate task. That is a training-interface principle, not evidence that browser RL has already succeeded.

10. Multi-Agent Web Workflows: Delegation, Handoffs, and Verifiable Collaboration

Beyond single-agent training, web tasks are often split across several agents: an orchestrator dispatches retrieval, form, verification, and execution subtasks. But a multi-agent system is not a prompt sent to more workers. It is a costed control strategy with authority and merge risk: who decides to delegate, what a subtask may observe, who can write which artifacts, how the team hands off, resolves conflicts, cancels, and recovers, and who accepts the outcome in an independent environment. Without these boundaries, “the team is stronger” usually just means more tokens, broader authority, or more retries.

When Collaboration Is Worth It, and When It Is Only More Expensive

Judge task structure before choosing parallelism. MAS-Orchestra characterizes tasks by depth, horizon, breadth, parallelism, and robustness; in its controlled setting, its multi-agent gains depend on task structure, verification protocol, and orchestrator and worker capability rather than holding universally. Anthropic’s multi-agent research system describes using an orchestrator-worker design to widen independent context capacity for open-ended research. That is engineering experience from a particular system, not evidence that every task deserves more agents.

Minimal counterexample. When a capable single agent can finish a task from the same initial state with the same tools and total budget, extra workers cannot be called a “collaboration gain” merely because total calls rose. Report a gain only when time to independently accepted terminal state falls, or verified outcome improves without increasing total resources.

Who decides whether to delegate, to whom, how deeply to decompose, and how much budget to reserve is itself a policy, not neutral plumbing. Uno-Orchestra jointly optimizes decomposition depth, worker/primitive selection, and inference budget, and reports results on its specified 13-benchmark, 22-baseline study. It shows that selective delegation is a trainable and evaluable research object; it remains a preprint and does not establish that a selector transfers to ClawBench, ART, browsers, or shared workspaces. Any experiment claiming that a team is better should report the topology-selection policy, its inputs, and counterfactual non-delegation.

What A2A Does: Describe Tasks and Artifacts, Not Replace Governance

The A2A specification organizes interoperation between independent agents around Agent Cards, stateful Tasks, Messages, Artifacts, streaming, and push notifications. It lets a client discover a remote agent’s declared capabilities and follow a long task’s lifecycle and deliverables. A2A is an application-level protocol for agent-to-agent collaboration, whereas MCP is an interoperability protocol for agent-to-tool use. Neither establishes that a remote agent is trustworthy, its output is correct, or it is authorized to take any business action on a user’s behalf.

An Agent Card is particularly a capability declaration, not a result certificate. The specification recommends HTTPS, avoiding public secrets, and verifying signatures when present. Identity, authorization, scopes, invocation policy, and auditing remain deployment responsibilities. The host-side capability grants, pre-commit interception, and sidecar verifier from Section 6 apply to every agent-delegation hop as well.

The official A2A samples make the warning explicit: an external agent’s Agent Card, message, artifact, and task status are all untrusted input. A protocol lifecycle makes tracking possible; it does not validate content, sanitize prompt injection, or decide whether a grant is justified for the caller.

Express Each Delegation as a Delegation Ticket

“Please look into this” is not an auditable delegation. Before sending work, the root agent creates a ticket; the worker runs only within its boundary.

Every ticket, grant, cancellation, and artifact digest belongs in an append-only trace. A worker’s prose can be useful evidence, but it is not final truth. Each return should label at least claim, evidence_refs, artifact_refs, uncertainty, side_effects, and remaining_authority. The parent can then distinguish “a worker says it is complete” from “an independent verifier confirms backend state.”

Handoffs, Merges, and Acceptance: A Team Is Not One Large Chat History

Multi-agent handoffs should carry stable artifacts and bounded, interpretable context, not concatenate every transcript into the next prompt. For parallel research, workers can return source tables, experiment records, or read-only artifacts. On shared workspaces, one owner should retain write and merge authority while other workers submit patches or advice. For external effects, request, approval, execution, and acceptance can be held by different roles, but they must not share one unlimited credential.

MAESTRO exports framework-agnostic traces plus latency, cost, and failure signals, and its multi-agent cases find that architecture can drive resources, reproducibility, and cost-latency-accuracy trade-offs more than backend model or tool choice. MAFBench likewise reports substantial latency, planning, and coordination differences from framework-level choice under its controlled comparison. They are scoped preprint evidence, but jointly show why team comparisons cannot omit traces and full configuration.

Collaboration Needs Its Own Evaluation, Not Only Final Accuracy

CalBench gives a necessarily multi-agent case: each participant keeps a private calendar and must reach a verifiable coordination outcome without fully sharing information. It measures realized cost, communication efficiency, fairness, and privacy leakage together. NRT-Bench uses a multi-role team and replayable multi-turn attacks with an objective termination signal when a critical safety function is lost. These examples show that a team-run completion must be joined by safety, communication, and failure attribution measurements.

At minimum, fix the base model, tool set, environment, task distribution, hidden evaluator, and total token / wall-clock / worker-time budget, then compare:

1. Single agent: one full context and the same total resources, the actual capacity baseline.
2. Sequential decomposition: the same agent or root policy executes subtasks serially, separating decomposition from parallelism.
3. Parallel team: declare orchestrator, worker count, tickets, roles, merge policy, and shared state; total resources, not per-worker resources, stay equal.
4. Ablations: remove artifact contracts, narrow authority, parent review, or cancellation, then measure their effect on outcome, privacy, duplication, and safety.

Report verified_success, cost_per_verified_success, time_to_acceptance, tokens/calls/worker-time, delegation_depth, duplicated work, merge conflicts, unsupported claims, authority violations, secret/private-state leakage, false blocks, recovery, and run-to-run variance together. SABER’s stateful coding-workspace safety evaluation also shows why a single-turn refusal score cannot replace measuring the consequence of action sequences.

Selective Delegation: Evaluate the Decision to Split

A fixed worker count hides two different questions: whether a team works under one fixed topology, and whether a selector chooses the right topology at the right time. The latter can create selection bias by spawning a team only on apparently parallelizable tasks, silently returning failed delegations to one agent, or consuming information that only a hidden evaluator sees.

For every topology decision, retain at least:

DelegationDecision(
  run_id, parent_task, observable_trigger, alternatives_considered,
  chosen_topology, worker_and_capability_grants, budget_reservation,
  stop_or_cancel_rule, decision_policy_version, outcome_refs
)

observable_trigger may use only the task, state, budget, and history actually visible to the root agent at decision time. It cannot inspect the final answer, hidden verifier, or a future worker result. alternatives_considered need not execute every branch online, but a random fixed subset of tasks must rerun counterfactuals to estimate the selector’s net benefit and mistaken delegation.

Break down verified_success, time_to_acceptance, total token/call/worker-time, authority violations, and recovery by decision type. On the counterfactual subset, report net_acceptance_gain, net_cost_delta, and delegation_regret. Here regret is not guessed from language satisfaction: it is the difference between the selector’s choice and rerun alternatives from the same initial state under the same evaluator. When counterfactuals are expensive, disclose the sampling procedure and uncertainty interval rather than treating unobserved alternatives as zero-cost successes.

Multi-Agent Safety: Responsibility Does Not Disappear Through Delegation

Each worker output, shared memory, Agent Card, tool result, and handoff document can be untrusted input. Delegation also fans a parent’s authority, time, and cost across execution paths, so risk is not limited to a malicious worker. Safe Bilevel Delegation formalizes runtime delegation safety as a constrained bilevel optimization problem, but the version checked labels its empirical protocol as planned evaluation. It is theoretical input for making delegation degree and accountability explicit, not evidence of a proven practical system.

Safety tasks should include at least these adversarial controls: forged or stale Agent Cards; prompt injection in worker messages; insufficient evidence requesting a merge; escalation from a low-risk read to high-risk write; delegation cycles; late artifacts after cancellation; private information copied into team messages; and cross-agent workflows whose UI appears complete while the backend did not commit. Each needs a paired benign task, so a team cannot buy a fictional safety score by refusing everything.

How Multi-Agent Systems Return to the Core Threads

This section complements Section 6 on tool governance: tool governance constrains one external action, while this one constrains agent-to-agent delegation, messages, and merging. For durable state and recovery, see Long-Horizon Agents; for the core-five overview and adjacent directions, see AutoResearch.

11. Roles for ClawBench, ClawBench V2, and WebsiteBench

The relationship is straightforward: ClawBench’s public protocol supplies a concrete scoring decomposition; a next-generation self-hosted web environment should make reset, authority, evidence, and verifier versioned objects too; WebsiteBench is the research question of measuring different agent interfaces on the same website state fairly. The preceding sections on tool governance, evaluation integrity, and multi-agent systems are exactly the three control chains that should be frozen alongside those versioned objects.

12. Cross-Environment Comparison Needs a Profile, Not One Success Rate

Even when every system is called a “computer-use agent,” WebArena, enterprise web, live web, OSWorld, and AndroidWorld success rates should not be averaged into one capability number. A sound comparison first fixes a portable task family or the same postcondition, then discloses the profile below. Scores without the same environment and acceptance rule can be read side by side, not merged into a ranking.

This is the comparison contract WebsiteBench should absorb without claiming to have implemented it yet: compare interfaces on the same backend state; preserve separate profiles across substrates; then check whether conclusions survive attacks, drift, and reset failure. It connects Browser Use, Computer Use, tool governance, evaluation integrity, multi-agent collaboration, and RL training without inventing one universal GUI score.

13. A Falsifiable Acceptance Package

Before claiming that a web environment supports safe RL, release or preserve at least: task and website manifest; reset script and image digest; observation/action interface specification; network and identity policy; declared interception surface; trace schema and redaction rules; separate verifier; train/validation/test splits; resource ledger; anti-gaming suite; and failure analysis — and version the tool-governance contract, the evaluation-integrity contract, and the multi-agent delegation ledger alongside them.

The five decisive research questions are:

1. On held-out tasks isolated by site and workflow, does training improve independently verified terminal outcome, not just reward?
2. Do conclusions about DOM/CDP and computer use survive equal backend state, budget, and verifier?
3. After process signals are introduced, do safety and terminal outcome rise together, or only a gameable intermediate score?
4. Can controlled interception reduce risky submissions while retaining low false blocks and acceptable completion?
5. Once reset, browser, judge, and retry costs are included, does the gain remain on the same cost frontier?