REDLINE

A browser agent can propose shared changes, but only a human decides what becomes real. REDLINE makes that authority boundary visible with WebMCP.

Comment

Inspiration

AI agents can already read context and invoke tools. The harder question is what happens when an agent proposes a change that affects more than one person.

Most interfaces collapse proposal and execution into the same moment. REDLINE explores a different boundary: an agent can prepare shared work, everyone affected can see it, but human review remains authoritative before anything becomes committed state.

What it does

REDLINE is a browser-local shared planning environment for two people: Alex, the reviewer, and Sam, a read-only observer.

A visiting browser agent reads the live planning context through WebMCP and stages five typed changes as one proposal. Those changes immediately appear as visible, uncommitted proposal state in both browser views.

Alex reviews each operation independently. In the canonical scenario, four changes are accepted and the proposed Browser QA compression is rejected. The projected outcome therefore changes from a Friday launch with compressed QA to a Monday launch with the full two-day QA window retained.

Only the accepted subset becomes committed state. Sam sees the proposal, review decisions, and final result, but cannot stage, review, commit, or reset shared state.

How we built it

REDLINE is a deterministic TypeScript browser application built around three WebMCP tools:

  • get_current_view reads the live browser-local planning context.
  • propose_changes stages an atomic typed proposal against an expected plan revision.
  • commit_proposal finalizes only the subset accepted through the page's human review state.

The commit contract deliberately accepts only a proposal ID and expected proposal revision. It does not accept operation IDs or human acceptance decisions, so an agent cannot widen its own authority at commit time.

The application also implements stale-revision refusals, deterministic impact calculation, idempotent commit receipts, synchronized same-origin views, and explicit observer-only enforcement.

REDLINE uses native BroadcastChannel synchronization between the two open browser views. There is deliberately no server, backend, or database: the proposal exists only in the open page.

How we used WebMCP

WebMCP is the capability boundary between the visiting browser agent and REDLINE.

Instead of exposing generic page automation, REDLINE exposes exactly three typed capabilities corresponding to the lifecycle of shared work: read context, stage a proposal, and commit an already-reviewed proposal.

The page retains the authority the agent must not possess. WebMCP therefore does more than provide tool access here: its contracts define what authority crosses the browser-agent boundary and, just as importantly, what authority does not.

Challenges

The main challenge was preserving a strict distinction between proposed state, human-reviewed state, and committed state while keeping two browser views synchronized.

The commit path also had to remain safe under retries and stale state. Repeating an already-applied commit returns the same receipt without duplicating mutation, while stale plan or proposal revisions return structured refusals without changing state.

A second challenge was making these boundaries visible. Proposal geometry, human decisions, observer restrictions, projected impact, and final attribution all needed to remain understandable without hiding the underlying authority model.

Accomplishments that we're proud of

  • Exactly three typed WebMCP tools with deliberately bounded authority.
  • Atomic proposal staging without immediate mutation of committed state.
  • Human acceptance decisions that cannot be supplied through commit_proposal.
  • Read-only synchronized observation for Sam.
  • Deterministic projected impact before commit.
  • Structured stale-revision refusal.
  • Idempotent commit behavior.
  • 31 passing behavioral, contract, and presentation invariant tests.
  • A fully browser-local architecture with no backend or database.

What we learned

Agent tooling is only one part of the problem. Once agents operate inside collaborative applications, proposal visibility, authority ownership, concurrency, retries, and attribution become first-class interface and systems concerns.

The most important boundary in REDLINE is therefore not whether the agent can call a tool. It is whether calling that tool can carry authority that belongs to a human.

What's next

REDLINE is intentionally narrow: one shared plan, two people, one proposal lifecycle.

The next step would be to explore how the same explicit proposal-before-commit model generalizes to richer collaborative workflows while preserving typed authority boundaries and deterministic review semantics.

Built With

Share this project:

Updates

Submission history