Agentic demos: Build them like code, not slides

Every demo tool gives you the same honeymoon. You capture the flow, it looks sharp, you send it, the prospect clicks through. Then you ship a release. Then another. Three sprints later, the demo shows a nav item that moved, a feature that was renamed, and a pricing page that no longer exists. The demo is still there. It's just showing last month's product.

That's not really a maintenance problem. It's an ownership problem. The demo lives inside someone else's SaaS, so every product change turns into a vendor-specific update job instead of a normal repo change. This guide shows how to build agentic demos like code, version them like code, and update them like code so the demo stays honest without a separate content workflow.

What agentic demos are, in plain terms

The line between a demo, a tour, and an agent

A standard product tour follows a fixed path: click here, see this, advance. An interactive demo responds to where the user clicks within a bounded flow. An agentic demo goes one step further. It adapts within a bounded product story based on what the user is actually trying to understand.

The key word is bounded. An agentic demo is not a chatbot with full product access. It's a controlled workflow with a defined scope: specific flows, approved claims, and a clear line where it stops and hands off.

What the agent is actually doing

The agent reads from a narrow knowledge source: your product docs, approved copy, and a set of allowed product facts. It takes user input, maps it against that context, and returns a response or advances the demo state. What it cannot do is reach outside the defined scope. No live database queries. No improvised claims. No answers beyond what you've approved. PostHog's notes on building AI agents make this point well. Your context is your advantage, and the harness is what keeps the agent useful rather than dangerous.

Why code-native agentic demos beat re-recording every release

The lock-in problem nobody likes admitting

When the demo lives inside a SaaS platform, you don't own it. The platform does. A nav rename in your product means opening the vendor's editor, finding every affected screen, and re-recording or re-editing each one. That's not a small tax. It's a separate content workflow running in parallel to your product workflow, forever.

Code-native demos break that dependency. The demo is a file in your repo. A product change is a code change. The update path is the same as any other change: edit, review, merge.

Why re-recording is the wrong unit of work

Re-capture is a symptom of the wrong system design. The artifact sits apart from the code, so even small UI changes force manual repair on the demo side. The demo and the product become two different things maintained by two different processes, and the gap between them grows every sprint.

The right unit of work is a diff. One prompt, one branch, one review. Not a fresh recording session.

What changes when the demo lives next to the product

One repo. One review flow. One place to update behavior when the product or messaging changes. The demo gets treated like code because it is code. It has a history, it has reviewers, and it has a clear owner. When something breaks, the fix is a PR, not a screen-recording session.

Set up the repo so the demo is a real asset

A folder layout you can actually maintain

A working demo repo structure looks something like this:

This isn't a monolith. It's a set of clear responsibilities. The reader should be able to open any folder and know what lives there and why.

What belongs in scripts, what belongs in content, what belongs in guardrails

Scripts handle product logic and flow sequencing. Content handles copy, labels, and approved claims. Guardrails handle what the agent can say, what it must refuse, and what routes to a human. Keep these separate. The moment product logic and copy live in the same file, every copy change risks breaking the flow, and every flow change risks changing what the agent says.

The smallest version that still deserves Git

A solo founder's minimum viable demo repo is three files: one flow script, one system prompt, one guardrails file. That's enough to version, review, and update without a separate process. Start there. Add fixtures and sandbox data when the demo needs them, not before.

Map product flows, context, and guardrails before the agent goes live

Choose the one flow the buyer actually needs

Pick one story first. Not the full product. One buyer-critical path. Signup and activation, or the core reporting view, or the one feature that closes deals. An agentic demo that tries to teach the whole product is an agentic demo that teaches none of it well.

Feed the agent the right context, not the whole knowledge base

Narrow the knowledge source to what the demo actually needs: the docs for the flows in scope, the approved product claims, the pricing facts you're willing to defend. More context doesn't make the agent smarter. It makes the agent noisier. A tight retrieval scope is the simplest way to reduce hallucination in a demo context.

Draw the safety line where the agent stops

The guardrails file is the boundary condition: what the agent can say, what it must refuse, and what should return a fixed response or route to a human. A concrete example: the agent can explain how the reporting dashboard works; it cannot quote a custom enterprise price; it cannot answer questions about the roadmap. Write the refusal rules before the demo goes live, not after the first bad answer.

Connect agentic demos to staging data, docs, and your build workflow

Use staging as the source of truth, not a demo clone

Wire the demo to a staging environment or a set of staging fixtures, not a hand-maintained demo clone. A demo clone drifts the moment the product ships. Staging fixtures can be regenerated from the same pipeline that builds the product, so the demo reflects real behavior without becoming a risky live copy.

Pull in docs only where they reduce hallucination

Docs help the agent answer buyer questions it would otherwise improvise. But more docs also means more surface area for the agent to wander. Scope the retrieval to the sections that cover the flows in the demo. If a doc section isn't relevant to the demo's product story, leave it out of the knowledge source.

Make the demo part of the same AI-assisted build loop you already use

If you're already using Cursor, Claude Code, or Codex to write and update product code, the demo should live in the same loop. A UI change triggers a prompt to update the demo flow. A new feature gets a new fixture. A messaging change gets a copy update in the content folder. The AI-assisted build workflow that maintains your product can maintain your demo. They're the same kind of work.

Version and ship demo updates like any other code change

The Git diff that turns a demo update into a normal review

A nav rename in the product becomes a one-line change in the flow script. A pricing update becomes a copy change in the content folder. A new guardrail becomes a new rule in the guardrails file. Each of those is a diff: reviewable, reversible, attributable. That's what versioning buys you, not just history but accountability.

Branching, review, and release without a separate content process

Edit in a branch. Review the behavior against the flow script. Merge when the demo matches the current product. Keep the demo tied to the same release rhythm as the product, not a separate quarterly update cycle. When the product ships, the demo ships with it.

What to do when the product and the demo diverge

Treat mismatch as a code problem. Run the demo against the current staging fixtures. Where the flow breaks or the copy is wrong, open a branch and fix it. The repair path is specific: find the diff, write the fix, review, merge. Not a marketing scramble. A PR.

Use agentic demos across sales, marketing, onboarding, and POCs

Where one demo can do more than one job

The same core demo can support marketing qualification, embedded on the site; sales calls, run live with a rep in the loop; onboarding, self-serve after signup; and POC evaluation, scoped to the prospect's use case. One repo, one flow, multiple surfaces. The demo doesn't need to be rebuilt for each context. It needs to be configured for it. That's a prompt, not a recording session.

When to keep a human in the loop

Agentic demos handle self-serve explanation well. They don't handle enterprise qualification, procurement negotiation, or edge cases the guardrails weren't written for. When the buyer's question falls outside the defined scope, the demo should say so and route to a human, not improvise. The agent reduces friction on the explanation side. It doesn't replace judgment on the sales side.

Who gets the most value first

Solo founders and small product teams with fast-moving product surfaces. If you ship weekly and your demo lives in a SaaS platform, you're already paying the re-record tax every sprint. Agentic demos fit founders best when the product changes faster than a human can keep a separate content workflow in sync.

Where Inkly comes in

The structural problem this guide describes — the demo trapped in a vendor platform, updated by hand, out of sync with the product by the next sprint — isn't a workflow problem. It's an ownership problem. The demo needs to be code you own, living next to your product, maintained by the same agent that maintains your product code.

Inkly is built on that premise. The three-prompt loop — prompt to create, prompt to update, prompt to produce a variant — replaces the re-record cycle entirely. A UI change is a re-prompt against the existing demo code, not a fresh capture session. A new customer is a variant off the same base, not a rebuild. The demo lives in your repo, reviewed in Git, updated through the same AI-assisted build loop you already use. The tradeoff is simple: you bring your own agent (Cursor, Claude, Codex). The hosted in-app agent is roadmap, not shipped yet. But if you're already in that loop, the demo becomes code you own and update with a prompt, without a separate content workflow or vendor lock-in.

FAQ

Q: What is an agentic demo, in plain terms, and how is it different from an interactive demo or a standard product tour?

A standard product tour follows a fixed path. Every user sees the same sequence. An interactive demo responds to clicks within a bounded flow. An agentic demo adapts within a bounded product story based on user intent. It can answer questions, advance different paths, and respond to what the user is actually trying to understand. The boundary is the key distinction. An agentic demo is a controlled workflow with a defined scope, not an open chatbot.

Q: How do you build an agentic demo fast if you want it to behave like code and stay easy to update?

Start with one flow, a clear folder layout (flows, assets, prompts, guardrails, fixtures), and Git from the first commit. The minimum viable version is three files: one flow script, one system prompt, one guardrails file. Wire it to staging fixtures rather than a hand-maintained clone. Updates are diffs: one prompt, one branch, one review, not re-recording sessions.

Q: What parts of your product need to be mapped, scripted, or guarded before an agentic demo can safely go live?

Pick one buyer-critical flow and script it completely. Narrow the knowledge source to the docs and approved claims that flow actually needs. Then write the guardrails: what the agent can say, what it must refuse, and what routes to a human. The refusal rules matter most. Write them before the demo goes live, not after the first answer you didn't want.

Q: How can an agentic demo improve buyer understanding and qualification without replacing a human sales call?

The agent handles self-serve explanation, walking a buyer through the core flow, answering questions within the defined scope, and advancing the product story at the buyer's pace. It doesn't handle enterprise qualification, procurement, or edge cases outside the guardrails. The right model is simple: the agent reduces friction on explanation, the human handles judgment. When the buyer's question falls outside scope, the demo routes to a rep. It doesn't improvise.

Q: What does a good workflow look like for testing, versioning, and shipping changes to a demo over time?

The same rhythm as any code change: edit in a branch, review the behavior against the flow script and staging fixtures, merge when the demo matches the current product. When the product ships, run the demo against the updated staging environment and open a PR for any drift. The demo stays tied to the product's release cycle, not a separate quarterly update process.

Conclusion

The demo stops being fragile the moment it becomes code you own, review, and update like the rest of the product. Everything else in this guide — the folder layout, the guardrails file, the Git diff as the unit of update — follows from that one structural fact. Pick one product flow, put it in the repo, and ship the first version through Git this week. The second update will tell you whether you built it right.