Forkline

• 

  Main UI

Inspiration

The dangerous part of an agent is not simply that it can be wrong. It is that it can be fluent while it is wrong, and then something irreversible happens.

We kept seeing the same shape: a model explores a messy situation, picks a plan, and the UI treats “the agent said so” as permission. The human either rubber-stamps it or fights the interface. There is no clear place where the agent is allowed to be ambitious and forbidden to make its answer real.

Forkline started from that split. Let the agent try every recovery. Do not let it touch the live world. The human sets the non-negotiables in the open. The only thing that becomes real is one exact state a person approved — not a vibe, and not a checkbox the model can invent.

The Port Azure / St. Anne story is the sharpest version of that: hospital kits, a closed port, and a tempting air-freight cheat. If the agent can talk past “no air,” the whole thing is theater.

What it does

You open a disruption. The rules are on the page: protect hospital orders, keep critical fill above the floor, and use no air freight. An agent (via WebMCP) reads the network, forks disposable futures, reroutes, switches suppliers, reallocates stock, simulates, and compares.

Bad futures stay useful. Emergency air looks fast and expensive, but it is illegal under the human rule. Regional stock-preserve starves the hospital. Those branches do not get a secret override.

The agent can still ask to commit. Forkline says no until a human selects a branch and approves that exact state. Change the fill floor after approval, and the old yes is dead. Then you approve again, or you don’t.

Six tools: get_network_state, fork_scenario, apply_intervention, simulate_scenario, compare_scenarios, commit_scenario. They use the same engine as the dashboard. If WebMCP is off, the page says so and still lets you walk the futures by hand.

How we built it

A small deterministic runtime in the browser handles the network, interventions, KPIs, violations, branch identity, and approval fingerprint. Then we put two faces on it: the ops UI and document.modelContext.

Approval is not a field on the tool. The page mints a one-shot token bound to the scenario and the current human rules. Commit checks that fingerprint again. If the agent could mint “approved,” we would have built a liar.

Challenges we ran into

Making “the agent cannot authorize” actually true, not just a prompt. That meant fail-closed commit, stale tokens, and tests that try to cheat.

WebMCP is still behind a flag, so a normal Chrome tab has to stay honest instead of fake-registering tools.

The demo had to show a rejected commit, not just a pretty graph. That is the product. It is also the part people are most likely to skip when rushing a video.

Accomplishments that we're proud of

The agent can be wide. The human is narrow. You can watch both.

You can watch an illegal recovery fail in public instead of getting smoothed into a recommendation.

You can watch a feasible recovery still get refused until a person binds themselves to that exact snapshot — and watch that binding die if they move a slider.

What we learned

More tools do not create safety. A gate the model cannot write creates safety.

If the human rules live in the prompt, they are decoration. If they live in the page and the commit path, they are real.

Disposable futures only matter if commit is expensive. Cheap commit, and you have just built a faster way to ship a bad plan.

What's next for Forkline

Same protocol, nastier decisions: anything where “try it” should be free and “make it live” should not — config, money, clinical, deploys. Tighter WebMCP as the API hardens. Keep the map small until the gate is obviously the point, not the supply chain.

Built With

• netlify
• react
• typescript
• vite
• vitest
• webmcp