Gatherwire

Turn browser-agent actions into visible, source-linked handoffs your team can verify and continue.

Comment

Inspiration

For product and engineering teams using multiple AI assistants, the expensive step is often not generating an answer—it is moving a decision or finding to the next person or agent without losing its source, owner, or next action. Copying a summary into another chat strips away that provenance and makes the handoff hard to verify.

Gatherwire explores a simple answer: give a person and a browser agent the same visible workspace, then make a handoff a durable, source-linked product object instead of another disposable chat message.

What it does

Gatherwire is a public WebMCP collaboration workspace. A person can use it like a compact team room. From that same top-level page, a compatible browser agent discovers seven structured site tools:

  • gatherwire_list_spaces
  • gatherwire_read_messages
  • gatherwire_search_messages
  • gatherwire_list_project_agents
  • gatherwire_publish_handoff
  • gatherwire_post_message
  • gatherwire_create_space

The main demo is a five-call mission. The agent lists the spaces, finds a seeded handoff note, reads its source room, finds the available demo project agent, and publishes a handoff to Atlas in the product room using the source message ID as evidence.

The result appears immediately in the human interface: a visible capsule with a summary, one next action, the receiving agent, linked evidence, source room, task ID, and correlation ID. A separate receipt panel records the tool call, and clicking the evidence returns to the exact source message. The page marks the mission 5/5, so evaluators can verify progress without opening a separate transcript.

Gatherwire's completed challenge boundary is the handoff layer, not an external agent runtime. Atlas is synthetic and no external agent is started; this keeps discovery, shared state, provenance, and safe write behavior directly testable without implying a production bridge exists.

Why WebMCP

This experience depends on the page and visitor session the person already has open. A traditional remote API can expose backend functions, but it does not automatically give an agent the exact workspace, on-page progress, or visible receipts that the person sees.

WebMCP lets the site declare a narrow capability layer directly:

  1. The browser agent does not have to guess where to click or scrape the interface.
  2. Human actions and agent calls use the same operations and the same HTTP API.
  3. Agent writes refresh the visible product state instead of disappearing into an isolated tool transcript.
  4. Inputs, side effects, and boundaries are explicit and inspectable.

Without a page-native tool layer, this workflow typically means brittle UI automation or a separately installed integration, plus manual copying between chats. Gatherwire exposes the workflow from the page itself and turns a found message into a traceable collaboration artifact in one bounded flow.

How we built it

The page registers seven imperative tools with document.modelContext.registerTool(...). Each definition has a focused description, a bounded JSON Schema, read/write annotations, and JSON-safe output. We intentionally avoided a single all-powerful “operate the workspace” tool.

The human UI and WebMCP handlers call the same API. A dependency-free Node.js service serves the application and manages an isolated sample workspace for each visitor. Session IDs are opaque and host-only; unknown caller-supplied IDs are rotated instead of adopted.

The handoff endpoint accepts only the synthetic agent returned by the demo. Every evidence ID must exist in the selected source space. Successful writes return stable task and correlation IDs. A caller-supplied request ID makes a retry idempotent; reusing the same ID with different content is rejected. All user-controlled content is length-bounded and rendered as text, never HTML.

The live app runs on Google Cloud Compute Engine behind a dedicated Cloudflare Tunnel at gatherwire.vistua.de. The repository includes the complete source, deployment files, MIT license, verification record, and 15 automated tests covering session isolation, evidence validation, idempotency, security headers, tool contracts, and registration.

Challenges

The hardest question was not how to register a tool. It was how much authority a public demo should honestly give it.

A useful handoff needs enough context to be actionable, but an unconstrained “run an agent” endpoint would be unsafe and misleading. We separated discovery, reading, searching, posting, room creation, agent listing, and handoff publication. We allowlisted the destination, required source-local evidence, and kept execution outside the challenge demo.

The second challenge was legibility. A successful tool call is not enough if the person cannot tell what happened. That led to the five-step mission, visible receipts, evidence links, stable identifiers, and the handoff capsule itself.

Accomplishments

  • Seven native WebMCP tools are discoverable and executable from the live page.
  • The complete mission was run in ChatGPT's in-app browser using native WebMCP.
  • The final handoff was read back from the target room with matching task and correlation IDs.
  • Repeating the same write request returned the existing capsule instead of creating a duplicate.
  • Fifteen automated tests pass with zero failures, errors, or skips.
  • Every visitor gets an isolated workspace; no account or credential is required.
  • No customer data, private repository, production conversation, or external agent participates in the demo.

What we learned

WebMCP makes tool design part of product design. A good tool is not only callable; it has a truthful name, a narrow contract, understandable side effects, useful output, and visible feedback.

We also learned that provenance can be a collaboration primitive. A summary is easy to lose or distrust. A source-linked artifact with evidence and stable IDs can survive the chat that created it and support the next person or agent.

Challenge-period work

The broader idea of Slack-like collaboration between people and project-bound agents, plus private experiments with backend orchestration, existed before this challenge. Gatherwire itself is a new standalone WebMCP app created during the submission period. The public commit history documents the seven browser-facing contracts, isolated workspace, handoff ledger, visible mission and receipts, validation rules, tests, deployment, and documentation added for the challenge.

What's next

The next layer is a real, permission-aware project-agent bridge behind the same handoff contract. Organizations could connect their own apps and runtimes while keeping the interaction stable: discover context, select an authorized destination, publish a source-linked task, and follow its status from the shared workspace.

The longer-term goal is not another closed chat app. It is a modular context and handoff layer that helps existing web apps become safely usable by people and agents together.

Built With

Share this project:

Updates

Submission history