How I Made a Product Demo with Claude Code, Playwright, and FFmpeg

Eric Mono — Mon, 13 Jul 2026 14:47:14 +0000

I recently needed a short product demo for my open-source project called Agent OS.

The goal was modest: create a clear 45–60 second walkthrough of the real product.

I didn't need a polished advertisement. I also didn't want to:

manually record a dozen clips
learn Premiere or After Effects
move every cut and caption on a timeline
recreate the product interface with generated animation

So I tried a simpler workflow:

Claude Code + Playwright + FFmpeg

The result was a 56-second silent MP4 created in roughly 30 minutes, using around 50K tokens with Opus 4.8.

What Claude Code handled

Claude Code first inspected the application and identified the existing product states that could form a complete story:

The Agent OS landing page
Main Agent planning and Coding Agent handoff
A real task graph and execution trace
Build, browser, and visual verification
A failed browser run with runtime evidence
A linked bounded-recovery run
A preview-only Git contract
The finished Pulseboard application

It then started the locally served frontend and backend and used Playwright to navigate through those states.

Nothing was recreated or fabricated for the video. The walkthrough used existing persisted run records from the real Pulseboard build.

Why it recorded several short clips

The first instinct was to record one continuous browser session.

That became unreliable when dense modals and long smooth scrolling caused the Playwright video encoder to fall behind.

The practical fix was simple:

record one short clip for each narrative beat
give each clip its own BrowserContext
store the content start and end times
close the context after every clip so the recording is finalized

The result was much more stable than one long recording.

What FFmpeg handled

After Playwright produced the raw WebM files, a small Python script used FFmpeg to:

trim each clip to its useful content window
add short labels
create a simple opening card
create a GitHub end card
concatenate everything
export a 1280×720, 30 fps H.264 MP4

There were no complex transitions. The product interface remained the main visual.

Why this workflow was useful

This will not replace professional video editing.

But it seems well suited to:

open-source project demos
internal product walkthroughs
release previews
reproducible UI recordings
projects where authenticity matters more than elaborate motion graphics

The useful shift was treating the demo as another automated software artifact.

The browser flow is code.
The selected product state is deterministic.
The labels and timings are configuration.
The video can be regenerated when the interface changes.

The project shown in the demo

Agent OS is a local-first AI Project Operating System — the harness around coding models that adds persistent memory, controlled execution, real verification, bounded recovery, and approval-gated delivery.

The project is open source here:

https://github.com/earthwalker17/agent-os

The demo doesn't prove that the system is perfect. It simply gives people a much faster way to see what it actually does.

Agent OS: A Local-First Harness Around Coding Models

Eric Mono — Fri, 10 Jul 2026 16:48:13 +0000

A coding model can generate code.

That does not mean it can reliably finish software work.

Between a plausible diff and a completed task, a real software agent still needs memory, execution boundaries, verification, recovery, permissions, and delivery infrastructure.

That is the problem I have been exploring through Agent OS, which I have now released as an open-source project.

GitHub:

https://github.com/earthwalker17/agent-os

The model is only one part of the agent

Agent OS is a local-first AI Project Operating System: a harness around coding models.

The core architecture separates two responsibilities.

Main Agent: the brain

The Main Agent handles:

Conversation
Planning
Project memory
Context assembly
Orchestration
Delegation decisions

It cannot edit repository code or execute shell commands.

Coding Agent: the hands

The Coding Agent operates inside one sandboxed project workspace.

It can inspect files, edit code, and run bounded commands, but it cannot modify project memory or access another project’s workspace.

The two sides communicate through summaries and structured artifacts rather than unrestricted shared control.

“Done” must come from verification

Agent OS does not accept the model’s own claim that a task is complete.

A coding run must pass a real build or test command.

It can then:

Launch the application
Walk declared browser flows
Capture screenshots and runtime evidence
Run visual review
Classify failures
Propose or execute a bounded repair pass

Recovery is deliberately limited. The goal is not unlimited autonomy, but controlled progress with evidence and an audit trail.

External actions remain human-controlled

Git pushes, pull requests, deployments, database migrations, and Stripe test-mode operations use explicit preview-and-confirm contracts.

The agent can prepare the operation, but it cannot silently mutate an external system because it inferred that the user probably wanted it.

Testing the system on a real product

To pressure-test the architecture, I used Agent OS itself to build and deploy Pulseboard, a full-stack SaaS, from an empty repository.

The process included real build, runtime, browser, visual, deployment, and database failures. Those failures became the test for whether the system could collect evidence, expose the problem, and recover instead of simply producing a confident success message.

What is included in the first public release

Local filesystem and SQLite-based project state
Structured Markdown memory
Claude, GPT, Gemini, DeepSeek, Kimi, and GLM support
Sandboxed coding execution
Parallel agent teams in isolated workspaces
Command, browser, and visual verification
Typed bounded recovery
GitHub, Vercel, Supabase, and Stripe test-mode connectors
Apache-2.0 licensing
GitHub CI and 832 backend tests
One-command Windows installation

Current limitations

This is an early public release.

The Windows setup is currently the most thoroughly tested. macOS and Linux users need to follow the manual setup instructions. At least one supported model provider API key is required.

Local-first means that project memory, workspaces, credentials, and execution records remain under the user’s control. It does not currently mean that every supported model runs locally.

What I am looking for

I am especially interested in feedback on:

The separation between the Main Agent and Coding Agent
The first-run installation experience
The boundaries of automated recovery
Which internal components should become independent libraries

The repository, architecture documentation, installation guide, and production showcase are available here: