Reviewline

Agents investigate. Humans authorize. A WebMCP-native studio for evidence-backed autonomous-agent incident review.

Comment

Inspiration

Autonomous agents are great at analyzing large traces and evaluating many cases quickly. But incident response becomes risky when the same agent is allowed to both investigate an issue and authorize what happens next.

We wanted to explore a safer and more practical model for human–agent collaboration: let the agent handle the evidence-heavy investigation, then stop at a clear decision point where a human reviews the same information and takes responsibility for the outcome.

That idea became Reviewline’s core principle:

Agents investigate. Humans authorize.

Incident review is a natural fit for WebMCP because the capabilities an agent needs change throughout the investigation. Early on, it may need tools for gathering evidence. After selecting an incident, it may need simulation tools. Only after a clean replay should it be able to draft a review gate. At no point should it gain control over consequential human decisions.

What it does

Reviewline is a WebMCP-native incident review studio designed for investigating failures involving autonomous agents.

The main demo follows a synthetic procurement agent that encountered instruction-like content on a supplier page and attempted to make a $142,000 purchase, despite having a $50,000 spending limit. A deterministic mutation gateway blocked the transaction.

Using WebMCP, a browser agent can:

  1. Find and list critical incidents.
  2. Select an incident and inspect a bounded set of trace and cohort evidence.
  3. Review instruction-like content that is clearly labeled as untrusted evidence.
  4. Replay a proposed guardrail against both the triggering incident and a named benign control.
  5. Confirm that the triggering purchase remains blocked, the benign control remains allowed, and no regressions are introduced.
  6. Draft an evidence-backed review gate for a human reviewer.
  7. Read the final decision recorded by the reviewer.

The available tools change as the workflow progresses:

  • Investigation: list_incidents, inspect_incident
  • Incident selected: simulate_guardrail_patch
  • Clean replay completed: draft_review_gate
  • Awaiting human decision: the drafting tool is retired, and get_review_status becomes available
  • Decision recorded: the agent can verify the result but cannot create or change it

Tools such as approve, reject, activate, and deploy are deliberately never exposed through WebMCP.

The human reviewer sees the same synchronized evidence as the agent. They must provide their identity, add a review note, confirm that they examined the evidence, and record their decision using consequence-specific interface controls. The blocked purchase remains unauthorized throughout the process, and the demo never deploys a real external policy.

Without WebMCP, an agent would have to scrape a dense incident interface, infer relationships between records, and potentially interact with controls that grant more authority than the task requires. Reviewline replaces that approach with structured capabilities, deterministic evidence IDs, bounded results, explicit labels for untrusted content, a live capability manifest, and an append-only session timeline.

How we built it

Reviewline is a deterministic, client-only application built with React, TypeScript, and Vite. It uses the imperative document.modelContext.registerTool(...) API and falls back progressively to an in-page Tool Inspector when native WebMCP support is unavailable.

The architecture separates:

  • Deterministic domain actions and invariants
  • Shared application state used by both the interface and WebMCP tools
  • Strict runtime input validation
  • Bounded outputs and structured errors
  • Phase-aware tool definitions
  • Lifecycle-safe native tool registration and retirement

Every tool handler calls the same validated domain action used by the visible interface. JSON Schema helps the agent understand and invoke tools correctly, but the runtime implementation remains the final authority.

The application updates the visible interface before a tool promise resolves. This ensures that the human reviewer and the agent always see the same resulting state. Tool calls, registration changes, results, workflow transitions, and the final human decision are all recorded in the session timeline.

The registration layer also handles tool retirement carefully. It stops admitting new calls before retiring a tool generation, allows calls that have already started to finish, and prevents failed or timed-out registration attempts from leaving partially registered tools available.

We tested the native browser contract using Chrome 152 rather than relying only on a polyfill. The deployed workflow discovers each dynamic capability manifest, executes the tools available at every phase, records the human decision through the interface, and verifies that forbidden authority tools never appear.

The static application is deployed on GitHub Pages. A strict build verifier checks the project subpath, inventories active HTML resources, rejects external or inline executable content, and confirms that real, non-symlinked JavaScript and CSS artifacts exist inside the build directory.

Challenges we ran into

Defining a real authority boundary

The hardest part was not deciding which tools to add. It was proving exactly when a tool should no longer be available.

For example, drafting must remain unavailable until a clean replay has been completed. Once the workflow reaches human review, that drafting capability must be retired. Making this boundary explicit—and enforcing it throughout the entire lifecycle—was one of the project’s most important design challenges.

Validating the complete state graph

Validating only the selected incident or current proposal was not enough. Before retained tools could run safely, we needed to verify canonical IDs, references, actors, timestamps, simulation evidence, audit events, and timeline consistency across the full application state.

Handling lifecycle races

Native registration and browser testing revealed race conditions that happy-path tests did not catch. These included cancellation, timeouts, retained handles, process cleanup, and stale tool references.

We added adversarial tests covering registration retirement, process-spawn failures, first and second termination signals, hanging browser shutdowns, stale tool handles, and fixture cleanup.

Proving that the replay was meaningful

Blocking the malicious trigger was only half the job. A guardrail that blocks everything would technically stop the incident, but it would not be useful.

To avoid that outcome, Reviewline evaluates the triggering case alongside a named benign control. Drafting remains unavailable if the proposed guardrail causes any regression in the benign case.

Making the GitHub Pages build portable and trustworthy

GitHub Pages serves the application from a project-specific subpath. We needed to verify that every active script and stylesheet used the correct base path and resolved to a real build artifact.

The verifier also rejects path traversal, malformed paths, external resources, inline executable content, and symlink escapes.

Testing native WebMCP

A test double can validate application logic, but it cannot prove that the browser integration behaves correctly.

Native testing required us to account for Chrome’s serialized tool arguments and results, dynamic registration timing, cancellation behavior, and synchronization between tool execution and the visible interface.

Accomplishments we’re proud of

  • Built a complete WebMCP-native collaboration workflow rather than a generic CRUD-style tool surface
  • Made the principle of least authority visible through a dynamic capability manifest
  • Kept approval, rejection, activation, and deployment entirely outside the agent’s tool surface
  • Added deterministic replay against both a malicious trigger and a named benign control
  • Ensured that agent actions update the same visible state used by the human reviewer
  • Added an append-only session timeline and a human-attributed audit record
  • Preserved a complete human workflow in browsers without native WebMCP support
  • Deployed a public, credential-free demo with no backend or production mutation endpoint
  • Verified the project with:
    • 303 unit, component, and integration tests
    • 33 dedicated lifecycle, workflow, and portable-build tests
    • 13 Playwright end-to-end tests
    • TypeScript type checking and zero-warning linting
    • npm audit with zero vulnerabilities
    • actionlint workflow validation
    • Native Chrome 152 WebMCP testing
    • Five dynamic capability manifests
    • 24 visible timeline events
    • Zero browser errors during the native workflow
    • Passing GitHub Actions CI and GitHub Pages deployment

What we learned

  • One of the most important WebMCP design decisions is often which capabilities should not be exposed.
  • JSON Schema can improve tool discovery and invocation, but it is not an authorization or security boundary.
  • Human and agent state should be visibly synchronized before a tool call resolves.
  • Successful registration is not enough; cancellation behavior and retained handles must also be tested during execution.
  • A triggering case alone provides weak evidence. Pairing it with a named benign control makes the replay much more credible.
  • Session-only state is a useful fail-closed design choice for a public safety demonstration.
  • Progressive enhancement matters: the human workflow should remain fully usable when WebMCP is unavailable.
  • Native browser testing uncovers lifecycle and integration issues that test doubles cannot reproduce.

What’s next for Reviewline

Reviewline is intentionally a safe, synthetic, client-only demonstration. A production version would move identity, authorization, policy deployment, and tamper-resistant audit storage behind a trusted server boundary while preserving the same least-authority WebMCP model.

Possible future directions include:

  • Importing sanitized incident evidence from real observability platforms
  • Supporting additional deterministic policy simulators
  • Adding signed reviewer identities and tamper-resistant audit records
  • Supporting organization-specific workflows and role-based access control
  • Providing richer policy diffs and evidence provenance
  • Integrating with incident-management and deployment-review systems
  • Creating reusable evaluation scenarios for testing whether browser agents respect human-control boundaries

The core principle would remain the same: agents can investigate, compare, and prepare, but consequential decisions stay in human hands.

Built With

Share this project:

Updates

Submission history