Three in the Loop

A WebMCP research workbench where agents do the legwork and humans decide what counts as evidence.

Comment

Inspiration

Three in the Loop began with a practical question: what should research look like when a human, an agent, and a website work together in the same live workspace?

We began with the WebMCP specification, Chrome developer and agent/tool security guidance, OpenAI developer demonstrations, community/practitioner demonstrations, and repeated internal dogfooding. Together, those sources made the website-declared tool model concrete. Our product question was what should remain under human control.

Research was the test case we kept returning to. It rewards speed in gathering and punishes speed in judging. So we built the smallest workbench that could test the boundary between useful research delegation and human evidence judgment. Repeated dogfooding refined that boundary until it matched the workflow.

What it does

Three in the Loop is for researchers, analysts, and technical teams doing fast-moving evidence-based research where recency, authority, and provenance matter.

It is a research workspace shared by a person and a WebMCP-enabled agent in the same live browser workspace:

Human defines → Agent researches → Human curates → Agent synthesizes → Human approves

You set the research question, audience, and evidence limit. The agent reads the workspace, searches OpenAlex, inspects sources, and proposes evidence. Then it stops. You accept or reject each proposal in the Workbench and control evidence membership. The agent drafts an Evidence Brief whose findings may cite only human-accepted evidence. You edit and review the brief, mark it reviewed, approve it, and download the approved Markdown.

The Research Cycle shows whose turn it is at every stage. A WebMCP activity readout records real tool calls as they land, so agent work is visible without exposing private reasoning. The application embeds no model and makes no OpenAI API calls; intelligence comes from a compatible external agent using the site’s bounded tool surface.

Why WebMCP

The interesting question was never whether an agent can search. It was which operations the site should expose as structured tools and which decisions should remain in the human workflow.

WebMCP lets the site declare that boundary on its structured tool surface. Three in the Loop exposes exactly five tools:

  • get_research_workspace
  • search_sources
  • get_source_details
  • propose_evidence
  • draft_evidence_brief

Accepting evidence and approving the brief are deliberately absent from the WebMCP tool surface. They are buttons, not tools. For the operations the site does expose, the agent can use structured calls instead of scraping the interface or imitating human clicks.

Both actors work against the same bounded browser workspace. It is the same page, with the turn changing hands.

Challenges

The hard problem was not building tools. It was deciding where useful delegation should stop.

We began with read-only tools and added exactly two state-changing operations when the workflow needed them: propose_evidence can stage a proposal, and draft_evidence_brief can place or replace a review-required draft. Evidence acceptance or rejection, evidence membership, brief editing and review, and final approval remain outside the WebMCP tool surface. That boundary looks obvious in hindsight. It took repeated use to find it.

Two smaller problems followed. The site cannot know that a person has spoken to an agent or that the agent is thinking, so it only reports AGENT WORK IN PROGRESS after a real WebMCP call lands in the current stage. And persistent rehearsal state kept reviving old missions, so the workspace now uses session-scoped browser storage: same-tab refreshes survive, while a new browser session starts clean.

What we learned

We began by treating the tool as the main unit of WebMCP design: name it well, type it well, keep it narrow. That is necessary. It is not what made the product work.

What made it work was the handoff. The agent works until evidence selection returns control to the human. The human changes the evidence set. The agent continues from that decision, not from scratch, and drafts from the accepted evidence. The human reviews and signs off.

Each time we clarified one of those transitions, the product became simpler and more useful. Looking at tools in isolation never explained the workflow as clearly as the handoffs did. Next time, we would design the journey between the person, the agent, and the page first; the tool set should follow from that journey.

The final product does not try to show how much the agent can do alone. It shows how clear the responsibility is at every step.

What's next

The application is frozen for submission. What follows is evaluation before expansion.

Planned assurance work includes deterministic checks of workflow invariants, WebMCP registration and cancellation lifecycle testing, response and serialized-output measurement, model-facing indirect prompt-injection evaluations, browser-agent evaluations of human-authority boundaries, and adversarial retesting after approved hardening.

Product directions remain open too: richer evidence comparison without a fake credibility score, additional structured research providers, reusable research sessions, and collaboration. Expansion follows evidence from the evaluations while preserving the principle that made the product useful:

The agent gathers. You decide what counts.

Built With

Share this project:

Updates

Submission history