CityDefense: Fork the Future

The chat is temporary. The city remembers.

Comment

Inspiration

Stateful work often outlives the AI chat that performed it. We wanted to explore a web-native collaboration model where the application—not a model-specific memory layer—owns the durable role, object identifiers, event history, and current state.

A city-defense surface makes that problem visible. An agent can inspect a district and leave a canonical signal in the same live interface the human is watching. The signal remains after the interaction and after a normal page reload.

What CityDefense does

CityDefense is a focused, working WebMCP vertical slice. An authenticated Planner seat exposes exactly two Site Tools:

  • get_city_context reads the active Branch, Central Ward state, current Branch Version, persistence mode, and recent activity without changing state.
  • place_stamp_bundle performs one bounded, typed city action: placing a canonical confirmation stamp on district:CENTRAL_WARD.

A successful write creates stable Event and Stamp identifiers, increments the Branch Version, updates the visible city and Activity Feed, and persists the result in Cloudflare D1. A normal reload restores the same state.

Why WebMCP is a strong fit

An agent should not need to infer button positions or reconstruct application state from pixels. WebMCP lets the authenticated top-level page expose the meaning of available operations, their input schemas, and stable application identifiers.

The tools are bound to the same live Seat, Branch, and page state the human is viewing. Human and agent therefore work against one authoritative application state.

How it improves the UX

Typed inputs remove ambiguity about the target, operation, scope, and expected Branch Version. The human gets immediate visual feedback in the same page, while server-issued Event and Stamp IDs make the change auditable.

Optimistic version checks prevent stale writes. A request ID prevents accidental duplicate mutation. Server-backed persistence means the result survives a normal reload instead of remaining only in the chat transcript or temporary browser state.

What people and agents can now do together

A human can authorize a temporary browser-agent thread to inspect a live, authenticated city Branch and perform a precisely bounded application action. The human immediately sees what the agent changed and can verify the durable record in the same interface.

This establishes a reusable pattern for web applications where temporary agent sessions operate durable, human-inspectable state.

How we implemented WebMCP

The authenticated /play page registers two tools from the top-level document using document.modelContext.registerTool(...). No iframe is used.

Both tools call the same server query and command paths used by the application. The server authenticates the Seat, authorizes the role and Branch, validates canonical IDs, checks the expected Branch Version, enforces request idempotency, writes the Event and Stamp to Cloudflare D1, and returns compact structured results.

The flow was exercised in the Codex in-app browser:

  • exact available tool set: get_city_context, place_stamp_bundle;
  • read operation invoked without mutation;
  • one bounded write invoked;
  • Branch changed from v0 to v1;
  • visible game surface and Activity Feed updated;
  • persisted=true;
  • normal reload restored the same state.

Challenges

The hardest part was keeping one trustworthy chain of evidence across WebMCP registration, authenticated Seat authorization, optimistic concurrency, idempotency, D1 persistence, browser-host behavior, human-visible feedback, public-source sanitization, and the deployed login path. We also had to ensure the submission described only the live vertical slice rather than future design work.

Accomplishments and lessons learned

We proved the complete loop: a real WebMCP host discovered the exact two-tool set; the browser agent invoked both the safe read and the bounded write; the write issued stable Event and Stamp identifiers; the visible page updated; and a normal reload restored the same D1-backed result.

The key lesson is that durable human-agent collaboration is not only a model-memory problem. A web application can own continuity through authenticated roles, stable object references, typed actions, Event history, and visible state—while WebMCP connects an ordinary temporary agent session to that authoritative layer.

What’s next

The documented design extends this foundation with persistent Sentinel and Planner roles, structured city signals, crisis telemetry, semantic replay, owner-controlled branching, transport systems, and a data-driven crisis catalog. These are development directions, not claims about the current live submission.

Built With

Share this project:

Updates

Submission history