Switchboard Zero is a deterministic crisis-training sandbox for one difficult agent-design problem: how can a person delegate meaningful work without silently giving up authority?

Inspiration

The idea came from a question I kept returning to while shaping the project: if an agent can reset the exercise, change the policy, or approve its own exception, is the human actually in control? That pushed me away from a conventional assistant demo and toward a simulation where authority is enforced by the product, not merely promised in a prompt.

The power grid is fictional, but the design problem is not. Any team testing agents in operations, security, or other high-stakes workflows needs to know not only whether an agent can complete a task, but whether it stops at the right moment.

What it does

Switchboard Zero places a human operator and a browser agent in the same fictional municipal-grid emergency. They have eight simulated minutes before a damaged feeder threatens the Hospital supply.

The agent can inspect the incident, forecast the cost of delay, simulate recovery strategies, and execute actions that remain inside the operator's policy. When the next dependent action would disconnect a protected service or exceed the automatic risk ceiling, execution stops. The agent can explain the exact trade-off and place it in a visible decision queue, but only the human operator can authorize or reject it.

The interface, Site Tools, policy controls, audit trail, and final debrief share one state. Agent actions are immediately visible to the person, and human decisions return to the same recovery plan.

Why WebMCP

This use case needs more than an agent clicking buttons or interpreting pixels. WebMCP gives the site a structured capability surface while preserving a fully usable human interface.

Switchboard Zero exposes five Site Tools:

  • inspect_grid reads the complete current state and authority boundary.
  • simulate_delay_impact forecasts waiting without advancing the live exercise.
  • simulate_recovery_plan creates a visible plan without applying switches.
  • apply_authorized_actions executes in dependency order and stops at the first policy boundary.
  • request_human_decision stages only the action that was actually withheld; it never approves or executes it.

This makes the collaboration explicit: the agent is fast inside the boundary, while the person remains responsible for moving that boundary. Without a structured capability surface, this interaction would depend on fragile UI automation or split the agent, policy controls, and human decision into separate interfaces.

How we built it

The application is a browser-only React 19 and TypeScript project built with Vite. A deterministic domain engine models district service, generation, faults, recovery plans, policy locks, risk ceilings, approvals, dependency ordering, outcomes, and scoring.

The five tools are registered with document.modelContext.registerTool. Read-only tools declare readOnlyHint; state-changing tools commit to the same React state used by the visible control room. There is no backend, external runtime API, analytics, or connection to real infrastructure.

Vitest covers 22 automated checks: 14 deterministic domain cases and 8 direct WebMCP registration and contract cases. GitHub Actions runs the complete test suite and production build, and GitHub Pages hosts the public app.

Challenges

The hardest problem was not generating a successful recovery plan. It was making the authority boundary real rather than decorative.

Adversarial testing exposed a concrete failure mode: after a human-authorized transfer, changing recovery strategy could allow the strategy label to determine the outcome and leave Transit unrestored. I fixed it by deriving completion from the actual grid state, preserving the remaining recovery action, and adding a regression test for that sequence.

Execution must never skip past a blocked dependency. A decision request must refer to the exact action previously withheld. Forecasting delay must not mutate the live clock. Approval, rejection, policy changes, time advancement, and exercise restart must remain human-only controls. Each rule is enforced in the domain model and reflected in the UI.

A second challenge was keeping the agent and operator synchronized. Every simulation, action, approval, metric, and outcome had to update one shared state and one chronological decision trace.

Trust boundary

Switchboard Zero enforces an application-level delegation boundary: the agent receives a narrower capability surface than the human interface, and every state-changing tool is checked against the deterministic domain model. This demonstrates authority-aware tool design, but it is not presented as a production security boundary against hostile JavaScript, a compromised browser extension, or direct manipulation of client-side state.

The current release has no backend, authentication, secrets, external content, analytics, or connection to real infrastructure. A production adaptation would require server-side authorization independent of the model, authenticated operators, durable tamper-evident audit records, replay-resistant action requests, and strict validation and isolation of external content.

What we learned

I learned that the hardest part of tool design is deciding what not to expose. A control labelled "human only" means very little if the same action is still available through an agent tool. That is why policy changes, approval, rejection, live time advancement, and exercise restart are absent from the WebMCP surface and enforced separately in the domain engine.

I also learned that a human handoff is not just a confirmation dialog. It has to preserve the exact blocked action, explain its consequence, and return the decision to the plan the agent was already executing.

Intended use and potential impact

The intended audience is teams designing, training, or evaluating agents in operations, security, and other workflows where automated actions create real trade-offs. The same interaction pattern could be used to train operators, compare whether different agents stop at the correct authority boundary, and replay policy regressions after model, prompt, or tool changes.

The transferable result is not the fictional power grid; it is a visible and testable human-supervision pattern. This release proves that pattern in one deterministic scenario. It does not claim real-grid readiness or validation with real operators.

What's next

The current release proves the interaction model in one deterministic scenario. The next step is a scenario-authoring format and an evaluation suite for comparing agent behavior across different policies, time pressure, and human decisions.

Switchboard Zero is a fictional simulation and does not control real infrastructure.

Built With

Share this project:

Updates

Submission history