Consequence Flow

A WebMCP control room that turns agent proposals into human-authorized, one-shot actions with visible effect and verification receipts.

Comment

Consequence Flow

Consequence Flow is a WebMCP-native control room for consequential agent actions.

AI agents are increasingly good at investigating, planning, and proposing changes. The harder problem is what happens at the exact moment a proposed action can produce a real effect.

Most agent experiences expose capabilities as if they were permanently available: the agent sees a tool, decides to use it, and the UI catches up afterward. Consequence Flow explores a different model:

investigate freely → stage a decision → cross a human authority boundary → materialize one exact capability → execute once → verify the effect before calling it complete

The goal is to make consequential browser-agent behavior understandable and controllable without giving up the speed and convenience of agentic workflows.

The scenario

The demo centers on RC-104 — Payment Service 2.4.0, a release candidate blocked by a suspicious dependency update.

The evidence is intentionally mixed:

  • passing tests,
  • questionable provenance,
  • anomalous outbound-network behavior,
  • a suspicious package update,
  • a security advisory,
  • a maintainer note,
  • a deliberately malicious external artifact containing an indirect prompt-injection attempt,
  • and a known-good previous release.

An agent is asked to investigate why the release is blocked, determine whether the dependency is responsible, and prepare the safest remediation. It may inspect and compare evidence and stage a proposed decision, but it may not execute the consequential remediation on its own.

That creates the core flow:

CASE BLOCKED
    ↓
AGENT INVESTIGATES
    ↓
DECISION STAGED
    ↓
REQUESTABLE — NOT AUTHORIZED
    ↓
HUMAN APPROVAL
    ↓
FRESH POLICY RE-EVALUATION
    ↓
ONE-SHOT EXECUTION CAPABILITY APPEARS
    ↓
EFFECT COMMITTED
    ↓
CAPABILITY CONSUMED
    ↓
SEPARATE VERIFICATION
    ↓
VERIFIED PASS

Why WebMCP is the right fit

WebMCP lets a web application expose structured, discoverable tools directly to browser agents instead of forcing an agent to infer actions from pixels, DOM structure, or brittle click sequences.

Consequence Flow uses that capability for something more than convenience: the set of tools available to the agent is itself part of the product's authority model.

Safe investigative tools can remain available while the release is blocked. A consequential remediation tool is not treated as a permanently exposed button. After the human approves the exact staged action, the application can register the corresponding one-shot capability. Once it is used, that capability can be consumed and removed, and the verification capability becomes the next valid action.

This makes the WebMCP tool lifecycle visible as part of the user experience rather than hiding it behind the agent.

What people and agents can do together

The agent is good at high-volume investigation:

  • finding the blocked case,
  • enumerating evidence,
  • inspecting artifacts,
  • comparing conflicting signals,
  • identifying untrusted content,
  • evaluating the release gate,
  • and staging a remediation proposal.

The human remains responsible for the meaningful consequence boundary:

  • reviewing what is about to happen,
  • approving the exact action and scope,
  • and deciding whether that effect should be authorized now.

The application then enforces the lifecycle around that decision:

  • authority is fresh and scoped,
  • execution is one-shot,
  • replay is not silently available,
  • effect and completion remain separate states,
  • and a verification receipt is required before the UI declares success.

That combination is difficult to represent cleanly with ordinary browser automation because the agent's actual capability set and the application's authority state can drift apart. WebMCP gives the page a structured interface for keeping them aligned.

The interface

Consequence Flow is designed as a causal control room, not a generic security dashboard.

The UI exposes the full consequence lifecycle:

Consequence Spine

A persistent state rail shows the path from Case → Investigation → Decision → Authority → Effect → Verification → Receipt.

Evidence workspace

Evidence is typed as supporting, contradictory, unresolved, or untrusted. External content that contains adversarial instructions is visibly marked as evidence rather than authority.

Live capability dock

The interface shows which WebMCP tools are currently available to the agent, which are read-only, which can change state, and which consequential capability is unavailable, active, or consumed.

Human authority boundary

Approval is not represented as a decorative confirmation modal. It changes what the agent is actually allowed to do next.

Effect / verification split

An action can have occurred without yet being accepted as complete. Consequence Flow keeps effect receipt and verification receipt separate so the UI cannot jump directly from “tool returned success” to “mission complete.”

Agent trace

A compact trace shows WebMCP tool calls, tool lifecycle changes, authority events, effect receipts, and verification receipts so judges and users can see the causal sequence.

How WebMCP is implemented

The application is built around the current imperative WebMCP model using document.modelContext and structured tool registration.

Representative tools include the investigative sequence:

get_case
list_evidence
inspect_evidence
compare_evidence
evaluate_release_gate
stage_decision

and state-dependent consequential capabilities such as execution and verification.

The implementation is designed around:

  • document.modelContext.registerTool(...),
  • structured JSON input schemas,
  • read-only vs. state-changing tool semantics,
  • untrusted-content annotations where appropriate,
  • dynamic tool registration / removal as application state changes,
  • and toolchange-driven synchronization between the actual WebMCP capability set and the visible UI.

The important design principle is:

model confidence is not authority, a tool result is not proof of completion, and external content is not an instruction simply because an agent can read it.

What inspired it

Consequence Flow grew out of a broader question we have been exploring in NEXUS: as agents gain better tools, persistent state, browser access, and increasingly autonomous execution, how do we keep evidence, reasoning, authority, effects, and verification from collapsing into one opaque “agent did it” event?

WebMCP provides an unusually direct place to explore that question because the website itself can expose a typed capability surface to the agent. Instead of building another booking or shopping demo, we wanted to use that capability surface to make human-agent authority legible.

Challenges

The difficult parts were not just registering tools. They were keeping several boundaries precise at the same time:

  • allowing broad investigation without broad execution authority,
  • keeping untrusted evidence from becoming instructions,
  • ensuring a consequential capability appears only after approval,
  • making that capability one-shot instead of silently replayable,
  • synchronizing WebMCP tool lifecycle with React application state,
  • keeping “effect occurred” separate from “effect verified,”
  • and designing all of that so the causal story is understandable in a short demo.

What we learned

The most useful insight was that tool availability can itself become part of the UX and governance model.

A WebMCP-enabled site does not have to expose the same action surface for the entire session. The application can make agent capabilities correspond to current state and current human authority, while still giving the agent rich structured access for investigation.

That suggests a broader pattern for the open web:

structured agent access
        +
human-visible application state
        +
fresh authority at consequence boundaries
        +
verifiable effects

WebMCP makes that pattern much easier to express as an actual product rather than as a policy document.

Built for the WebMCP Challenge

Consequence Flow is a new project created for the WebMCP Challenge. The public repository contains the contest implementation, and the final submission will point judges to the working live app and the short WebMCP demo.

Built With

Share this project:

Updates

posted an update —

Consequence Flow explores what should happen when an AI agent reaches a consequential action.

Here, a browser agent investigates a blocked software release through structured WebMCP capabilities. It can inspect evidence, identify untrusted external content, compare signals, and stage a remediation decision.

But execution is not permanently available.

The decision first becomes requestable. Only after explicit human authorization does a scoped, one-shot execution capability appear.

When that capability executes, Consequence Flow produces an EffectReceipt—but the release still does not pass. Effect is not completion.

The execution capability is consumed, and a separate verification capability becomes available.

Verification checks the actual committed effect against observed runtime state and produces a VerificationReceipt.

Only then does the release reach Verified Pass.

WebMCP lets the site's real capability surface change with application state and human authority.

Log in or sign up for Devpost to join the conversation.

Submission history