LINE-CALL

Human-controlled AI for live-event timing - keep every cue in line.

Comment

Inspiration

Live-event schedules are fragile. A two-second change to one segment can affect speakers, video, lighting, audio, downstream cues, and the final hard-out.

I wanted to explore a safer question: what if an AI agent could do the time-consuming reasoning without receiving unlimited control over the production interface?

LINECALL started as a human-operated run-of-show application. For the WebMCP Challenge, I extended it into an agent-native control surface where the agent can inspect the schedule, compare possible timing strategies, and prepare a precise change—but a person remains responsible for approving the final action.

The guiding idea became:

[ \text{Agent explores} \rightarrow \text{Rules verify} \rightarrow \text{Human approves} \rightarrow \text{Agent acts once} ]

What it does

LINECALL helps an AI agent reason about live production timing through a small set of structured WebMCP tools.

The agent can:

  • Read the current run, revision, locks, readiness, and constraints.
  • Compare a local segment move with a downstream ripple.
  • Prepare an exact cue-level preview.
  • Update low-risk cue readiness.
  • Apply a timing plan only after the human approves that exact plan.

The main demonstration begins at schedule revision R1. The user asks:

The audience Q&A needs to start two seconds later. Find the safest way to absorb that delay without breaking the run, and show me the exact change before anything moves.

LINECALL rejects the segment-only option because it breaks chronology. It identifies the safer downstream ripple and prepares a precise 13-cue change set.

The live schedule does not change immediately. The operator reviews the proposed result and approves that exact plan. Only then does the fifth WebMCP capability, linecall_apply_approved_retime, become available.

The agent applies the approved plan once. LINECALL advances the schedule from R1 to R2, displays a visible receipt, and removes the temporary apply capability.

The active tool lifecycle is therefore:

[ 4 \rightarrow 5 \rightarrow 4 ]

A second test asks the agent to move the Opening sequence. Cue Q014 is human-locked, so LINECALL blocks the change. There is no tool that allows the agent to remove the lock or approve its own request.

How we built it

LINECALL is built with React 19, Vite 8, modern CSS, the WebMCP Imperative API, and Node’s built-in test runner.

The WebMCP layer uses document.modelContext.registerTool to expose five purpose-built tools:

  • linecall_get_run_snapshot
  • linecall_compare_retime_options
  • linecall_preview_segment_retime
  • linecall_set_cue_readiness
  • linecall_apply_approved_retime

The tools use strict JSON schemas, explicit revision checks, deterministic plan IDs, and WebMCP trust annotations.

The schedule engine is deliberately separate from the language model. It owns:

  • Chronology validation.
  • Minimum spacing rules.
  • Hard-out enforcement.
  • Schedule revisions.
  • Human-owned cue locks.
  • Stale-plan rejection.
  • Exact approval binding.
  • One-time application receipts.

The agent helps reason about the available options, but the deterministic engine decides whether the resulting cue changes are valid.

The user interface was also designed around two different needs. Operators see a dense, human-friendly cue score with timing, readiness, locks, conflicts, approval state, and receipts. Agents receive a semantic tool interface instead of having to guess what buttons or page elements mean.

I added focused agent evaluation cases covering direct inspection, safe retiming, exact-plan application, locked-cue refusal, missing unlock authority, readiness updates, and unrelated questions where no LINECALL tool should be selected.

Challenges we ran into

The hardest challenge was designing useful agent authority without making the agent dangerously powerful.

It was not enough to reject an unsafe call after it happened. The interface needed to make unavailable authority genuinely unavailable. That is why the apply tool does not appear before approval, appears only for the approved plan, and disappears immediately after use or invalidation.

State management was another major challenge. A plan prepared at revision R1 must not be accepted after the schedule has changed. Every timing mutation therefore carries both an exact plan ID and an expected revision.

The schedule rules also had to handle more than simple arithmetic. A timing change can create chronology conflicts, spacing violations, hard-out failures, or collisions with human-locked cues. The system needed to explain those conflicts clearly enough for both the agent and the operator.

WebMCP browser support is still a new area, so verification required more than checking that JavaScript functions existed. I tested registration, discovery, tool schemas, handler behavior, the visible interface, and the complete approval lifecycle in a real Chromium production build.

I also had to make sure the browser evidence process did not modify the project while the project was being fingerprinted for verification. That required separating temporary browser artifacts from the source tree and tightening the build-input checks.

Accomplishments that we're proud of

The biggest accomplishment is that LINECALL demonstrates a complete collaboration loop rather than a simple tool-call demo:

  1. The agent reads the current state.
  2. It compares multiple futures.
  3. Deterministic rules reject the unsafe option.
  4. The agent prepares an exact preview.
  5. The human reviews and approves it.
  6. The agent applies that exact plan once.
  7. The system advances the revision and leaves evidence.
  8. A separate locked request is refused.

The project has:

  • 30/30 passing tests.
  • A passing production Vite build.
  • A passing Chromium production interaction rehearsal.
  • WebMCP contract and discovery tests.
  • Agent tool-selection and call-order evaluations.
  • A permanent HTTPS deployment.
  • Seven replayed challenge cases with matching expected calls and arguments.
  • An MIT open-source license.
  • A complete illustrated README and narrated demonstration video.

We are especially proud that human approval changes the browser-visible capability surface itself. Approval is not just a message or a modal. It changes what the agent is technically able to call.

What we learned

We learned that semantic tools are much more useful than exposing a general-purpose interface and asking an agent to guess how it works.

A tool such as linecall_compare_retime_options gives the agent a meaningful domain operation. It communicates intent, inputs, constraints, and results directly. That is clearer and safer than asking the agent to click through a timetable.

We also learned that safety should be represented in the capability model whenever possible. A missing tool is stronger than a tool that is always available but usually refuses.

Another important lesson was that language models and deterministic systems are good at different things. The model is useful for interpreting a request and comparing alternatives. The schedule engine is better at enforcing exact rules. Keeping those responsibilities separate makes the whole system easier to test and trust.

Finally, we learned that a convincing WebMCP project needs three kinds of proof:

  • The tools are correctly defined.
  • The product works in a real browser.
  • The authority boundaries behave correctly over time.

What's next for LINECALL

The next step is to connect LINECALL to real production systems and live event workflows rather than the controlled challenge schedule.

Planned directions include:

  • Adapters for existing rundown, show-control, and scheduling systems.
  • Team-based approvals with named operators and audit trails.
  • More detailed resource checks across audio, video, lighting, and stage departments.
  • Multi-event support for conferences, theatre, broadcast, live streams, and awards shows.
  • Durable change history with replayable receipts.
  • Additional WebMCP-compatible agent hosts and browser environments.
  • More advanced planning tools while preserving the same human approval boundary.

The goal is not to give an agent unrestricted control of live production. The goal is to make the agent genuinely useful while ensuring that people remain in charge of consequential decisions.

Built With

  • ai-agents
  • automation
  • chrome-devtools-protocol
  • css
  • html
  • human-in-the-loop
  • javascript
  • live-events
  • mcp
  • node.js
  • openai
  • production-management
  • react
  • safety-critical-systems
  • schedule-management
  • vite
  • web-apis
  • webmcp
  • workflow-automation
Share this project:

Updates

Submission history