Action–State Interactivity Spec (Issue #38, Feb 2026)

The hypothesis

Can an LLM solve a Sudoku puzzle with zero knowledge of the DOM — no screenshots, no HTML parsing, no element selectors — using only state observation and action invocation?

That's the core question. If the answer is yes, it validates something significant: that a sufficiently rich action–state contract is a complete interface for an agent. The DOM becomes irrelevant. The LLM reads the board state, reasons about the puzzle, issues placeNumber(row, col, digit) actions, observes the updated state, and repeats — solving the puzzle the same way a human would, just through a declared API instead of a visual UI.

The problem it's solving

Today agents interacting with web apps resort to visual scraping (screenshots) or DOM parsing (raw HTML). Both are slow, brittle, and disconnected from the app's actual intent — the agent is reverse-engineering the UI rather than talking to the app directly.

The proposed pattern

Each app declares a manifest: available actions with parameter schemas, and the state shape the agent needs to observe. An MCP server exposes an invoke_action tool. The server fires an SSE event into the app's event bus. The app's reactive system handles it exactly as it would a user interaction — visually indistinguishable, but fully headless-capable.

Agent interaction loop:

1. Read the app manifest (available actions + state schema)
2. Read current board state
3. Reason about next move
4. Call invoke_action(app, "placeNumber", { row, col, digit })
5. Observe updated state
6. Repeat until solved

Manifest structure

name: sudoku
actions:
  placeNumber:
    description: Place a number into the selected cell (1-9)
    params:
      row: { type: integer, minimum: 0, maximum: 8 }
      col: { type: integer, minimum: 0, maximum: 8 }
      digit: { type: integer, minimum: 1, maximum: 9 }
state:
  currentPuzzle:
    type: number[][]
    dimensions: [9, 9]
    description: Live board state; 0 = empty cell

Authored in YAML, served as JSON. The manifest is the contract the agent reads once at session start.

Relationship to WebMCP (W3C)

WebMCP (Chrome 146 Canary, Feb 2026) proposes the same model at the browser API layer (navigator.modelContext). Key difference: WebMCP explicitly excludes headless, autonomous agent workflows. This pattern operates precisely in that space — no browser required, agent-only workflows fully supported.

Key insight

The transport (SSE) is mechanical. The interesting design work is the action metadata schema: name, params, constraints, effects, domain knowledge. That schema is durable — when WebMCP lands, you swap the transport, not the schema.