A desktop automation demo is a playback, not a real automation.

The frame the question gets wrong

Type the topic into a search bar and you get RPA tool listicles. Power Automate, UiPath, Leapwork, Ui.Vision, TestGrid. Every one of those is a real production scripting engine for clicking buttons inside native apps on a real operating system. They are the right answer when you are shipping an automation for daily use against a known computer.

They are the wrong answer when the artifact you actually need is a three-minute video, a clickable URL, or a hackathon submission that has to run on a stranger's laptop without setup. A real RPA flow that depends on local Excel installs and accessibility permissions does not survive being shipped to ten different judges. A web-based playback does. The two problems look identical from the outside (the visual is the same: cursor moving, files moving, output appearing) and they are completely different to build.

A demo is a story you can rehearse. An automation is a contract with the operating system. Pick one for the job at hand. This page is about the first one.

One sentence in, one playback out

The shape of a useful first prompt names three things: the surface (what the viewer sees at rest), the trigger (what starts the playback), and the punch line (the visible change at the end). Everything else is iteration.

A demo of an "auto-organize my desktop" tool.
Surface: a Mac-style desktop with about 30 messy icons (random
filenames, jpeg / pdf / docx / mp4 mix), a thin top bar with a
"Scan and tidy" button, and a hidden Trash icon at the bottom-right.
Trigger: the user clicks "Scan and tidy". A cursor sprite glides
from the icon grid up to the button and clicks it.
Playback: a terminal panel slides in from the bottom and streams
about 12 lines of plausible scan output over 3 seconds. As scanning
finishes, files of the same type group themselves into folders
(Images, Docs, Videos), and 3 duplicate jpegs flash red and slide
into the Trash. A counter at the top animates from 0 to "27 files
organized, 3 duplicates removed" with a confetti burst.
Style: warm desktop wallpaper, soft shadows, generous spacing, a
single teal accent for the button and the counter. Mobile-aware
but the desktop layout is the default.

That paragraph is opinionated by design. It commits to one specific automation (organizing desktop icons), one specific playback (cursor + terminal + file moves + counter), and one specific punchline (confetti and a number). mk0r writes the React for it in one streaming pass. From there, iteration is conversational: slow the cursor down, replace the confetti with a checkmark, swap the terminal for a progress bar, change the counter to a percentage. The first draft is the slowest part; everything after is talking.

Four beats every playback hits

Every demo of automation, regardless of the underlying problem, follows the same rhythm. If any beat is missing or rushed, the audience does not read it as automation; they read it as a confusing animation.

Total wall-clock for the playback should be 6 to 12 seconds. Shorter and the viewer cannot read the work. Longer and you lose them. If the underlying automation in real life would take an hour, the demo still has to finish in 12 seconds; that is the point of a demo.

What the playback actually is, in one timeline

Underneath the visuals, every playback is a chain of setTimeoutcalls posting React state updates against a fake data model. Here is the timeline for a duplicate-file scan, with the viewer's click as the entry event and React state transitions feeding the rendered surface.

Notice nothing in this sequence touches the operating system, the file system, or any external API. The mock store is a plain JavaScript object held in component state. The terminal lines come from a hard-coded array. The duplicate file paths are made up. The viewer reads the run as automation because the visual choreography is right, not because anything got automated.

Believable inside the iframe, dishonest outside it

The honest list. Anything in the first column is fair game and will read as automation. Anything in the second column the demo cannot do; do not build a script that pretends to.

The free screen recording you did not ask for

Most demo authoring tools charge for the screen recording. Loom, Tella, Arcade, Navattic, all of them are essentially capture-and-edit pipelines with hosting on top. mk0r ships the capture pipeline as part of how the live preview already works, because the agent uses it to verify its own writes.

Inside the sandbox VM, a small Node proxy at docker/e2b/files/opt/proxy.js opens a Chrome DevTools Protocol WebSocket against the headed Chromium, sends Page.startScreencast, and listens for Page.screencastFrame events. Each frame arrives as base64-encoded JPEG bytes. The proxy throttles to one frame every 66 milliseconds (line 287), decodes the buffer, and writes it to disk as /tmp/video/frames/frame followed by a six-digit zero-padded index, ending in .jpg. The same buffer also goes out over the WebSocket to the parent window, which is what makes the live preview visible.

Two things follow from this. First, every iteration of your demo is silently captured to disk; the directory grows the entire session. Second, ~15 fps is enough for a desktop UI playback (no fast camera pans, no high-FPS gameplay), so the recording is usable as-is. Stitch the frames into an MP4 with ffmpeg -framerate 15 -i frame%06d.jpg -c:v libx264 -pix_fmt yuv420p out.mp4, or into a GIF with one extra palette pass. You did not have to install OBS, you did not have to fight Loom permissions, and you did not have to pay a per-seat fee.

A demo that responds to the presenter, live

A pure auto-play demo is fine for an embedded landing page. For a stage talk or a sales call you want the demo to wait for a human click, then run. The mk0r preview pipeline already pipes real input events from the parent window into the sandboxed Chromium via CDP.

Around line 401 of the same proxy file, a second WebSocket relay accepts JSON messages from the parent: {type:"mouse",x,y,action,button}, {type:"key",key,code,text,action}, {type:"scroll",x,y,deltaX,deltaY}, {type:"insertText",text}. The relay forwards each one to the headed Chromium as the matching CDP method (Input.dispatchMouseEvent, Input.dispatchKeyEvent, Input.insertText). The browser inside the sandbox cannot tell the difference between these synthetic events and a real user mouse, so the React app inside reacts the same way.

For your demo, this means the Run button works whether the audience is looking at a presenter clicking it on stage or at a recorded URL on Twitter. You build the same React, you wire one onClick to start the timeline, and the input pathway is already there. No additional plumbing.

A useful side effect: the playback is also drivable programmatically. If you wrap the demo in Playwright, you can replay the click trace from a script, capture frames, and produce a deterministic recording. That is how the agent verifies its own output without you watching, and it is the same primitive your eventual real automation engine will use against a real OS.

Eight first prompts that produce useful demos

If you are stuck on what to demo, pick one of these and paste it into the prompt box. Each one is a complete enough surface that the first draft is shareable.

The pattern is consistent: name the surface, name the trigger, name the change. Save the iteration for the second turn. Trying to specify the entire demo in one paragraph produces worse first drafts than starting plain and adding detail by talking.

What the demo plays well alongside

The demo is one artifact in a chain. Here are the tools it tends to share a workflow with, both for shipping the demo and for the day you graduate to real automation.

mk0r is not trying to replace any of these. It is the front end where the demo is born and the place where the captured frames live. After that, you pick the right shipping format (raw URL, MP4, GIF, hosted walkthrough) and, if the idea wins, the right native runtime (Tauri, Electron) and engine (PyAutoGUI, AppleScript, AutoHotkey, .NET UIAutomation, Playwright).

When to stop demoing and start building

The demo has a clear end-of-life signal. The first time someone asks "what about [specific OS, specific app version, specific edge case]?" with a real budget behind the question, the demo has done its job. Move on. Export the source from the sandbox (Vite + React + Tailwind, no proprietary format), wrap it in a desktop runtime, and start the boring work: probing accessibility APIs, handling locale differences, code-signing the binary, paying for notarization, building an installer.

The React you sketched in the demo carries over verbatim, because it is normal React. The setTimeout-driven timeline gets ripped out and replaced with real event handlers wired to your engine over IPC. The cursor sprite goes away because the real OS cursor takes over. The mock file list becomes a real directory listing. The terminal panel becomes a tail of real subprocess output. The visual hierarchy survives intact, because nothing about it depended on the playback being fake.

Most of the demo is a permanent contribution to the eventual product. The bit you throw away is small. That is what makes it a useful first move and not a tax.

Frequently asked questions