ExactCue

Browser agents can prepare pharmacy refills, but prescription records can change before a person confirms. ExactCue uses WebMCP to block stale orders.

Comment

Inspiration

Marcus wants his browser agent to handle the repetitive work of refilling prescriptions. But Marcus - not the agent - should own the final decision.

That creates a deceptively hard problem: what happens if Marcus reviews an order, but the pharmacy record changes before he confirms it? A confident click or agent response could submit an order he never actually reviewed.

ExactCue asks a simple question:

Can a website promise that the action it commits is still the action the person reviewed?

We use a synthetic pharmacy refill because the failure is instantly understandable, while the underlying pattern applies to any consequential browser action.

What it does

ExactCue gives a person and their browser agent shared custody of one action:

  1. The agent prepares. Through WebMCP, it selects two eligible prescriptions and a pickup pharmacy using the tools the page currently allows.
  2. Marcus reviews. ExactCue creates one visible, spoken, and machine-readable summary of the exact order, including its current version.
  3. The server checks. When Marcus confirms, the server commits only if the pharmacy record is still the version he reviewed.
  4. ExactCue proves the result. A successful action earns an authoritative receipt. If the record changed, the outdated refill is blocked, nothing is submitted, and Marcus is guided to the current record.

The demo’s signature moment is a real failure test: another request reaches the server first, the record moves from v1 to v2, and Marcus’s original action receives HTTP 409 · NO WRITE.

The pharmacy is synthetic. The reusable product idea is current-state-bound actions for browser agents.

Why WebMCP is essential

Without WebMCP, a browser agent must infer controls from pixels or an accessibility tree. It can click the right-looking button, but the page has not given it a typed contract for the action, the current workflow state, or recovery.

ExactCue makes WebMCP load-bearing:

  • The page exposes only the tools valid for the current step.
  • Prescription tools retire when the flow moves to pickup; pickup tools retire at review.
  • The agent and the visible interface operate on the same live order.
  • review_order returns the exact cue as structured data, not just screen text.
  • submit_refill carries the reviewed version and ETag to the server.
  • reload_current_record gives the agent a structured recovery path after a conflict.

Remove WebMCP and the agent loses the page-declared workflow contract. Remove the server check and ExactCue loses its central promise. The product needs both.

A better user experience

For someone who relies on spoken or structured confirmation, “the agent clicked it” is not enough. They need to know exactly what will happen - and that the action did not silently change after the readback.

ExactCue reduces a multi-step form to one meaningful human decision. The agent handles preparation. Marcus receives one exact cue. The result is either a current receipt or a plain-language explanation that nothing happened.

The product also includes:

  • keyboard and screen-reader semantics;
  • on-demand speech for the exact order;
  • reduced-motion and narrow-screen layouts;
  • visible current tool authority;
  • clear ineligible-prescription explanations;
  • explicit stale-record recovery; and
  • a complete manual path when WebMCP is unavailable.

ExactCue does not claim to prove spoken assent. It proves that the reviewed payload was bound to a particular record version and checked again at commit time.

How we built it

The system follows one inspectable path:

Person + UI ↔ shared order state ↔ WebMCP tools → Netlify Function → Blob conditional write → receipt or recovery

  • Browser: React and TypeScript power the visible flow and the shared order state.
  • WebMCP: document.modelContext.registerTool publishes typed actions. An AbortController retires tools when their step ends.
  • Exact Cue: one snapshot binds the prescription IDs, pharmacy, spoken readback, record version, and ETag fingerprint.
  • Server: a Netlify Function rebuilds and validates the order against authoritative data.
  • Storage: Netlify Blobs uses strong reads and onlyIfMatch conditional writes. A losing request cannot overwrite the current record.
  • Proof: every result includes a structured next action; successful writes return a receipt, while conflicts return the current record with noWrite: true.

Synthetic run IDs isolate judge sessions without acting as credentials. Operational logs deliberately exclude session IDs, ETags, request bodies, and patient/order fields.

Architecture

PERSON + BROWSER AGENT
        │
        │ prepares prescriptions + pickup
        ▼
REACT UI ↔ SHARED ORDER STATE ↔ STEP-SCOPED WEBMCP TOOLS
        │                         select · review · submit · recover
        │
        ▼
EXACT CUE
prescription IDs + pharmacy + spoken readback + record v1 + ETag
        │
        │ submit_refill(confirmed: true)
        ▼
══════════════ AUTHORITATIVE COMMIT BOUNDARY ══════════════
        ▼
NETLIFY FUNCTION
rebuild current order → validate reviewed payload → compare ETag
        │
        ▼
NETLIFY BLOBS · onlyIfMatch(ETag)
        ├── CURRENT ──→ atomic write ──→ authoritative receipt
        └── STALE   ──→ HTTP 409 · NO WRITE ──→ reload_current_record

The architecture is deliberately split at the commit boundary. The browser agent prepares shared state and WebMCP carries the exact reviewed cue. A Netlify Function then rebuilds the authoritative order and uses a Netlify Blobs ETag compare-and-swap. The only valid outcomes are a current receipt or HTTP 409 · NO WRITE with a structured recovery tool.

Challenges we ran into

Retiring tools safely. A WebMCP tool can advance the state while its own invocation is still resolving. Aborting its controller immediately can discard the result, so ExactCue retires the previous tool surface on the next task after Chrome delivers the response.

Proving a real conflict. Client-side validation could only imitate safety. We separated the domain state machine from storage, tested stale and replay paths locally, then captured two real conditional requests against the public Netlify deployment.

Drawing an honest boundary. ExactCue cannot infer whether a person truly intended a spoken “yes.” It can prove the narrower - and useful - guarantee that the payload presented for review is the payload checked against current server state.

Accomplishments that we’re proud of

  • A complete prepare → review → verify → recover → receipt product journey.
  • Native WebMCP execution drives the same state shown in the human interface.
  • Tool authority changes with the workflow; navigation cannot bypass the committing action.

What we learned

A useful agent experience needs more than callable functions. The page should expose authority that changes with state, return structured recovery instructions, and show the same boundary to the person.

We also learned to separate three moments that are often blurred together:

  1. a person reviews an action;
  2. the page binds that review to one precise proposal; and
  3. the server decides whether that proposal is still current.

WebMCP connects the human and agent sides of that contract inside the user’s browser. Conditional server state makes the contract trustworthy under failure.

What’s next for ExactCue

We would co-design the cue and recovery language with people who use nonvisual interfaces, test additional WebMCP clients, and formalize confirmation provenance as the API evolves.

Then we would package the current-state cue pattern for other consequential workflows - benefits, banking, travel changes, and government services - where an agent can prepare complexity but a person should own the final, current decision.

Built With

  • document.modelcontext
  • motion
  • netlify-blobs
  • netlify-functions
  • react
  • typescript
  • vite
  • vitest
  • webmcp
Share this project:

Updates

Submission history