BranchLine

BRANCHLINE lets humans and browser agents share the same live supply-chain reality—fork recovery futures, simulate their consequences, and commit only the plan a human explicitly approves.

Comment

Inspiration

Supply-chain disruptions are rarely isolated events. A supplier outage can cascade through component availability, transport lanes, factory capacity, production schedules, customer commitments, revenue, and cost.

Operations teams often have to reconstruct this chain manually across ERP systems, spreadsheets, supplier messages, logistics tools, and planning software before they can even decide what to do.

At the same time, browser agents are becoming capable of operating websites, but most applications still expose their operational meaning only through buttons, forms, and DOM elements.

We built BRANCHLINE around a different idea:

What if a human and a browser agent could operate inside the same live operational reality?

BRANCHLINE — Fork reality. Simulate the consequences. Commit the future.

It is an agent-native operational recovery control plane where humans steer intent, agents traverse consequences, and both operate on one shared supply-chain digital twin.

What it does

BRANCHLINE models a synthetic commercial EV supply chain for Asterion Mobility, including suppliers, components, factories, transport lanes, inventory, products, customers, and 24 customer orders.

The featured scenario begins with a healthy network.

A human triggers a 12-day production outage at the battery supplier NoriCell.

Instead of simply displaying an alert, BRANCHLINE calculates and visualizes the complete causal cascade:

supplier → component availability → factories → products → customer orders → exposed revenue

The browser agent can then use semantic WebMCP tools to:

  • inspect the operational state;
  • trace downstream consequences;
  • inspect suppliers, factories, products, customers, and orders;
  • find compatible substitute suppliers;
  • create multiple recovery branches;
  • simulate each future across a 30-day horizon;
  • compare service, cost, risk, emissions, and delays;
  • explain tradeoffs using causal evidence;
  • stage a recovery plan for human approval;
  • apply only an explicitly approved plan;
  • verify the committed result;
  • restore the previous operational checkpoint.

The central experience is Branchspace.

Instead of presenting three AI recommendations as ordinary cards, BRANCHLINE renders different recovery strategies as parallel futures emerging from the same present.

For example:

  • Service First prioritizes customer service and on-time revenue.
  • Cost Guard prioritizes lower incremental cost.
  • Balanced Recovery trades off service, cost, resilience, and logistics.
  • Resilience reduces supplier concentration and future single points of failure.

The simulation is deterministic and calculated from the underlying supply, compatibility, capacity, logistics, inventory, and customer-order data.

How we built it

BRANCHLINE is a static TypeScript web application built around one architectural principle:

Human UI ─┐
          ├─ shared command bus → domain engine → one live state
WebMCP ───┘

The visual interface and WebMCP tools do not maintain separate copies of reality.

Every meaningful operation passes through the same domain engine and shared state.

The application includes:

  • a deterministic synthetic supply-chain digital twin;
  • causal impact tracing;
  • a bounded recovery-planning engine;
  • a day-by-day simulation from T+0 through T+30;
  • supplier and product compatibility enforcement;
  • inventory and factory-capacity constraints;
  • customer-tier and human-authored priority constraints;
  • transactional execution;
  • verification;
  • checkpoints and exact rollback;
  • an append-only causal audit trail.

The WebMCP integration uses the native imperative API directly with:

document.modelContext.registerTool(...)

BRANCHLINE exposes 14 semantic tools:

get_ops_snapshot
inspect_entity
trace_impact
list_constraints
find_substitutes
read_external_alerts
create_branch
simulate_branch
compare_branches
explain_tradeoff
stage_plan
apply_plan
verify_plan
rollback_plan

The capability surface is dynamic.

For example, apply_plan is not registered at all while a recovery plan is waiting for human approval.

When the human approves the exact staged plan in the BRANCHLINE interface, apply_plan becomes available to the browser agent.

If the operational context changes, the approval becomes stale and the capability is revoked again.

Challenges we ran into

Keeping the human and agent in one reality

The most important technical challenge was preventing the application from becoming a dashboard with a separate agent workflow.

Human interactions and WebMCP calls therefore use the same command bus and domain functions.

If a human changes something visually, the next agent call immediately encounters the changed state.

Making stale reasoning visible and enforceable

A recovery simulation can become invalid the moment a constraint changes.

BRANCHLINE maintains separate stateVersion and contextVersion values.

Every simulation records the context on which it was produced.

When the human changes operational intent:

  • the context version increments;
  • existing simulations become visibly stale;
  • staged plans are invalidated;
  • previous approval is revoked;
  • execution capabilities disappear;
  • the agent must re-simulate.

Human authority over consequential actions

We deliberately did not create an approve_plan WebMCP tool.

Approval must happen in the visual interface.

Only after that approval does the consequential apply_plan capability become registered.

Modeling real compatibility constraints

Substitution cannot simply mean choosing the cheapest available supplier.

For example, Voltra V-2170 battery cells are incompatible with ORION-X.

That restriction is enforced inside the domain engine and simulation rather than merely displayed as UI text.

Building meaningful simulation rather than prewritten outcomes

Recovery metrics are derived from the underlying operational state.

The planner evaluates supplier allocation, logistics, inventory movement, production scheduling, compatible substitutions, and eligible order delays before choosing a deterministic result for each strategy.

Accomplishments that we're proud of

The interaction we are most proud of involves order_1082 for Apex Health Logistics.

Before human intervention, an otherwise attractive recovery future can delay this order.

The human opens the order directly in the visual application and presses:

Protect this order

A gold human-intent pin appears on the order and propagates upstream through its dependencies.

That single human action:

  1. changes the shared operational context;
  2. invalidates every simulation based on the previous reality;
  3. removes stale execution capabilities;
  4. becomes immediately visible to the browser agent.

The agent then re-simulates the recovery using the new constraint.

Scarce compatible supply is reallocated to protect Apex Health, while a lower-priority order takes the delay instead.

This is not a hardcoded visual effect. It emerges from the planner and shared constraints.

In our verified featured recovery, BRANCHLINE produces approximately:

  • $26.56M revenue protected
  • 93.4% of exposed revenue recovered
  • $258,849 incremental cost
  • 23 of 24 orders on time
  • 1 lower-priority delayed order
  • 0 hard compatibility violations
  • 1 explicit human approval
  • 1 rollback checkpoint

We are also proud that every WebMCP action has a corresponding visual response.

Agents do not disappear into an invisible automation layer—their semantic investigation is visible in the operational world.

What we learned

WebMCP becomes much more interesting when tools are treated as part of application state rather than as a static API catalog.

BRANCHLINE demonstrates that the application can expose only the actions that make sense right now.

The project also reinforced an important principle for human-agent systems:

Human intent should not have to travel through chat to matter.

A planner can simply change something in the interface.

The application can make that change part of the same structured context the agent uses on its next call.

We also learned that simulation results become significantly easier to trust when their causal evidence, assumptions, actions, and counterfactuals remain inspectable after the recommendation is produced.

That led to Causal Proof, which explains decisions from simulation evidence rather than from an embedded LLM.

What's next for BranchLine

BRANCHLINE currently uses a completely synthetic operational twin so the entire workflow is deterministic, safe, and reproducible.

A future production version could connect the same architecture to authenticated:

  • ERP systems;
  • warehouse-management systems;
  • transport-management systems;
  • supplier portals;
  • manufacturing execution systems;
  • procurement systems;
  • demand and inventory planning platforms.

The domain engine could also evolve toward richer optimization methods, probabilistic disruption modeling, supplier negotiation workflows, and organization-specific approval policies.

The larger idea extends beyond supply chains.

Any system where people must explore multiple consequential futures before changing reality—logistics, infrastructure, manufacturing, finance, incident response, or resource planning—could benefit from this interaction model.

BRANCHLINE imagines the web not as pages that agents operate on behalf of people, but as shared operational realities that people and agents can safely change together.

Built With

Share this project:

Updates

Submission history