WorkHub Goal Room

WebMCP lets the agent act; WorkHub keeps evidence, verification, and final authority separate.

Comment

WebMCP makes a website callable. WorkHub deals with what happens after the call: keeping the agent’s work tied to the right Goal, the right evidence, and the right human decision.

We built the missing control layer between an agent saying “I’m done” and a human safely accepting what it actually changed.

The problem we chose

Giving an agent a tool is the easy part. While building this, we kept finding the same tempting shortcut: if the agent can call the tool and the checker says PASS, the system wants to treat the job as finished. Goal Room refuses that shortcut.

The agent may have the right tool but stale state, the wrong Plan version, or evidence for different candidate bytes. A green check tells us that explicit checks passed. It does not prove the work is correct, and it does not give the checker authority to accept, merge, deploy, or release anything.

Goal Room puts those boundaries on the page instead of hiding them behind one vague “agent completed” message.

What the Goal Room demonstrates

The Goal Room is one browser-local, synthetic software-release Goal shared by three distinct actors:

  • Agent: moves work forward through six narrow WebMCP tools;
  • System Verifier: records deterministic PASS or FAIL for the exact candidate;
  • Owner: confirms Goal and Plan scope and makes the final acceptance decision.

The page registers exactly six browser-native Agent tools:

  1. get_goal_room_state
  2. propose_goal_contract
  3. propose_plan
  4. claim_step
  5. submit_artifact
  6. request_completion

There is deliberately no Agent tool for Owner confirmation, System-verdict authorship, or final acceptance.

The journey begins with owner intent. The Agent proposes Goal Contract v1; the Owner requests a revision and confirms immutable v2. The Agent proposes a Goal-bound Plan v1; the Owner revises and confirms v2. Only then can the Agent claim the admitted step and submit Candidate v1.

Candidate v1 fails deterministic verification and remains in the append-only history. The Agent submits corrected Candidate v2, which passes. The Agent can then request completion—but the room still stops at the Owner.

PASS does not mean accepted. The Owner accepts only the exact candidate version and SHA-256 shown in the confirmation dialog. The final S14 room is sealed: current actor none, no controls, and no legal continuation.

The architecture

The architecture separates four jobs that agent systems often blur together:

  1. WebMCP tool surface: lets the Agent read, propose, claim, submit, and request.
  2. Governed kernel: rechecks exact input shape, state version, idempotency, Goal/Plan/step binding, candidate digest, evidence, and the current legal frontier.
  3. System Verifier: records deterministic findings for the bound candidate but cannot change the candidate or accept the Goal.
  4. Owner UI: confirms scope and retains the final exact-candidate decision.

That separation is the product. The Agent can advance the work without inheriting every power in the room.

What we added after the frozen demonstration

Agent Change Assurance (ACA) is genuine post-demo engineering. It is not presented as part of the frozen Goal Room demonstration.

The original Goal Room demo stops at synthetic release metadata on purpose. That keeps the authority model small enough to inspect, but it leaves an obvious next problem: real code changes are messier. ACA is our bounded answer. It checks whether an agent’s claim about a real local code change matches what Git and isolated checks actually show.

On an explicit local observation, ACA can:

  • bind the observation to an exact commit, tree, base, diff, and working-tree inventory;
  • compare what the agent says changed with the files and evidence actually observed;
  • run admitted unit and build checks in a provider-free isolated sandbox;
  • handle failure, mismatch, cancellation, source movement, timeout, and cleanup paths;
  • produce a digest-linked, point-in-time evidence receipt for review.

The public repository contains the merged nine-commit ACA chain in PR #1. The successor video shows the real local ACA run and its evidence receipt after the Goal Room demonstration.

The important boundary is still visible: Authority: NONE. ACA did not post a GitHub comment or review, create a native Check, approve the pull request, merge it, deploy it, or release anything. Passing checks are evidence for a later decision, not the decision itself.

What we proved

In the demonstrated Goal Room

  • Chrome Canary natively returned the exact six RegisteredTool descriptors.
  • Calls used the browser testing path getTools() → executeTool(tool, JSON.stringify(input)).
  • The same governed state is reflected in the Agent calls, Owner UI, System findings, and receipts.
  • Failed Candidate v1 remains visible after corrected Candidate v2 passes.
  • PASS leaves final acceptance pending.
  • Only the Owner accepts the exact verified candidate.

No autonomous model selected tools in this recorded native evidence.

In the post-demo ACA work

  • The public ACA implementation and its authority limits are reviewable in the merged PR.
  • A real local, point-in-time run bound one exact Git candidate to its base, tree, diff, manifest, policy, and isolated-check evidence.
  • Unit and build checks passed in the qualified sandbox, with cleanup confirmed.
  • Deliberate failure, mismatch, cancellation, and source-movement paths were also exercised.

This is evidence of one bounded implementation and one bounded local run. It is not a claim of production security, hostile-environment attestation, repeated model reliability, or autonomous release authority.

What was hard—and what we learned

The hardest bug was authority leaking across layers. The UI wanted to be helpful. The verifier wanted to sound conclusive. The evidence package wanted to tell a neat success story. Any of those could accidentally turn “the checks passed” into “the work was accepted.”

We kept coming back to one rule:

Tool access, evidence, verification, and acceptance are four different events.

Human control means very little if the approval button is attached to a vague status. It becomes useful when the decision is attached to exact state and exact evidence.

Scope and limits

The demonstrated Goal Room is one synthetic, browser-local Goal. Reloading starts a fresh room. It has no accounts, backend persistence, database, credentials, production effects, payment, messaging, deployment, or release action.

ACA is a separately labeled local engineering extension. Its public static view cannot observe a judge’s local repository or run the sandbox. The evidence shown in the video is a recorded point-in-time local run, not a live provider-backed service or continuing monitor.

How to judge it

  1. Open the frozen Goal Room WebMCP app in a qualifying WebMCP browser.
  2. Confirm exactly six Agent tools and the absence of Owner, verifier, acceptance, deployment, or release tools.
  3. Follow Goal revision, Plan revision, Candidate v1 FAIL, Candidate v2 PASS, completion request, exact-candidate Owner acceptance, and sealed S14.
  4. Watch the successor video: Goal Room first, then the clearly labeled post-demo ACA extension.
  5. Inspect the public source and merged ACA PR for the implementation, checks, commit chain, and permanent authority exclusions.

Project links

Built With

Share this project:

Updates

Submission history