OpsRelay

The dispatcher stays in control. The agent handles the coordination.

OpsRelay is a shared dispatch workspace for a human operator and a WebMCP agent. It turns a disrupted field-service schedule into a visible proposal, a deliberate human decision, and worker handoffs built from the approved result.

Built for the OpenAI WebMCP Challenge. This is a local-first, open-source portfolio prototype. The hosted preview is owner-only; public app access and competition submission are separate steps.

The optional Northstar sample and bundled Harbor CSV files contain fictional records. User workspaces can be created manually or imported; use synthetic data for this prototype. OpsRelay is a portfolio and competition prototype and is not represented as a deployed customer system.

New views: worker handoffs · mobile dispatch · mobile handoffs. See the design QA.

Verified locally: all ten tools were invoked through native WebMCP in Codex's in-app browser. The run staged a visible proposal, blocked unapproved application, then applied the reviewed plan and generated three worker handoffs. The redesigned static production export also completed a job-linked request → agent revision → fresh approval workflow. The current workspace release adds validated CSV import, manual record editing, unassigned/deferred states, safe backup/restore and approval/handoff invalidation. Its test and native browser evidence is in workspace-verification.md. See the verification record for evidence and remaining native keyboard and submission checks.

The problem

A small service team can begin the day with a reasonable schedule and lose it to one unavailable worker. Customer windows, specialist skills, urgent work, and missing access details make reassignment more complicated than moving a card.

OpsRelay's intended audience is a small field-service business with a dispatcher coordinating a handful of workers. Its hypothesis is that structured agent assistance could reduce the effort of diagnosing and preparing schedule changes. That is a product hypothesis, not a measured saving or a claim of customer adoption.

The seeded demonstration contains six synthetic jobs and a deliberately disrupted day: an unavailable worker, overlapping appointments, urgent work, a skill mismatch, missing access information, and a fixed customer window.

Why WebMCP belongs here

The agent works with the same operational state the dispatcher sees. It can read job constraints, inspect worker capabilities, find conflicts, and stage an explicit proposal through structured tools. The proposal appears in the app, where the dispatcher reviews its consequences before applying it.

WebMCP is the application's agent interface—not a chat panel or a second schedule hidden in a conversation. There is no OpenAI API key or in-app model dependency. The normal interface supports the complete workflow without an agent.

1. Inspect: the agent reads jobs and workers and checks operational issues.
2. Propose: it stages assignments and a rationale; the active board remains unchanged.
3. Refine: the dispatcher requests a change on a specific visit. The agent answers the note in its next proposal; the old approval is invalidated.
4. Decide: compare Current and Proposed views, inspect the changes, and approve in the app.
5. Apply: the application accepts only a currently approved, valid plan.
6. Handoff: the agent generates worker instructions from the applied schedule. The activity log records the sequence.

Hosted preview

Open OpsRelay on ChatGPT Sites. The first deployment is private to the owner, not yet available to judges. All ten native WebMCP tools and the revision/approval/handoff workflow were verified on this hosted origin through Codex's in-app browser. A separate ordinary ChatGPT conversation remains the next demonstration. See hosted verification.

Workspace capabilities

• Start empty, create a team/day, or load an explicitly labeled fictional sample.
• Import two CSV files (or paste CSV), review the preview, and confirm replacement. Up to 10 workers and 20 visits. Format reference.
• Add/edit visits and workers in Jobs & details and Team. Record confirmed access without auto-dispatching held work. Cancel visits or remove unassigned workers with confirmation.
• Unassigned visits need a plan; missing-information visits may be held; other deferrals require the dispatcher's reason and remain visible.
• Fact edits invalidate pending approvals and clear old handoffs. Fixed appointments retain their start; a dispatcher lock also protects the worker.
• Download/restore workspace backups. Restore retains history but never revives pending approval or current handoffs.
• One browser-local workspace, one active day, one active tab. No travel-time calculation, automatic sending, shared account database or production authorization.

The complete 2:45 recording kit includes synthetic files, screen actions, narration, prompts, rehearsal and submission checks. No tutorial is embedded in the product.

Run locally

Use Node.js 24 or newer and npm; a supported LTS release is recommended. .nvmrc selects Node.js 24. The exact project dependencies are pinned in package-lock.json.

cd opsrelay
npm ci
npm run dev

Open the local dashboard. No account, API key, environment file, database, or paid service is required. Create a workspace with its own team/date, import CSV files, or load optional fictional sample data. All times refer to the active workspace day and local team time.

The browser stores workspace changes locally for this origin. A different browser profile or origin has a separate workspace. Use one active OpsRelay tab; V1 does not coordinate concurrent edits across tabs. If browser storage is blocked, the app shows a notice and changes last only for that page session. Use Workspace → Download workspace backup before replacing your day. Workspace → Load sample data restores the fictional Northstar example after confirmation. Import schedule previews CSV rows and rejects malformed files without partial replacement. Do not enter real operational data.

For a local production check:

npm run build
npm run start

Try the human workflow

1. Read the schedule and operational alerts. Open a job to inspect its requirements, customer window, and assigned worker.
2. Review worker skills and availability.
3. Choose Prepare a plan. Choose assignments and start times, and keep work with missing required information on hold instead of inventing the missing detail. Load suggested plan offers a deterministic scheduling helper; it is not an AI response.
4. Choose Stage plan for review. Confirm the review panel changes while the active schedule does not.
5. Toggle Current / Proposed to compare the day. Use Request changes to attach a note to a visit; the next proposal must answer it. Review assignment changes, validation results, unresolved warnings, and the rationale. Choose Reject or Adjust proposal if needed. In job details, Lock assignment preserves the worker and start time; changing this constraint invalidates a pending or approved proposal, so prepare a new one.
6. Check the acknowledgment that you reviewed the assignments and held jobs, then choose Approve plan. Approval is separate from applying the plan.
7. Choose Apply approved plan, then Generate handoffs. Download a text copy or print the handoffs, and inspect Activity. Nothing is sent to workers.
8. Reload the page to check persistence, then reset the demo for another run.

The ordinary workflow is also the fallback when WebMCP is unavailable. A compatibility notice is not evidence that an agent invoked a tool.

Use a supported WebMCP agent

The challenge documentation identifies ChatGPT's in-app browser and WebMCP-enabled Chrome as test environments. For local Chrome testing, enable chrome://flags/#enable-webmcp-testing and relaunch Chrome, following Chrome's setup instructions. Browser support is experimental and can change.

1. Start the app and open its URL in the supported browser. Reset the demo.

2. Check that the app reports WebMCP tools available. In a browser inspector, confirm all ten tool definitions are discoverable.

3. Ask the agent:

   Review today’s Northstar schedule. Identify scheduling conflicts, unavailable workers, skill mismatches, urgent jobs, and missing information. Do not change the schedule yet.

4. Ask:

   Propose the safest revised dispatch plan. Preserve fixed customer windows and stage the plan for my review. Do not apply it.

5. Check the pending plan in the application. Before approving, invoke apply_approved_dispatch_plan with that plan's ID: it must return an error and leave the schedule unchanged. This is a negative test, not a request to bypass approval.

6. Review and approve the plan yourself in the app. If you reject it or change constraints, have the agent stage a fresh proposal.

7. Ask:

   Apply the plan I approved in OpsRelay, then generate the worker handoffs. Summarize any work still on hold.

8. Confirm the board, handoffs, and activity log reflect the same result. Record the browser/version, tool outputs, and visible state changes in the verification record.

A mock tool registry or direct function call tests the adapter; it does not prove supported-browser WebMCP interoperability. See the verification record for the evidence actually collected.

Tool surface

Each tool has a focused description, JSON Schema input, and structured result. Tools use application validation rather than relying on instructions in the agent prompt.

Tool	Input	Purpose / effect
list_jobs	Optional date	Read jobs, requirements, priorities, windows, and assignments; no schedule change
get_job	jobId	Read one job's complete operational details; no schedule change
list_workers	Optional date	Read skills, availability, and assignments; no schedule change
find_operational_issues	Optional date	Detect operational conflicts and urgent-job timing issues; no schedule change
get_dispatch_feedback	{}	Read job-linked notes and the responses required for the next proposal
stage_dispatch_plan	expectedRevision, complete assignments, rationale, feedbackResponses when required	Validate and display a pending proposal; no schedule change
get_pending_dispatch_plan	{}	Read current proposal, approval status, and validation results
apply_approved_dispatch_plan	planId	Update the schedule only after human approval and revalidation
generate_worker_handoffs	{}	Create ordered instructions and warnings from the applied schedule; send nothing
get_activity_log	Optional limit from 1–50	Read recorded actions and results, newest first

For each note in get_dispatch_feedback.open, include {feedbackId, response} in feedbackResponses. A replacement must answer notes again until an associated plan is applied. Missing, duplicate, and unknown note IDs are rejected. A note is task data, never permission to remove a hard constraint.

There is deliberately no approval tool. Inspection may add an activity event; it does not change assignments.

Tool inputs are strict: unknown fields, including actor and approval metadata, are rejected. Dates use YYYY-MM-DD. Scheduling times are integer minutes after midnight in the workspace day (540 means 09:00); they are not Unix timestamps.

A staged plan must include every job exactly once. A scheduled assignment is {jobId, action: "schedule", workerId, start}. Held work uses {jobId, action: "hold", workerId: null, start: null}. Deferred work uses {jobId, action: "defer", workerId: null, start: null} only when the dispatcher already deferred that visit with a reason. Agents cannot defer or reopen work themselves. Copy expectedRevision and IDs from a fresh read; preserve dispatcher locks and customer windows. Explain the changes and unresolved work in a 20–2000 character rationale.

Results contain ok plus either data or an error with a code and message. Each result also includes context: the workspace date, company, data source, local-time convention, current revision, valid job and worker IDs, and approval policy. Read ok before proceeding. An error is not authorization to remove a constraint or forge approval. Full schemas and adapters live in src/lib/webmcp.ts.

Architecture

flowchart LR
    Human[Dispatcher] --> UI[Next.js / React dashboard]
    Agent[Browser agent] --> MCP[WebMCP tools]
    UI --> Domain[TypeScript domain service]
    MCP --> Domain
    Domain --> Gate[Validate → stage → approve → apply]
    Domain <--> Repo[Repository abstraction]
    Repo <--> Local[Browser-local demo storage]
    Domain --> State[Shared state + activity log]
    State --> UI

Loading

The UI and WebMCP adapter share the same domain operations and repository. Validation belongs to the domain layer, so omitting a UI control does not remove the approval requirement from the tool path. React renders repository updates without requiring the agent to navigate away or ask the dispatcher to refresh.

V1 runs these rules in the browser. Next.js exports static HTML, CSS, and JavaScript to out/; no application server or database is required at runtime. The storage interface separates demo persistence from domain logic so a future authenticated service can replace it without putting scheduling rules inside React components.

The implementation follows the current WebMCP draft and Chrome imperative API documentation: named tools register with document.modelContext.registerTool(...) when supported. WebMCP is an experimental specification, not a finalized W3C standard.

Approval and safety

The supported application workflow is pending → human approved → applied. Staging only creates a proposal. Applying checks the plan's approval and validity; it does not accept an agent-supplied “approved” field as authorization. A rejected or stale proposal must be revisited before it can affect the board. Unresolved work must remain explicit in the review and handoffs.

This is an application workflow gate, not an authenticated security boundary. V1 has no login, trusted server, or independently verified human identity. Browser storage and the local activity log are editable by someone controlling the browser; the log is not tamper-evident. Browser automation with UI control could click the approval button. Never use this prototype for real dispatch, customer data, or high-stakes authorization.

Actor labels distinguish the normal human interface from the tool path. They describe the pathway that recorded an action; they are not cryptographic proof of who acted. Production use would require authenticated roles, server-side authorization, durable audit storage, concurrency controls, and a reviewed threat model.

Tests and verification

npm test
npm run typecheck
npm run lint
npm run build

Or run the sequence with npm run check. Run npm run test:watch while changing domain logic.

Critical verification covers overlap and availability detection, skills and required information, fixed windows, proposal isolation, approval enforcement, applied assignments, activity events, and deterministic reset. Five component tests additionally cover the manual workflow, keyboard approval, replacement acknowledgment, Escape, and reset cancellation. Component checks use jsdom; native browser and accessibility checks remain separate.

Read docs/verification.md for current pass/fail/pending evidence. Implemented behavior, automated coverage, actual browser invocation, and deployment are reported separately; this README does not treat a passing build as proof of the full definition of done.

Current limitations

• One fictional team, one fixed demonstration day, and browser-local state. No multi-user or cross-device collaboration.
• No real messages, route optimization, maps, customer imports, or business integrations.
• No authentication, secure approval identity, protected audit store, or production authorization.
• No in-app LLM. An external WebMCP-capable browser agent supplies reasoning; manual controls work independently.
• Time and skill constraints are a simplified operational model, not a certified dispatch or safety system.
• Browser WebMCP availability varies. Only the verification record establishes what was tested.
• No real customers, measured savings, business adoption, or production validation are claimed.

Version 2 — deliberately outside V1

Authenticated dispatcher and worker roles; hosted persistence with concurrent-edit protection; stronger approval and audit security; real-world discovery with consenting businesses; optional integrations and notifications with explicit sending consent; travel-time constraints; multi-day planning; and accessibility evaluation with assistive-technology users.

Payments, billing, robotics, native mobile apps, and customer portals are not part of this MVP.

Demo, deployment, and submission

• 2:55 demo script — narration, exact agent prompts, and a recording checklist.
• Deployment instructions — local production check and approval-gated hosting preparation.
• Submission-description draft — product story and outstanding submission assets.
• Verification record — evidence and remaining checks.
• WebMCP integration guide — schema examples, browser compatibility, and native acceptance procedure.

The current Devpost requirements call for a working live app, public open-source repository, and public YouTube video with audio lasting less than three minutes. Deadline: September 3, 2026, 1:00 PM PDT / 4:00 PM EDT. Requirements were checked on August 29, 2026; review the official rules yourself before entering or submitting.

License

MIT, copyright 2026 OpsRelay contributors. Third-party dependencies retain their own licenses.