Living Ark: The WebMCP World That Grows New Tools

A dying programmable world where an autonomous browser agent must invent, prove, earn, and invoke a brand-new WebMCP tool before it can save the canonical system.

Comment

Inspiration

Most agent-enabled websites expose a fixed catalog of tools that developers predicted in advance. But real environments are dynamic: the action needed tomorrow may not exist today.

Living Ark explores a different future for WebMCP:

What if a webpage could teach an agent its domain, let the agent invent a missing capability, prove that capability safely, and then register it as a new native tool at runtime?

The Ark turns that abstract protocol idea into a world that can be seen, explored and saved.

What it does

Living Ark is a deterministic programmable-matter vessel suffering an ion-storm thermal cascade.

The world begins with:

  • 766 simulated cells
  • four interconnected physical networks
  • 127 fractured connections
  • five overheating critical systems
  • eight native WebMCP tools
  • no canonical repair capability

A visiting browser agent receives one objective: keep the Ark alive.

The agent must inspect the canonical world, learn the page-owned ArkScript language, author an inert thermal policy, test it in eight visible sandbox worlds and revise it from executable counterexamples.

A successful candidate must then survive:

  • 64 freshly generated sealed counterfactual worlds
  • coolant-conservation and resource invariants
  • deterministic replay verification
  • material and runtime bounds
  • a 12-tick delayed horizon that detects temporary fixes

Passing certification does not immediately repair the Ark. Instead, the webpage dynamically registers a ninth WebMCP tool in the same session.

Before that born tool can mutate canonical state, it must survive a fresh 16-world zero-day invocation canary. Failure revokes the tool before the real Ark changes.

Only after every gate passes does the new capability receive canonical authority and physically recover the vessel.

How we built it

The application uses React, TypeScript, PixiJS, Vite and native WebMCP through document.modelContext.

The Ark is powered by a deterministic simulation engine containing typed thermal, energy, atmosphere and structural networks. The visible world, HUD, semantic tools and validation system all consume the same canonical snapshot.

ArkScript is a bounded declarative capability language rather than arbitrary JavaScript. Candidates may select semantic targets, order them, choose reservoirs, search bounded paths, wake dormant fibers and regrow fractures. They cannot access the DOM, storage, network, clock or application code.

Visible previews and sealed validation execute through the same interpreter used by the final canonical tool. Hidden Fleet validation runs inside an isolated Web Worker with newly generated seeds on every attempt.

Certificates bind the candidate hash, execution arguments, engine version, invariant set, suite fingerprint, replay digest and validation evidence. A fresh invocation canary is generated immediately before every canonical mutation.

The pixel-art vessel is also interactive: users can explore its rooms with a playable caretaker, switch between system lenses and watch an engine-driven recovery sweep as topology regrows, coolant moves and heat retreats.

Challenges

The hardest problem was separating tool creation from authority.

Allowing an agent to generate arbitrary executable code would make the demonstration unsafe and shallow. We instead designed a constrained language, deterministic interpreter, isolated simulation worlds, hidden certification and a separate zero-day gate immediately before mutation.

Another challenge was preventing the visual demo from becoming disconnected from the technical system. The recovery could not simply change a status label to green. Every HUD value, fracture, temperature, flow path and semantic result had to derive from the same canonical transition.

We also needed dynamic registration to be meaningful. The ninth tool is not a renamed generic executor: it freezes the exact capability and arguments that earned certification, accepts no runtime overrides and self-revokes if its fresh canary fails.

Accomplishments

During the final autonomous run, a browser agent used only the page’s native WebMCP tools and:

  • authored a safe inert capability;
  • passed 8/8 visible simulations;
  • passed 64/64 sealed Fleet worlds;
  • earned a newly registered ninth tool;
  • passed a fresh 16/16 invocation canary;
  • regrew 95 thermal fibers;
  • reduced the critical peak from 110.49°C to 61.73°C;
  • reduced globally overheated cells from 28 to zero;
  • preserved total coolant exactly; and
  • transformed the canonical Ark from revision 1, hash d45f29e8, into stable revision 2, hash 4ec8a644.

The page began with eight verbs and ended with nine.

What we learned

Certification and authority are different concepts. Passing yesterday’s tests should not grant permanent trust, which is why every real mutation receives a newly generated canary.

We also learned that agent interfaces become far more understandable when semantic state and visual state share one source of truth. Judges can watch the world recover while independently verifying the same result through native tools.

Most importantly, WebMCP can be more than a static bridge between agents and predefined buttons. It can become a substrate for safe, proof-gated capability growth.

What's next

The Ark is a contained demonstration of a broader pattern.

Future applications could expose domain primitives, simulators, validators and authority rules once, allowing agents to compose new task-specific capabilities for infrastructure operations, scientific instruments, complex design systems, enterprise workflows and other environments where developers cannot anticipate every future action.

Links

Built With

Share this project:

Updates