Runline

Runline helps people and browser agents repair live events and recurring timetables together—while humans keep the final say.

Comment

Inspiration

Live events run on shared commitments: speakers, rooms, capacity, timing, and moments that cannot move. A delayed speaker turns a tidy schedule into a coordination problem. We wanted a browser agent that could work on those real constraints alongside the organizer, instead of offering suggestions in a disconnected chat window.

Why WebMCP

This workflow needs more than a chatbot that describes a schedule. The agent must discover the application's domain operations, read the same saved state the organizer sees, use stable IDs, preserve hard constraints, and hand a concrete proposal back to the human interface. WebMCP makes Runline's existing web application the shared workspace: there is no duplicated agent dashboard, separate MCP server, or simulated transcript to keep in sync.

What it does

Runline is an event scheduling control room with a shared human-agent workflow. Report a delayed speaker, unavailable room, or attendance spike. The browser agent reads the actual schedule and constraints, then requests a repair or submits its own move proposal. The organizer compares the proposed schedule with the saved one. Every speaker whose session would move must confirm before apply; a decline or organizer rejection searches for a distinct next-best plan.

Locked sessions stay protected. Every applied repair is revalidated against room and speaker availability, capacity, event hours, lunch and turnover. New edits invalidate old proposals, and undo preserves the recorded disruption so the original problem does not disappear from the history.

The demo includes persistent browser-isolated workspaces, session editing, event configuration, JSON and timetable CSV import, CSV/ICS/JSON exports and an activity trail. It supports both single events and reusable weekly templates. A one-week edit is stored as a dated exception and automatically gives way to the normal template in the next week; a permanent edit updates future weeks. All sample people and events are fictional.

The underlying model is reusable beyond conferences. A college can represent lecture halls, auditoriums, classrooms, and sports grounds as locations, then schedule classes, matches, rehearsals, ceremonies, and workshops across a repeating week. Wedding halls and other bookable venues use the same capacity, availability, conflict, protection, consent, exception, and alternative-plan workflow. Runline does not claim to be a complete booking system; alternating-week rotations, semesters, equipment, payments, authenticated roles, and notifications are future work.

How we built it

Ten imperative WebMCP tools expose real application operations in the page. They use the same state transitions as the React interface, backed by a Cloudflare Worker and D1. Browser agents need neither a separate MCP server nor an application-owned LLM key.

A bounded deterministic search generates repair candidates; the browser agent supplies intent, chooses trade-offs, and can author custom proposals. Proposal signatures are remembered per schedule revision, so a rejected retry cannot simply return the same set of moves. The server performs the final validation, verifies every affected speaker is confirmed, and makes an atomic version-guarded write. The tool surface intentionally stops at requesting approval and contains no apply, consent-recording or unlock tool.

Challenges

The difficult part was making human and agent edits coexist safely. A proposal can become obsolete between generation and approval, and "try again" is useless if a deterministic solver repeats the same answer. Runline separates workspace versions from schedule revisions, makes stale proposals visible, rejects conflicting concurrent writes, and excludes prior same-revision plan signatures. Another challenge was translating shared impact into a clear consent rule without overstating identity: the demo records responses, while authenticated speaker approval remains future work.

Accomplishments

The project implements an end-to-end persisted repair workflow, with regression checks for disruptions, hard constraints, locks, distinct alternatives, affected-speaker consent, weekly exceptions, permanent future changes, undo, stale writes, workspace isolation, exports and the real WebMCP handler chain. A delayed-speaker fixture produces a two-session repair without moving either locked session. The interface shows every proposed change and its trade-offs, blocks apply until all affected speakers confirm, and turns a decline into another plan search.

What we learned

WebMCP is most useful when tools are designed around the application's domain, not around arbitrary clicks. Small structured reads, stable IDs, explicit errors and carefully separated proposal, consent and apply steps make the agent's work inspectable by the people it affects. The browser context becomes shared working state rather than another data copy to synchronize.

What's next

Authenticated participant accounts or signed confirmation links, outbound notifications, production role authorization, stricter human-presence approval, rate limiting, scheduled retention cleanup, alternating-week and semester calendars, equipment and payment workflows, external calendar synchronization and broader solver evaluations are future work, not claims about this demo.

AI assistance

The implementation, documentation and test suite were built with OpenAI Codex and ChatGPT assistance. The social preview artwork was AI-generated, and the public demo video uses Deepgram Aura-2 Orion synthetic narration with an on-screen disclosure. The running application does not contain an embedded LLM or simulated AI conversation: it exposes actual WebMCP tools to a compatible browser agent.

Built With

Share this project:

Updates

Submission history