Friction

Test the same task through human eyes and agent tools.

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Friction

Inspiration

WebMCP lets a live page publish named, structured actions instead of forcing an agent to infer buttons and forms. That creates a new usability question: does the agent receive the same information, consent gates, and final state that a person sees?

Friction is a dual usability laboratory for answering that question. It pairs one visual journey with one WebMCP journey, exposes the differences, repairs both interfaces together, and proves the improvement with a retest.

What it does

The deterministic RelayConf event-registration scenario contains three intentional problems:

  • a quiet-zone seat is hidden behind vague human-facing wording;
  • the baseline agent result omits a $12 service fee and refund condition;
  • an ambiguously described completion tool finalizes without the human review gate.

Friction records both traces and scores outcome, information, consent, state, and effort parity. It produces evidence-backed findings and a four-part patch. A human must approve that patch through the visible UI—approval is intentionally not agent-callable. After approval, the human option becomes clear, the tool returns an itemized total and policy, and finalization requires a review token plus confirmed=true. The paired score rises from 50/100 to 96/100.

Why WebMCP is essential

WebMCP generates one side of the experiment. The page registers ten tools with document.modelContext.registerTool(...); these are not a remote MCP server and do not automate the DOM. Tool handlers and visual controls share the same React state and durable browser storage, so agent mutations immediately change the visible trace, findings, and comparison.

Without WebMCP, Friction could test only visual automation. With WebMCP, it can inspect the explicit contract a site offers to agents and compare that contract against the human experience.

How humans and agents work together

People complete and judge the visual task, report hesitation, and retain approval authority. Agents exercise the structured contract, analyze traces, submit findings, and propose interface changes. Neither side replaces the other: the agent contributes speed and structured analysis, while the person supplies subjective usability evidence and approves consequential changes.

How we built it

Friction uses React 19, TypeScript, Vinext, Tailwind CSS, shadcn primitives, and ChatGPT Sites-compatible Cloudflare output. Ten page-owned WebMCP tools use restrictive JSON Schemas, runtime checks, read/write annotations, untrusted-content hints, feature detection, and registration cleanup with AbortController.

The account-free demo persists locally in the browser, making the before/after experiment repeatable without credentials or external APIs. Deterministic tests cover the parity score, consent and information failures, approval transition, and repaired replay.

Challenges we ran into

The most important design challenge was avoiding a fake split between “human UI state” and “agent demo state.” Every interaction had to operate on the same live model. The second was expressing the repair as a real contract change: the completion tool’s description and JSON Schema are re-registered after human approval, and its handler independently enforces review and confirmation.

Accomplishments that we're proud of

  • A non-trivial ten-tool WebMCP implementation over shared visible state.
  • A complete evidence → proposal → human approval → retest loop.
  • A consent failure that is demonstrably blocked by the repaired handler.
  • A polished responsive product requiring no accounts, secrets, or external APIs.
  • Deterministic tests, type checks, linting, production build, and dependency audit.

What we learned

Parity is broader than whether both paths eventually produce the same record. A fast agent path can still be worse if it hides cost, weakens consent, or returns less context. Tool schemas, descriptions, results, and confirmation design are part of the product interface and need usability testing just as much as buttons and labels do.

What's next for Friction

Future versions could import OpenTelemetry-style traces, compare multiple scenarios, export regression suites for CI, and provide a lightweight SDK that lets other WebMCP sites embed paired parity tests while keeping approval policies application-owned.

Built With

Share this project:

Updates