Bring your own agent demo: Build it in your repo

Demo workflows usually fall into one of two buckets that most tutorials gloss over: demos that live inside a vendor's platform, and demos that live in your repo, where your own agent can create, update, and ship them like code. A bring your own agent demo is the second kind, and this guide is for founders, product engineers, and builders who want that workflow from start to finish.

The difference is not cosmetic. If the demo is a recording in Supademo or Arcade, a UI change means re-recording. If it's code in your repo, a UI change means editing a file and re-prompting. That's the split.

What a bring your own agent demo actually means

The line between an agent-built demo and a hosted recording

Most interactive demo tools produce an artifact, a recording, a captured flow, or a hosted tour, that lives on their servers and can only be edited through their UI. You can share it, embed it, and tweak it in their editor. You cannot put it in a pull request, diff it against last week's version, or hand it to Cursor and say "update the nav."

An agent-built demo produces code. The output lands in your repo as files you can read, edit, commit, and re-prompt. The demo becomes a normal artifact in your codebase, not a SaaS object sitting behind someone else's dashboard.

Why code ownership changes the job

When the demo is code, maintaining it is the same job as maintaining the product. You open a file, make a change, run a check, commit. Same tools, same habits. Your agent, Cursor, Claude Code, Codex, can touch the demo the same way it touches anything else in the repo.

When the demo is a hosted recording, maintenance becomes a separate job in a separate tool with a separate login. Every product change creates extra work: fix the product, then fix the demo. That adds up fast. Code ownership cuts out that second pass.

In one project, demo files sat in `/demo` right beside `/app`, with the same repo, same CI, same agent session. When a nav item moved, the agent updated both in one pass.

Structure the repo so the demo is easy to own

A repo tree the team can read at a glance

A repo-native demo needs a predictable home. Here's a shape that works:

The rule is simple: anyone on the team should be able to open `/demo` and know where to look without asking. Prompts go in `/prompts`. Assets go in `/assets`. Generated output goes in `/src`. Nothing else.

This is the same idea as docs-as-code setups, and Mintlify's approach to keeping docs next to product code applies here too. The demo is just another artifact the team owns.

What belongs next to the prompt and what does not

Version-controlled files: prompt briefs, asset sources like SVGs, config files, and the demo's flow definition. Those are the source of truth. Change them on purpose.

Do not version intermediate renders, auto-generated screenshots, or build artifacts. Those are outputs, not inputs. Regenerate them. Do not commit them. A `.gitignore` entry for `/demo/src/generated` keeps the repo clean.

The test is straightforward: if deleting the file would cost you information, version it. If you can recreate it from something else in the repo, leave it out.

Give the agent a source of truth before it writes anything

Ground it with product copy, UI rules, and real assets

An agent writing a demo without grounding will invent things. It'll use placeholder copy, approximate UI, and flows that do not match the actual product. The fix is explicit context files the agent reads first.

At minimum: a `product-copy.md` with the current value proposition and key feature names, a `ui-rules.md` with navigation structure and terminology, and an `/assets` folder with the real logo and brand colors. The agent reads those before it writes a line of demo code.

PostHog's work on building an AI envoy makes the same point: agents work best when they get structured context from your own codebase, not when they're left to infer everything from loose instructions.

The one-prompt demo brief that does useful work

A strong prompt brief has four parts:

• Goal — what the demo needs to prove ("show that a founder can set up a pipeline in under five minutes")
• Audience — who's watching and what they already know ("seed-stage investor, technical, has seen Supademo-style demos before")
• Path — the exact screens and actions in order ("dashboard → new pipeline → add stage → invite teammate → done")
• Constraints — what the agent must not do ("don't show the settings page, don't use placeholder names, use the assets in /assets")

Four parts. One file. The agent reads it, writes the demo, and you review the output instead of re-recording it.

Create the first bring your own agent demo from one prompt

The first build pass should aim for pitch-ready, not perfect

Run the agent against the prompt brief. The first output will be close but not final. Expect to trim screens that wander off the core path, fix copy that drifted from `product-copy.md`, and tighten the flow to the five or six moments that actually matter.

The sequence is simple: generate, open the output in a browser, walk the path as if you're the viewer, cut anything that does not move the viewer forward, commit.

Vercel's observation that anyone can build agents but it takes a platform to run them applies here. The first generation is fast. The hard part is the review pass, not the prompt.

What a good first demo leaves out

The overbuild trap is real. The agent will happily generate twelve screens if you let it. A pitch-ready demo needs three to six. Cut anything that:

• Explains a feature the viewer does not need yet
• Shows a settings or admin screen that is not part of the core value path
• Adds motion or animation that slows the viewer down without adding information

The demo's job on day one is to prove one thing clearly. Every extra screen is another chance for the viewer to get lost.

Update the demo without re-recording the whole thing

What changes when the product UI shifts

This is where a code-owned demo earns its keep. When a button label changes, you update `product-copy.md`, re-prompt the agent against the affected demo screens, and review the diff. When a nav item moves, you update `ui-rules.md` and regenerate. The change is surgical. Only the affected pieces get touched.

On a screenshot-based tool, a nav restructure forces you to recapture every screen that shows the nav. On a code-owned demo, the nav is just a config value. Change the value, re-prompt, done.

Version prompts and assets before the team starts improvising

Prompt files should be versioned the same way config files are. When someone changes the demo brief, new audience, new flow, new constraints, that change goes into the prompt file with a commit message, not into a Slack thread.

Same for assets. When the logo updates, the old version goes into `/assets/archive`, the new version replaces it in `/assets`, and the next regeneration picks it up automatically. No manual hunt through a Figma file.

The failure mode is one-off edits directly to the generated `/src` files. Those edits get overwritten the next time the agent runs. Anything that needs to survive a regeneration belongs in the source-of-truth files, not the output.

Test, publish, and hand off the demo like part of the product

How to check the demo before it reaches a launch page

Before the demo goes anywhere public, walk the path in staging:

• Does every screen match the current product UI?
• Does the copy in the demo match `product-copy.md`?
• Does the flow still make sense after the latest code change?

This is a five-minute check, not a QA cycle. The point is to catch the demo showing last week's UI before a prospect does. Stripe's lessons on building for agentic workflows include a consistent theme: agents need a review gate before their output reaches users. Same idea here.

The handoff between founder, engineer, and marketer

Each role touches the same demo differently:

• Founder changes the brief — updates the goal, the audience, or the core path in the prompt file.
• Engineer keeps the code honest — updates `ui-rules.md` when the product ships, triggers the regeneration, reviews the diff.
• Marketer adapts the surface — swaps assets, adjusts copy in `product-copy.md`, produces a variant for a specific campaign or vertical.

None of these roles need to re-record anything. They edit a file and re-prompt. The demo survives multiple owners because the source of truth lives in the repo, not in someone's head.

Where Inkly comes in

The structural problem this workflow solves is ownership: every other demo tool makes the demo an object inside their platform, which means every update or per-customer variant sends you back into their editor. The demo is never really yours.

Inkly is built on the opposite premise. The demo is code you own, generated by your agent (Cursor, Claude, Codex), living in your repo, editable like any other file. The three-prompt loop is the whole workflow: prompt to create the first demo, prompt to update it when the product ships, prompt to produce a variant for the next customer or pitch. No re-recording, no SaaS editor, no artifact stuck in someone else's cloud.

The tradeoff is honest enough: Inkly's MVP is bring-your-own-agent. You need Cursor, Claude Code, or Codex already set up. A hosted in-app agent is on the roadmap, not shipped yet. If you do not already have an agent workflow, that's the prerequisite.

If you do, the demo becomes code you own and iterate. You get the same first-capture speed as Supademo, and every update after that costs a prompt instead of a re-recording.

FAQ

Q: What does bring your own agent actually mean in a demo workflow?

It means the demo is created and maintained by your own coding agent, Cursor, Claude Code, Codex, and the result lives in your repo as code you control. The agent builds the demo from a prompt brief, not a screen recorder. You own the output, can diff it, version it, and re-prompt it without going through a vendor's UI.

Q: How do you set up a repo-native demo that the team can own and update?

Create a `/demo` directory with four subdirectories: `/prompts` for versioned prompt briefs, `/assets` for logos and brand tokens, `/src` for generated demo code, and `/config` for product copy and UI rules. The source-of-truth files live in `/prompts`, `/assets`, and `/config`. The generated output in `/src` gets regenerated from those files, so do not edit it directly.

Q: How can one prompt produce a pitch-ready agent demo fast?

A tight brief is the whole trick. Give the agent four things: the goal the demo needs to prove, the audience watching it, the exact screen path in order, and the constraints it must respect. Four parts in one file. The agent writes the demo; you review and trim the screens that wander off the core path. The first pass is usually close enough to share.

Q: How do you keep the demo maintainable so you do not have to re-record every time it changes?

Keep the source of truth in config files, not in the generated output. When the product UI shifts, update `ui-rules.md` or `product-copy.md`, re-prompt the agent against the affected demo screens, and review the diff. Only the changed pieces get touched. The demo stays current because the inputs are versioned, not because someone re-recorded every screen.

Q: What files, prompts, and assets should live in the repo to support iteration?

Version-control these: the prompt brief, `product-copy.md`, `ui-rules.md`, flow definitions, and asset sources like SVG files, not PNG exports. These are inputs. Losing them means losing the ability to regenerate accurately. Do not version intermediate renders or build artifacts; those are outputs and should be regenerated, not committed.

Conclusion

The repo-native split from the intro is the whole answer: if the demo lives in your repo, your agent keeps it current without a re-recording loop. If it lives inside a vendor's platform, every update becomes a separate job in a separate tool.

Pick one existing demo this week, a Supademo capture, a Loom, a slide deck you've been using as a demo. Move the source of truth into a `/demo` folder: write the prompt brief, drop in the assets, document the flow. Then regenerate the first pass from your agent. That's the whole migration. After that, it's prompts, not re-records.