DOMHamster

A human-in-the-loop AI dispatcher that helps coordinate volunteers without taking control away from the coordinator.

Comment

Inspiration

AI agents are getting better at using websites, but many of them still have to guess what a page means from buttons, labels, and layout.

That is usually fine for simple tasks. It becomes a problem when the agent is working with schedules, approvals, private information, or decisions that a person has already made.

I wanted to explore a workflow where the agent could still do useful work, but where important decisions stayed clearly under human control. That idea became DOMHamster, a volunteer-dispatch demo built around WebMCP.

What DOMHamster does

DOMHamster helps coordinate a fictional, non-emergency volunteer operation with eight requests and five available volunteers.

The agent can use WebMCP tools to:

  • Read the current requests, volunteers, assignments, and audit history
  • Create a complete assignment draft
  • Check whether the draft is valid
  • Repair scheduling conflicts
  • Prepare a specific draft version for human review
  • Commit the plan after the coordinator approves it
  • Request one contact record when it is actually needed
  • Review a sanitized history of important actions

The agent does not have permission to do everything.

It cannot approve its own draft, override a locked human decision, reset the application, or freely access every contact record. Those actions remain controlled by the person using the interface.

How the demo works

The agent starts by reading the current coordination data and creating a full assignment draft.

The coordinator then changes request R-105 from volunteer V-01 to V-03 at 1:00 p.m. and locks that choice.

This creates a scheduling conflict with R-106.

Instead of replacing the coordinator's decision, DOMHamster blocks approval and explains what went wrong. The agent is then asked to repair the plan while preserving the locked assignment.

The repair keeps R-105 exactly as the coordinator selected it and moves only the conflicting request to another available volunteer.

Once the draft is valid again, the agent prepares that exact version for review. The coordinator must approve it through the interface before the agent receives permission to commit it.

The commit can only be used once. After the plan is committed, the commit capability disappears, and a repeated attempt is rejected.

Contact information is also restricted. The agent can request the contact for one specific assignment only after the plan has been committed. The audit history records that contact access happened, but it does not copy the sensitive contact value into the log.

Finally, the coordinator can reset the scenario and return it to the original READY state.

How I built it

I built DOMHamster as a state-driven web application and exposed its agent capabilities through the native document.modelContext WebMCP interface.

The project includes 12 structured WebMCP tools. Each tool has:

  • A clear purpose
  • Structured inputs and outputs
  • State requirements
  • Predictable error responses
  • A JSON Schema contract

The available tools change depending on the current application state.

For example, the commit tool is not available before human approval. Contact access is not available before the plan is committed. After a successful commit, the commit tool is removed so it cannot be used twice.

I also tied approvals and mutations to the current draft version. This prevents an approval from being reused after the underlying plan has changed.

I tested the tools with the ChatGPT browser extension, as well as Google Chrome with WebMCP enabled. I also used Playwright and the Chrome DevTools Protocol to test tool registration, state changes, invalid actions, and replay protection.

The application was built with TypeScript, JavaScript, HTML, and CSS, and deployed with Netlify. I used Remotion and FFmpeg to create and edit the project video.

Challenges I faced

The hardest part was keeping the WebMCP tool surface synchronized with the actual application state.

A tool may be valid in one state but unsafe or meaningless in another. I had to make sure tools appeared and disappeared at the correct time, and that invalid or outdated actions failed in a clear and predictable way.

Other challenges included:

  • Preventing a stale draft from being committed
  • Preserving human-locked assignments during an agent repair
  • Making approval apply to one exact draft version
  • Keeping commit authorization short-lived and single-use
  • Rejecting repeated or out-of-order actions safely
  • Restricting contact access until after commitment
  • Recording useful audit events without exposing contact information
  • Resetting the full scenario back to the same starting state for repeated testing

Creating the demo video was also more difficult than expected. I had to keep the narration, subtitles, screen states, and timings aligned while still making the workflow understandable to someone seeing the project for the first time.

What I learned

The biggest thing I learned is that giving an agent more tools does not automatically create a better experience.

What matters is giving it the right tool at the right moment.

Tool availability can work as part of the permission model. Instead of exposing every action all the time and relying only on written instructions, the application can remove capabilities that are not currently allowed.

I also learned that approval is much safer when it is tied to a specific version. A general “yes” is ambiguous if the draft changes afterward. Approving an exact visible version creates a much clearer connection between what the person reviewed and what the agent is allowed to execute.

Most importantly, the human-agent experience feels more trustworthy when the agent handles the repetitive coordination work, while important decisions remain visible and controlled through the interface.

What's next

The next step would be to test DOMHamster with more agent clients and expand the scheduling rules beyond the current deterministic scenario.

I would also like to add server-backed authentication and authorization, improve accessibility, and explore how the same approval pattern could work in other coordination tools where agents need to act without silently taking control away from people.

Built With

Share this project:

Updates

Submission history