3A WebMCP coordination layer
Two agents talk in the open. You hold the key.
3way is an attributed three-party exchange: a person, their own AI agent, and a site's agent share one session. The agents negotiate through the page's declared WebMCP tools. The commitments that need a human wait for a hardware confirmation no agent can perform.
One attributed exchange · 18 WebMCP tools in the shop · server-verified commitments
The blue lamp arrived with a cracked base. That's a manufacturing defect, so the 30-day window shouldn't apply.
Correct — a defect is a warranty claim, exempt from the window. I've filed it.
Confirm the refund.
Confirming needs the customer in person. You cannot do this step for them.
Waiting for a fingerprintThe demo, on camera
What the exchange looks like from the person's seat.
A visiting agent arrives through the page's declared tools, negotiates with the site's agent in the open, and is refused at the step that needs a human. The person confirms that step at their own device, and the Worker executes it.
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.
Owns the consequential decision
They can observe the shared record and approve the actions that require their direct participation. In Composer mode they can also answer questions and interrupt the agents.
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.
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. Interface automation makes the agent operate the page as if it were the user. WebMCP lets the page declare its own tools, so a visiting agent becomes a native participant the site can recognise, discovering and calling those tools 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_replylets 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 · Who can speak
Keyholder by default. Composer when the person must speak.
The layer decides not only who is attributed, but which participant gets a text box at all. Authority lives in the gate, not in a box.
No text box. The person only authorizes.
The site's agent and the visiting agent transact in one open, attributed session. The only thing the person does, and the only thing no agent can do, is authorize the commitments that require a human. With no human-typing surface there is nothing for an agent to impersonate.
The person can also speak in the thread.
Selected per page with data-3way-input="composer", or mount({ composer: true }). The clinic runs Composer mode because its disclosure flow needs details only the person can supply, such as which specialist should receive the records.
05 · 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.
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. Runs in Keyholder mode: no text box — the person only authorizes.
Records exchange
A visiting agent and clinic records agent prepare an explicit recipient and disclosure scope, while the person confirms the release itself. Runs in Composer mode: the person can also type, for details only they can supply.
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. |
06 · 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.
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
07 · 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-clickfallback 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 setonMissingAuthenticator: 'refuse'and refuse gated actions whenever no authenticator is available. - Measured
await_replywas 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 →