Quorum

Inspiration

Group scheduling is a negotiation over everyone's constraints - and it's still done by making humans click checkboxes in polls. When WebMCP launched, we realized the missing piece was never a smarter poll: it was letting each person's AI agent join the negotiation itself. Quorum is our answer: scheduling, negotiated by your agent - approved by you.

What it does

Quorum is a meeting scheduler where humans and agents are equal participants in the same live session. Humans get a normal UI: candidate times, yes/maybe/no voting, counter-proposals. Agents get seven WebMCP tools registered by the page itself - they can read the event state, join on their human's behalf, vote with reasons, counter-propose new times, and rank the slots. Every action lands in a shared negotiation log tagged HUMAN or AGENT, and only the human organizer can accept proposals or lock in the final time. Agent proposes; human approves.

Why this is a strong fit for WebMCP

Scheduling is a multi-step, stateful interaction - exactly where screen-scraping agents fail. With WebMCP, the page tells agents what's possible via typed, self-describing tools. In testing, an agent that had never seen the app correctly chained four tools on the first try (read state -> join -> vote with a conflict note -> report the winner) purely from the tool descriptions.

What people and agents can do together that wasn't possible before

A mixed negotiation - some parties human, some agents - on the same page, in real time, with full mutual visibility. Before WebMCP, agents couldn't reliably operate voting UIs built for humans, and sites had no way to declare what actions they support. Quorum shows the new shape of the open web: agents handle the tedium, the audit trail keeps trust, and humans keep the final word.

How we built it

Vanilla JS frontend + Express backend, live-synced over server-sent events. Every WebMCP tool executes the same functions the human UI uses, tagged via: "agent" - one code path, one audit trail:

document.modelContext.registerTool({
  name: "submit_availability",
  description: "Submit availability for candidate slots on behalf of your user…",
  inputSchema: { type: "object", properties: { responses: { type: "array" } }, required: ["responses"] },
  execute: async ({ responses }) => submitAvailability(responses, "agent"),
});

Deployed on Vercel; Upstash Redis keeps event state consistent across serverless instances, with a per-stream Redis poll so every open tab stays live. The visual design was created in Claude Design and implemented as a hand-written design system.

 Challenges we ran into

- Serverless broke our state. Events lived in memory; on Vercel, an SSE stream landed on a different instance and couldn't find the event. We added a storage layer (Upstash Redis in production, in-memory locally) and cross-instance live updates via polling.
- The WebMCP API surface is still moving (document.modelContext vs the earlier navigator.modelContext), so we wrote a small adapter that registers against whichever exists.
- Tool descriptions are prompts. Agents chained our tools correctly only after we rewrote descriptions to say when to call each tool and what to fetch first.

 Accomplishments that we're proud of

- **A never-before-seen agent used our app correctly on the first try.** In our final test, a Gemini-backed agent autonomously chained four tools - read the event state, joined as a new participant, voted with a conflict note attached to the right slot, and reported the winning time - guided by nothing but our tool descriptions. That's the whole WebMCP promise, working.
- **One code path for humans and agents.** Every WebMCP tool executes the exact same functions the human UI calls - so the audit log, validation, and permissions are identical no matter who acts. No parallel "agent API" to drift out of sync.
- **Trust as a first-class feature.** The negotiation log tags every action HUMAN or AGENT in real time, organizer-only tools are genuinely scoped, and an agent can never finalize a meeting on its own.
- **A one-click seeded demo event**, so any judge can see a mid-negotiation session - votes, an agent counter-proposal, a live log - in under ten seconds, then take over as the organizer.
- **Shipping the full journey in days**: idea -> working local app -> designed UI -> deployed on Vercel with Redis-backed state that survives serverless cold starts.

 What we learned

- **Tool descriptions are prompts.** Agents started chaining our tools correctly only after we rewrote descriptions to say *when* to call each tool and what to fetch first ("Call this first to understand the current state"). Designing for a model reader is a real skill, and WebMCP makes it part of frontend work.
- **The trust problem matters more than the automation problem.** The feature people react to isn't that agents can vote — it's seeing exactly what an agent did on your behalf, and knowing the final decision always needs a human.
- **Serverless changes your assumptions.** Our in-memory state worked perfectly until the first live SSE request landed on a different instance. Moving to Redis-backed storage with cross-instance live updates taught us to design for "any request, any instance" from the start.
- **Build for a moving standard defensively.** WebMCP's surface has shifted between Chrome previews (`document.modelContext` vs `navigator.modelContext`), so a small adapter layer saved us from breaking on every browser update.

 What's next for Quorum

- **Calendar integration**, so your agent votes from your real availability instead of being told your constraints.
- **Agent-to-agent negotiation rounds** - agents exchange counter-proposals automatically until they converge on a shortlist, and humans only see the final choice to ratify.
- **Invites addressed to agents**: send an event link straight to someone's assistant, which handles everything and pings its human only for approval.
- **Richer constraints in tools** - recurring meetings, time-zone fairness scoring, and "must attend / optional" roles that agents can reason about.

Built With

• chrome
• css3
• express.js
• gemini
• html5
• javascript
• node.js
• redis
• server-sent-events
• upstash
• vercel
• webmcp