Use case · teams shipping with an agent

Interactive product demos, recorded by your agent.

Your agent just built a flow. Instead of a screen recording or “pull the branch and run it”, it walks the real thing and hands you a click-through demo — a link that opens in any browser, at the viewer's own pace.

Showing a flow
costs more than building it.

re-recording a video every time the flow changes
“can you pull the branch and check it?”
screenshots that go stale by the next commit
feedback that arrives as “the second screen looks off”

Let the agent record it.

Four steps, and
none of them are yours.

1 · The flow is written as a plan

Plain markdown: open, click, type, check — one line per step. The agent writes it from the flow it just implemented, so the plan and the code never drift apart.

2 · The agent walks it in a real browser

Not a mockup and not a screen recording — an actual browser session against the running app, one captured frame per step, with the cursor shown where it clicked.

3 · One link, no install

Your teammate, your designer or your client opens it in a browser. No account, no extension, no “which branch was that again”.

4 · The flow changes, the link doesn't

Re-run the same plan and the frames are replaced in place. Whoever you already sent the link to sees the current build, not the one you shot last month.

A walkthrough shows. Feedback still comes from the page.

The frames are read-only by design — one step per screen, each with its caption and its line of the summary. When a reviewer wants to change something, they pin it on the running page, where the selector, the computed styles and the console come attached.

Claude Code · via MCP: “Fixed the empty-state copy on step 3 of the checkout flow. Commit 8b1e40.”

Here's a real one.

Not a screenshot of a demo — the demo itself, recorded by the CLI on this very site. Click through it at your own pace.

Recorded with handoff walk — the same command your agent runs.

What is a click-through demo?

A click-through demo is a captured sequence of a real product flow that a viewer clicks through at their own pace — no live call, no test account, no install. Each step is a real frame from the real interface, not an illustration of it.

The category grew out of sales and onboarding, where a demo is built by hand: someone opens the product, clicks every step and edits the result. That's fine when a demo is a one-off asset. It stops working when the flow changes every week, because every change means recording it again.

Handoff comes at it from the other end. The demo is recorded by the agent that built the flow, from a plan that lives next to the code — so re-recording costs one command — and it lands on the same link, which is what keeps a demo from ageing behind the product.

Questions

Do viewers need an account?

No. They open a link in any browser. No account, no extension, nothing to install — that's the whole point of sending a link instead of a branch.

Does it work on a local dev server?

Yes. The agent walks the app wherever it runs — localhost included — and the captured frames are what gets shared, so the viewer never needs access to your machine.

How is this different from a screen recording?

A recording plays at your pace and can't be paused usefully. A walkthrough is clicked at the viewer's pace, one step per screen, with a written summary of what changed beside it.

What happens when the flow changes?

The agent re-runs the plan. Re-recording is one command, so the demo tracks the code instead of aging behind it.

Can I take a link back?

Yes — handoff revoke closes access to a link you've already sent.

Stop re-recording the same flow.