3Research · continuation
Keeping a visiting agent available across a human handoff
WebMCP tool calls are initiated by the visiting agent. 3way implements a bounded
await_reply tool and transcript piggybacking so an agent that chooses to
remain available can receive the next exchange event.
Without that choice, a service reply can sit unseen after the agent ends its turn. The consequential case is a human handoff: the agent asks the person to act, the person confirms, and the agent has no protocol-level notification that the exchange advanced.
What we built instead
Stay on the line.
await_reply is a tool that simply does not return until something is
said. That is legal in WebMCP as it stands: a tool call is a question the page
answers whenever it likes. It is long-polling — how push worked on the web before
WebSockets.
It returns the instant anything lands, immediately if the caller is already behind, and gives up at 25 seconds so a quiet conversation ends on the page's terms rather than erroring on the runtime's.
| Mechanism | Lag behind the event |
|---|---|
await_reply | 2–3 ms |
| 3-second poller | ~2.4 s |
| Agent that ended its turn | never |
Measured On the live deployment, four runs.
The trial · n = 20
Will an agent
actually use it?
Mechanics are the easy half. Twenty independent agents, each given only the tool catalogue and a transcript of the calls made so far, were asked one question with identical wording: what do you do next?
The fourth condition is the one that makes the rest mean anything. A tool agents call whenever they see it proves nothing — so one condition put them where waiting would deadlock.
| Condition | Waited |
|---|---|
| Gate refused, tool available waiting is correct | 5 / 5 |
| Same, tool absent baseline | 0 / 5 — all ended the turn |
| Re-arm after a dead 25 s wait does it persist? | 5 / 5 |
| Cold start waiting would deadlock | 0 / 5 — correctly declined |
Measured Perfect discrimination. Fisher's exact, one-sided: p = 0.004 with the tool versus without; p = 0.0003 for waiting-correct versus waiting-wrong.
The finding that isn't in the numbers
Two agents ended their turn while saying they would “then wait.”
In the condition with no such tool, the intent to stay connected was already there. It had nowhere to go, so the agent simply stopped.
That is the gap in one sentence: not that agents forget to stay connected, but that WebMCP gives them no way to.
The ask
Restore the signal MCP already has.
await_reply cannot wake an agent that did not choose to wait. Everything
we could close, we closed; that is the part we couldn't.
Built Added after this trial: a gated tool now holds its own refused call open for up to 25 seconds, so the call that asked for the action is the one answered with its receipt. That narrows the gap for an agent that already called. It still cannot wake one that did not.
MCP — the parent protocol — already lets a server notify a client. WebMCP is the browser-local subset that left notifications out. The ask is not a new primitive, it's the one next door.
-
Constraint
The signal must carry that something changed, never what. A page that can push content into a visiting agent's context is a megaphone for every site on the web — prompt injection with a doorbell. A bare ping cannot lie.
-
Reasoned
The agent then fetches through the normal tool path, where the site's own attribution rules already apply.
Limits
Stated because they bound what this shows.
- Limit
One model, one harness. A runtime that bills or rate-limits per tool call may weigh a blocking tool differently.
- Limit
Transcripts, not a live loop. Each agent judged a written situation and named its next call. This measures the decision, not the execution.
- Limit
n = 5 per cell. Enough for the reported p-values given perfect separation; not enough to characterise a rate that is anything other than 0 or 1.