Demo Fallback Pivot Notes¶

Quick reference for switching from live demo to fallback in ≤ 15 seconds. Keep this open on a second screen or second browser tab during investor meetings.

The pivot (≤ 15 seconds)¶

When the live demo fails:

Say this immediately — do not pause, do not explain the error:

“Let me stop there — something is wrong with the environment. Let me switch approaches.”

Then move directly to a fallback. Do not attempt to fix the failure live. Do not spend more than 15 seconds on the failure itself.

Fallback sequence — apply in order¶

Fallback 1 — Recorded demo (preferred)¶

When: You have a screen recording of autonomy demo openclaw on your machine.

How to present: Open the recording immediately. Before pressing play, say:

“Let me show you a recording of the demo — our live environment has an issue I’m still diagnosing. The recording shows the exact same output you would have seen live.”

Do not imply the recording is live. Label it explicitly.

After the recording:

“What you just saw is the actual output of the command on my machine. The enforcement, the audit trail, the WAL events — that is real.”

Fallback 2 — Annotated terminal output¶

When: No recording is available. Use docs/demo/fallback/annotated-output.md.

How to present: Open annotated-output.md and share your screen. Say:

“This is the actual output from the command — I want to walk you through what it shows.”

Walk through each annotated section in order:

Header block — runtime started in-process, no Docker required
[1/3] tool.echo → ALLOW — agent submitted the call; policy permitted it; WAL entry written before response
[2/3] tool.http_get → SKIP — honest representation of standalone demo scope; domain enforcement exists in production
[3/3] tool.shell → DENY — shell command blocked before execution; agent cannot bypass it; decision in WAL
Summary block — ALLOW/DENY counts, WAL event count, rollback marker, PASS verdict

Total walk-through time: approximately 3 minutes.

Fallback 3 — Behavioral description (last resort)¶

When: Neither recording nor annotated output is accessible.

How to present:

“I can’t run the demo right now, but let me show you exactly what it does at the code level.”

Walk through these points verbally, referencing source files if you have them open:

The agent sends every tool call to POST /v1/tool before executing it
The runtime evaluates the embedded Rego policy against the call
The runtime returns allow or deny before the agent proceeds
A deny means the tool is never executed — not deferred, not logged-and-run, not retried
Every decision is written to a write-ahead log before the response is returned
The agent cannot read the policy, cannot detect the runtime, and cannot bypass it

After the fallback¶

Once the conversation has continued past the demo section, address it once — briefly:

“The live demo had an issue I’ll debug after this call. The recording [or: the output I walked you through] showed you the same behavior, but I want to make sure you know I’m aware of it.”

Then move on. Do not re-raise it.

Before the next meeting¶

Do not show the live demo again until it is fixed and re-tested
Run autonomy demo validate and confirm exit 0
Run on the presentation hardware specifically — not just the dev machine
Document the fix and re-run the reliability checklist
Re-capture the recorded output if the demo output format changed: bash scripts/capture-demo-output.sh --dev --normalize

What not to do¶

Action	Why not
Narrate past the error and continue	The error is more memorable than the successful parts
Apologize repeatedly	It amplifies the incident; one acknowledgment is enough
Attempt to fix it live	Takes longer than 15 seconds; signals operational unpreparedness
Imply the recording is live	Violates the anti-fake-demo rule; damages trust permanently if discovered
Skip the fallback entirely	Leaves the prospect with the error as their last impression of the product