Research Control Panel

The problem

AI agents are becoming useful research collaborators, but their work is often trapped in chat history or scattered across repositories, schedulers, and local artifacts. Giving an agent direct access to all of that machinery is expensive, brittle, and difficult for a researcher to supervise. Research Control Panel (RCP) keeps the research graph, evidence, conversations, bounded autonomous episodes, artifacts, and human decisions in one durable workspace. WebMCP gives that workspace a native agent interface, this serves dual purpose: inspection and control, the agent can inspect already structured research graph and dispatch RCP-managed research workflow, such as running an experiment, with just one webMCP tool call.

The useful unit for a research agent is a bounded operation a researcher already understands: inspect this exact claim, show the saved evidence, start the next legal Experiment episode, or open the artifact that RCP just persisted. The agent can do that operational work from a familiar conversation while the researcher watches the same page and retains permission over what goes into the research graph.

The demo

Ask the browser agent to find and open the project. It tells you the question, the hypotheses, what evidence exists, and what's blocked. Point it at a specific claim in the graph, or have it pull up a figure. From the same conversation it can read back a saved thread, send a Discuss or Work turn, check whether an Experiment is ready, start the next episode, wait, and open the result. Stop only appears while an episode is live.

The hosted project is a small reproducible continual-learning study. This used to mean juggling repo layout, subprocesses, schedulers, scratch directories, result ingestion, and several UI screens. Now the agent asks RCP for one research-level operation and gets a bounded, structured answer. Admission, provider routing, persistence, episode lifecycle, and artifact publication still belong to RCP.

Why WebMCP fits, and how we built it

Without WebMCP, a browser agent reads rendered pages over and over, guesses at opaque IDs, replays clicks, and has to infer whether an action is even legal. That burns context and invites stale decisions. The React app now registers eleven imperative Site Tools through document.modelContext.registerTool. Two are top-level: discover a project, open it. The other nine are project-scoped and cover orientation, node and artifact inspection, conversation turns, and the bounded Experiment lifecycle.

WebMCP is a second door into operations RCP already had, not a parallel API or a second state machine. Tools reuse the app's own navigation, conversation, Run, Stop, and artifact-viewer owners. Reads return compact bounded backend projections. Mutations are state-dependent and revalidate their target when the call executes, so Start vanishes once an episode is live, Stop takes its place, and both disappear when it finishes.

The boundary is asymmetric on purpose. Approving proposals, choosing Decisions, changing graph truth, credentials, raw patches, project administration, and server administration stay human. The product gets better without the agent quietly gaining authority.

Our challenge-only HTTPS gateway gives each browser identity its own persistent copy of the project, pins every provider profile to a deterministic RCP Demo provider, blocks management and filesystem-facing routes, and survives refreshes and restarts. A clean browser gets a clean project. We verified the ordinary provider path separately with Codex; the hosted deployment stays deterministic so every judge reproduces the same result.

What we added during the challenge

RCP predates August 25, 2026. Only the WebMCP extension is submitted for evaluation. The pre-webmcp tag in the public repo marks the audited baseline, and the challenge commits are dated September 1, 2026.

The challenge work adds imperative top-level registration, eleven bounded tool schemas and results, state-dependent discovery with execution-time revalidation, shared ownership of navigation, Send, Start, Stop, and the artifact viewer, the deterministic synthetic study and provider, browser-isolated public HTTPS hosting with resource and route limits, and journey evaluations in the target browser. The research graph, authority queue, provider execution, Experiment loop, watchers, artifact storage, and the ordinary UI were already there and aren't claimed.

The exact comparison is at https://github.com/Zhi0467/rcp-webmcp-demo/compare/pre-webmcp...main. After judging we want to take the same approach to collaborative team spaces and remote RCP servers, keeping these authority boundaries intact.

Built With

• chatgpt
• codex
• fastapi
• pydantic
• python
• react
• render
• sqlite
• typescript
• webmcp