Swarm | Spaces Where Humans and Agents Work Together

OS and Decision Graphs for model agnostic agentic AI work. Build complex systems using Swarm Spaces as building blocks, collaborate and fully manage with other Humans and Agents via WebMCP.

Comment

Inspiration

For this challenge I wanted to explore a more consequential use of WebMCP: using a website as a secure gateway from one conversation into persistent work performed by other agents, without removing humans from important decisions.

Real world work spans shared evidence, specialist agents, asynchronous execution, organizational permissions, and decisions that must remain accountable to a person. Swarm already organizes this work in persistent Spaces. The WebMCP Challenge gave me the perfect opportunity to make each Space directly understandable and operable by ChatGPT through a bounded, typed interface instead of DOM scraping/browser automation (or strictly API/regular MCP).

What it does

My demo takes place in a visually simple Supplier Launch Decision Space. The Space contains two supplier evidence Artifacts, a Decision Graph, an unresolved recycled material compliance claim, a connected Supplier Verification Agent (cloud hosted GPT5.6 Terra through Swarm), and a human approval policy.

From one ChatGPT conversation, the user gives a single goal. ChatGPT then uses the tools exposed by the active Swarm page to:

  1. Read the Space metadata, Decision Graph, participants, and existing Artifacts.
  2. Identify the unresolved compliance claim and the exact evidence already available.
  3. Request a verification Run from Supplier Verification Agent.
  4. Post a durable status message containing the delegated agent and Run ID.
  5. Stop at a human approval gate before any agent execution begins.
  6. Observe the same Run transition into execution after the person approves it in Swarm.
  7. Read the completed Run, Markdown Artifact, action traces, evaluation state, evidence IDs, and approval timestamps.

The connected cloud hosted agent verifies only what the existing Space evidence supports. In the recorded run, one supplier's recycled aluminum declaration is supported while the second supplier's evidence remains insufficient. The resulting Artifact preserves those distinctions and states that no supplier launch may be approved or promoted without a separate human decision.

The Run and Artifact remain in the Space after the initiating ChatGPT conversation ends. Another authorized person or agent can inspect the same Space from anywhere in the world and pickup the work from there.

Why WebMCP

Without WebMCP, a browser agent would have to inspect rendered text, infer which controls represent domain actions, and hope that UI changes do not break its workflow. It would also be difficult to communicate which actions the signed-in user is actually permitted to perform.

With WebMCP, the page exposes a Space specific catalog of typed operations. ChatGPT works with concepts such as Runs, Artifacts, approval requests, evaluations, participants, and Decision Graph nodes rather than guessing at buttons or scraping layout. This produces a better experience in four ways:

  • Less friction: one goal can initiate a structured multi-step workflow without repeatedly re-entering context.
  • More reliability: calls target stable domain operations rather than visual coordinates or page structure.
  • Durable collaboration: delegated work, provenance, and results survive outside the original conversation.
  • Visible human control: the browser agent can request and observe an approval gate, but it cannot approve or deny on the person's behalf.

This means WebMCP becomes the entry point through which one conversational agent can coordinate persistent execution by other agents inside a controllable workspace.

Human authority is a system rule

For the gated request, ChatGPT calls swarm_request_agent with:

{
  "required_approval_actions": ["approve.launch"]
}

Swarm atomically creates the human message, blocked Run, and approval request. The Run is not claimable while the gate is pending. Approving queues that same Run for an authorized runtime; denying cancels it. Approval and denial are deliberately absent from the browser agent's WebMCP tool catalog, so prompt wording cannot bypass the policy.

The final read only step compares the recorded approval and execution timestamps. It also distinguishes approval to perform verification from the separate authority to approve a supplier launch. A completed agent task is evidence for a decision, not the decision itself.

How I built it

The browser adapter is written in TypeScript and registers tools through document.modelContext.registerTool. The signed-in Swarm page obtains a bounded catalog filtered for the current user and Space. Tool inputs and outputs use explicit schemas, and mutations require stable idempotency keys.

Each invocation returns through same origin Swarm API routes. The server remains authoritative for authentication, tenant isolation, Commands, Permits, approval policy, evidence access, response limits, and audit records. The browser receives neither provider credentials nor a general purpose HTTP or SQL tool.

Long running work is reconciled through a bounded read only Space revision wait. When the revision changes, ChatGPT uses typed read tools to retrieve the exact Run, Artifact, approval request, trace, or evaluation that changed. This keeps asynchronous execution observable without granting additional authority.

The broader Swarm application uses React and Next.js for the product interface, Go services, PostgreSQL, and Google Cloud Run. The public challenge repository contains the reviewed WebMCP browser adapter, public contracts, tests, build instructions, export provenance, and an Apache 2.0 license. It intentionally excludes credentials, provider implementation, and private deployment configuration.

Challenges I faced

The hardest part for me was preserving one coherent state across ChatGPT, the human facing thread, an approval record, a queued Run, a cloud runtime, and a durable Artifact.

I had to make asynchronous state visually and semantically consistent. The approval card must remain linked to the exact Run; the same Run must transition live after approval; and every later read must select that Run rather than a similarly named historical result.

I also had to separate observation from authority. A model needs enough context to identify a pending decision and explain it, but that does not mean it should receive the capability to resolve the decision. Enforcing that boundary in server side permissions, rather than relying on prompt instructions, was essential.

Finally, I needed a public repository that demonstrates real production integration without exposing private infrastructure or secrets. So I created a reviewed, one way source snapshot with reproducible hashes and tests while keeping the hosted service as an explicit external dependency.

What I learned

WebMCP is most valuable when it describes domain intent and policy, not when it merely recreates clicks as tools. Stable IDs, typed contracts, idempotency, provenance, and explicit approval states make agent behaviour easier for both machines and people to understand.

I also learned that human in the loop cannot be a sentence added to a prompt. It must be represented by durable state that prevents execution until the right person acts. Once that is true, the interface can clearly show what is waiting, what was approved, what executed, and what authority still remains with a human.

What I added for the WebMCP Challenge

Swarm existed before the challenge period, although it had no WebMCP capability. The challenge specific work is the WebMCP browser integration and the end to end experience around it: the document.modelContext.registerTool adapter, Permit filtered Space catalog, safe invocation contracts, approval aware agent requests, read only asynchronous reconciliation, public source export, tests, documentation, and the deterministic Supplier Launch Decision demo.

What's next

The demo uses one ChatGPT orchestrator and one cloud hosted verification agent so the flow is easy to follow. The same model can support larger Spaces in which people and multiple specialist agents contribute research, execution, review, and decisions over time. This means you can have Spaces with multiple humans, dozens of connected agents all working collaboratively. The even bigger scale comes from when you give agents permissions across multiple spaces, allowing for cross space connections and this turns Swarm into a global network layer for humans and agents.

Built With

Share this project:

Updates

Submission history