Hexmend is an agent-evaluation environment disguised as a graph-native spell game. A person contributes taste ("the ducks must stay") while a browser agent inspects, traces, simulates, and repairs the same executable spell through seven WebMCP tools. Those calls form a deterministic, scored, exportable trajectory.

How to try it

WebMCP tools register only when a host provides document.modelContext, and hosts are not broadly shipped yet, so the page tells you which case you are in instead of pretending. Opened by a WebMCP-capable browser agent the header reads 7 WebMCP tools registered; opened in an ordinary browser it reads 7 WebMCP tools ready for a host. Either way the lesson is playable, because the local tool console calls the same production handlers a visiting agent would. The screenshots, the demo video, and the browser tests install a stand-in document.modelContext to play the host; that shim only delivers the calls, and every result in them comes from the production handlers.

Why this is a strong fit for WebMCP

Most agents have to infer application state from pixels and imitate clicks. That is especially brittle in a graph editor, where direction, type, version, and causality matter more than position. Hexmend exposes the spell as a semantic, versioned artifact instead.

Seven narrow WebMCP tools let the agent inspect the exact graph, trace a side effect, run deterministic simulations, explain the smallest responsible subgraph, record a human-authored sacred constraint, rank valid repairs, and atomically apply an approved patch. Focused inspection never hands the agent dangling references or a pre-solved diagnosis: it separates the closed selected subgraph from boundary edges and returns only high-level scenario status. The trace is a bounded graph traversal, not a prose guess: it returns the complete ordered Moonwell → Multiply → Summon ducks → Pour → Room path, all responsible edges, and explicit cycle/type evidence. The explanation is also executable evidence rather than a prose claim: it returns the typed five-rune/four-edge subgraph, the positive route facts, the absence of an Umbrella route, and four counterfactual simulations proving every responsible edge is necessary. A repair can first be simulated by its bounded patch ID: the result proves the editor was not mutated, and the interface visibly labels the stable prediction as unapplied. The tools return stable node and edge IDs, ordered events, cast assertions, before/after evidence, minimality evidence, and a stale-safe revert token. The browser agent works with the application's source of truth rather than reconstructing it from the interface.

How it creates a better user experience

The agent does not disappear into a chat transcript. Its work is visible on the shared canvas: inspected runes select, causal paths glow, constraints become physical pins, and every proposed connection, disconnection, and rune activation appears both in an eight-step review ledger and as a pending graph overlay before approval. Crucially, the human card renders the exact structured ledger returned to the agent; simulation, application, and rollback repeat that receipt so review cannot silently drift from execution. Mutations advance the graph version, and verification casts animate the outcome. The same shared handlers power WebMCP, human controls, and a local fallback console, so the experience remains understandable in an ordinary browser.

Every write is bounded and reversible. The agent can apply only a current application-generated patch ID, not arbitrary graph operations. The proposal names its exact graph-version, live-edge, dormant-rune, and sacred-lock preconditions; the approval card shows them, application revalidates them before cloning, and the result returns what was checked. The human can undo the latest unchanged patch without losing their sacred constraint.

What people and agents can do together

The opening spell should water a Moonflower, but Multiply executes before a target is bounded. Twelve lunar ducks flood the observatory. A purely mechanical optimizer ranks a six-edit repair that bypasses the duck branch.

The person contributes something the graph cannot infer: "The ducks are funny. They stay." That preference becomes an executable constraint. The cheaper candidate is now ineligible, so the agent ranks an eight-edit Umbrella route first. All twelve ducks survive, their rain reaches the Moonflower, the room stays dry, and the flower blooms.

This is the central thesis: graph interfaces let people and agents negotiate executable intent. The same pattern applies beyond games to creative tools, workflow builders, data pipelines, and other stateful systems where a person's subjective constraints are essential but impossible for an optimizer to guess.

Why it is more than a game

Hexmend also exposes a headless Agent Gym protocol. The typed graph is the observation, the seven tools are the action space, and the shared application handlers define deterministic transitions. A nine-milestone, 23-point rubric rewards grounding, failure observation, causal tracing, explanation, intent preservation, safe patch preview, atomic application, and final verification. Invalid calls score −2; mutating before explaining scores an additional −5. The visible scorecard updates for both UI and WebMCP calls, and a complete trajectory can be exported as JSON.

Three semantic families contain 96 deterministic tasks: 48 Moonflower carrier-path variants across 32/8/8 splits, 24 Resonant Aviary feedback-cycle variants across 16/4/4, and 24 Clockwork Orchard temporal-guard variants across 16/4/4. Node, edge, and effect IDs are opaque and remapped per task; serialized order, layout, and prompt wording also change. Each variant activates one to three seeded, typed decoy edges outside the answer-key route, giving every family at least three visible topologies and testing whether a policy can reject causal distractors. Public observations deliberately omit the simulator's role map, causal rule ID, answer-key edges, rule-revealing family/scenario names, and pre-cast diagnostic assertions. Tests prove that a transparent policy can ground protected intent from natural-language constraints plus inspected rune text and earn 23/23 on held-out variants from all three rules, while a memorized training ID is rejected without mutation. That is meaningful cross-rule grounding evidence, not a claim of broad transfer or reinforcement-learning gains.

The reproducible benchmark runs the transparent reference policy over all 96 variants and reports 96/96 completions at 23/23. A held-out contrast suite proves the reward separates grounded completion (23), unsafe mutation-first completion (18), safe but incomplete diagnosis (6), constraint-violating completion (4), and canonical-ID memorization (−8); its aggregate results are visible in the product. A JSONL exporter emits standalone training episodes with the task prompt, human constraint, initial public graph, complete tool manifest, replay-complete transitions, rewards, and termination flags; an independent verifier replays every action through the production handlers and rejects any altered record. A streaming JSONL service and dependency-free Python adapters let an external trainer drive those same transitions online, as one environment or as isolated parallel vectors with Gymnasium-shaped reset/step results. These validate the environment and scripted controls, not a learned-policy result.

What adversarial testing found

An evaluation environment is worth what it survives, so this one was attacked deliberately. The attacks are kept runnable, and every number below regenerates with one command.

  • The reward ignored the human's constraint. A policy that diagnosed correctly, skipped locking the constraint so the destructive repair stayed eligible, applied it and recast was graded goal-verified at 20/23 with the protected branch orphaned every time. Reaching the goal by discarding what the human protected now ends the episode as constraint-violated and scores 4. It is a visible row in the on-screen baseline table.
  • The advertised tool schemas were locked to one scenario. Enums were built from a hardcoded scenario, so on other families the only correct arguments were schema-invalid. Registration now describes the graph it is registering for, and deliberately does not enumerate the protected rune, since that is what the agent must ground from the human's words.
  • Registration gave up if the host was slow. Model context was feature-detected once; a host that installed it after mount found nothing. Registration now waits for the host, bounded and abort-scoped.
  • The approval card promised a protection that was not set. Its footer was a hardcoded claim. It now reports what the patch actually preserves, or says plainly that nothing is.
  • The splits held out identifiers, not structure. The suite now fingerprints every task and derives the claim a held-out score is entitled to support. A separate transfer protocol withholds an entire family: a grounded policy scores 23/23 on a structure it never saw, while a policy that memorized the training family's vocabulary scores 2 or −1, a 21-to-24-point separation. Two of the three still reach the goal; only the reward tells them apart.

How WebMCP was implemented

  • document.modelContext.registerTool() is feature-detected and registers exactly seven lifecycle-scoped tools.
  • All schemas are narrow JSON objects with described, bounded fields and additionalProperties: false.
  • Five tools are annotated read-only; two are reversible writes. Application-owned output is marked trusted.
  • Registered callbacks, visible UI actions, and the fallback console invoke the same runtime-validated handlers.
  • The React adapter reads current graph state at execution time and emits typed presentation events, so agent calls visibly update the canvas.
  • A pure deterministic simulator and bounded graph-rewrite solver remain authoritative. The optional two-round Familiar GNN only ranks inspection targets.
  • A shared-handler instrumenter records Agent Gym rewards and trajectories without creating a second execution path.

How to test

  1. Open https://hexmend.hex-machina.workers.dev in a WebMCP-enabled browser.
  2. Reset the lesson if it is not at graph v1.
  3. Give the browser agent this exact prompt:

Inspect my spell and cast it. Explain why it failed, but do not change anything yet. The ducks are funny, so preserve them as a sacred constraint. Find the smallest repair that waters the moonflower without flooding the room, show me the proposed patch, apply it, and cast the spell again.

Expected result: seven tools are discoverable; the initial cast floods the room with twelve ducks; the agent pins the duck constraint, proposes the rank-one eight-edit Umbrella patch with a complete visual operation ledger, applies it, and reaches Stable at graph v3 with all twelve ducks preserved.

Build provenance

Hexmend is a new project created during the challenge period. Its first commit is c661551 at 2026-08-26 22:55 EDT, and the complete timestamped history is preserved in the repository.

Built With

Share this project:

Updates

Submission history