Recovery Desk

The agent proposes. The website decides. The human commits.

Comment

Recovery Desk

The agent proposes. The website decides. The human commits.

Recovery Desk is a deterministic airline disruption-recovery simulation built to explore a question that matters far beyond aviation:

What if a website did not expose every action to an AI agent all the time, but instead changed what the agent was allowed to do as the situation evolved?

Inspiration

Most agent demos focus on whether an AI can call a tool.

I wanted to explore a harder problem: when should that tool exist at all?

In high-stakes workflows, reading information, proposing a change, cancelling something, and committing a final decision should not carry the same authority.

Recovery Desk uses an airline operations-control scenario to make that distinction visible. A fictional airline faces a hub closure and must recover its schedule while respecting aircraft position, crew duty, minimum turn time, and the disruption window.

The airline scenario is the testbed. The core idea is state-governed WebMCP capabilities.

What it does

Recovery Desk exposes seven WebMCP tools:

  • get_disruption
  • get_schedule
  • check_plan_legality
  • propose_reassignment
  • reset_draft
  • cancel_flight
  • commit_recovery_plan

But they are not all available at the same time.

The website moves through six operational states:

DISRUPTED → DRAFTING → CANCELLATION_REQUIRED → DRAFT_LEGAL → AWAITING_APPROVAL → COMMITTED

As state changes, the website dynamically changes the capabilities exposed through WebMCP.

For example, cancel_flight is a destructive capability. It is not exposed by default. When the current plan leaves an unresolved flight with no feasible aircraft reassignment, the website can enter CANCELLATION_REQUIRED and expose cancel_flight.

Once that destructive action is no longer appropriate, the capability is withdrawn.

When the draft becomes legal, commit_recovery_plan becomes available. Calling it still does not commit the plan. It moves the workflow to AWAITING_APPROVAL and waits for an explicit human decision.

Only human approval commits the recovery plan.

Agent proposes → Website validates → Capabilities change → Human authorizes → System commits.

How I built it

Recovery Desk is a deterministic client-side application with the WebMCP layer separated from the recovery logic.

The site registers tools through the browser's Model Context API and dynamically manages their availability according to the current application state.

The recovery engine uses integer-minute scheduling and explicit rules for:

  • hub closure
  • aircraft position
  • minimum aircraft turn time
  • crew duty limits

Agent mutations affect a draft, never the committed plan directly. Every mutating, destructive, or human-gated action re-checks the current phase at invocation time.

This also provides stale-tool defense: if an agent attempts to invoke a capability that is no longer valid in the current state, the website rejects the call without performing the mutation.

The application maintains an audit trail of tool calls, state transitions, rejected actions, approval requests, and final human decisions.

The demo

The deterministic recovery walkthrough deliberately creates and repairs operational conflicts.

The operator retimes flights while the website continuously validates the evolving draft. Eventually, the current draft leaves MA442 without a feasible aircraft reassignment, causing the site to enter CANCELLATION_REQUIRED.

At that point, cancel_flight dynamically appears.

After the remaining recovery actions and cancellation of MA442 produce a legal draft, the destructive capability is withdrawn and commit_recovery_plan becomes available.

The agent can request the commit, but the website opens a human approval gate.

A human can Reject, leaving the committed schedule unchanged and preserving the draft for further work, or Approve, which is the only path that commits the recovery plan.

After commitment, mutating capabilities disappear and the interface returns to three read-only WebMCP tools.

Challenges

The hardest part was not registering tools. It was defining authority boundaries between the agent, the website, and the human.

I also learned that capability availability must be treated as part of application state rather than as a static tool list.

Another challenge was keeping the demonstration deterministic enough that the same state transitions can be inspected and reproduced.

The current feasibility helper intentionally evaluates aircraft reassignment against the current draft. It is not a global optimization engine and does not claim to exhaustively search every possible retiming, resequencing, aircraft, and crew combination.

That limitation helped clarify the real purpose of the project: Recovery Desk is not presented as a production airline optimizer. It is a testbed for state-governed agent capabilities.

What I learned

WebMCP can represent more than a collection of functions that an agent can call.

A website can use its own domain state to determine:

  • what an agent may read,
  • what it may propose,
  • when a destructive capability becomes appropriate,
  • when that capability must disappear,
  • and where human authority must remain absolute.

That suggests a broader pattern for agentic websites in finance, healthcare operations, enterprise administration, infrastructure, procurement, and other workflows where actions have different levels of consequence.

Recovery Desk demonstrates a simple principle: giving an agent tools is useful; giving it the right tools at the right moment is safer and more powerful.

Built With

Share this project:

Updates

Submission history