A WebMCP coordination layer

An attributed three-party exchange with verifiable human commitments.

3way gives all three participants a shared, attributed session. A person's agent can represent their context and interests. A service's agent can respond from its own records, rules, and capabilities. The person can participate throughout and retain approval over commitments that require them.

WebMCP makes the visiting agent a native participant instead of a bespoke integration or a program operating the interface as if it were the user. 3way adds shared state, participant attribution, structured handoffs, domain actions, and action-bound human confirmation.

Experience the shop exchange Experience the records exchange

One shared exchange · two independent agents · 18 WebMCP tools in the shop exchange · human participation · server-verified commitments

Three participants · one attributed exchange

Your agent · via WebMCP · unverifiedThe blue lamp arrived with a cracked base. That's a manufacturing defect, so the 30-day window shouldn't apply.
Halden SupportCorrect — a defect is a warranty claim, exempt from the window. I've filed it.
Your agent · via WebMCP · unverifiedConfirm the refund.
Refused · needs the personConfirming needs the customer in person. You cannot do this step for them.
Waiting for a fingerprint

01 · The general model

Three participants with different information and authority

The product is the exchange itself: a person, a visiting agent they chose, and an online service acting from its own systems. Each participant contributes something the other two do not have.

The person

Owns the consequential decision

They can observe the shared record, answer questions, interrupt the agents, and approve actions that require their direct participation.

The visiting agent

Represents context and interests

It brings the person's request and relevant context, calls the site's declared tools, and stays available when the service or person replies.

The service agent

Answers from the service

It can use the service's records, policy, and domain capabilities without pretending to speak for the person or the visiting agent.

02 · The open tool channel

Why the visiting agent needs WebMCP

A bilateral vendor integration works only after two systems arrange an API and identity model together. WebMCP lets the page declare its own tools so a capable visiting agent can discover and call them while the person is on the site.

Interface automation remains useful, but its clicks and keystrokes do not by themselves tell the service whether a person or an agent produced them. A declared, page-owned tool call gives the service a separate channel it can attribute and govern. That is a protocol distinction, not a claim that every automated interface interaction is deceptive.

Route into a service	What it establishes
Bilateral integration	A pre-arranged connection between specific vendors.
Interface automation	Interaction through the same controls available to a person.
WebMCP	A page-owned tool surface for a visiting agent, without a bespoke vendor pairing.

Measured The shop's current registry exposes 18 WebMCP tools through native document.modelContext where it is available and uses the vendored polyfill elsewhere. Inspect the browser capability probe →

03 · The coordination layer

What 3way adds to the tool channel

WebMCP supplies the route. 3way supplies an exchange model that lets the three participants coordinate across that route without collapsing their roles.

Built
Participant attribution. Transcript entries record whether they arrived from the person, the visiting WebMCP agent, or the service agent.
Built
Scoped tool views. The visiting agent sees the page's WebMCP tools; the service agent gets a narrower registry that cannot impersonate that visitor.
Built
Structured handoffs. Missing-information results separate the question for the person from guidance for the agent. Human-confirmation results name the pending request and say that the action did not happen.
Built
Continuation. await_reply lets a visiting agent that chooses to remain available receive the next event after a person or service response.
Built
Action-bound execution. A confirmation is tied to one pending request and tool, spent once, and rechecked by the Worker when the action executes.

04 · Implemented evidence

Two implemented exchanges

The shop and clinic are working evidence for the same coordination model. They are not the definition of the product, and they do not imply that the other applications below have been implemented or validated.

Built

Shop exchange

A visiting agent represents a damaged-item case, Halden Support evaluates its own order and warranty data, and the person retains the refund commitment.

Open the shop exchange

Built

Records exchange

A visiting agent and clinic records agent prepare an explicit recipient and disclosure scope, while the person confirms the release itself.

Open the records exchange

Potential applications, not implemented claims

Status	Application areas	What still needs domain work
Potential	Healthcare, insurance, legal, finance, government	Domain policy, identity, authorization, compliance, and independent validation.
Potential	Enterprise approval	Organizational roles, delegation boundaries, audit requirements, and system integration.
Potential	Accessibility and disputes	User research, appropriate human controls, and safeguards for each consequential action.

05 · Implementation

One exchange model, enforced in code

The shared registry in packages/widget/src/tools.ts defines the exchange operations and domain actions. 3way exposes the appropriate view through WebMCP to the visiting agent, gives the service agent its own restricted view, and reflects the same session state in the human-facing widget.

The browser coordinates the participants; it is not authoritative for a gated effect. The Worker validates the pending request, assurance, action binding, eligibility, and single use before a refund or record release executes.

Shared exchange core · separated authority

packages/widget/src/tools.ts
  ├─ WebMCP tool view → visiting agent
  ├─ restricted tool view → service agent
  └─ shared session events → human widget

Cloudflare Worker
  └─ authoritative execution of gated actions

06 · Assurance boundaries

Assurance and current limits

Attribution, presence, and consent are different claims. The implementation keeps them separate so a useful record is not presented as stronger proof than it is.

The current demos are one implementation on one service. They demonstrate the exchange mechanics; they do not establish interoperability, regulatory suitability, or demand in the potential application areas.

Limit
Message attribution is channel attribution. It records which 3way path produced an entry; it does not independently verify every identity or claim behind that channel.
Limit
WebAuthn proves presence for one bound action. Server verification does not prove informed consent, comprehension, or that a compromised page displayed the same action it bound.
Demo only
The deployed trusted-click fallback is lower assurance, demo-only, and unsafe for production. A caller that obtains the demo session ticket and can set the expected Origin can complete this path without proving human presence. Production deployments must set onMissingAuthenticator: 'refuse' and refuse gated actions whenever no authenticator is available.
Measured
await_reply was tested with one model and one transcript harness. It cannot wake an agent that did not choose to wait. Read the bounded trial and its limits →