Phase 1: Three-act demo runbook + 15-min vendor pitch script

[hanwencheng]

Context

A demo that only the original author can run is not a vendor sale. The M1 three-act IAM demo has to be reproducible by a new operator in ≤15 minutes, and legible to a non-technical vendor stakeholder in 5 minutes of pitch.

These two documents lock in:

• Operator runbook (docs/runbooks/demo-three-act-iam.md): the script a new operator follows to bring up the demo. End-to-end, copy-paste, idempotent.
• Vendor pitch script (docs/pitch/vendor-15min.md): the 15-minute outline used in pitch meetings. Maps the three-act demo onto the vendor's pain points + Agent IAM category + pricing.

Without this, the demo lives in someone's head and never scales beyond one operator.

Scope (M1)

docs/runbooks/demo-three-act-iam.md

• One-command setup: bash scripts/setup-demo-iam.sh provisions everything — demo MCP server (Phase 1: AgentKeys MCP server — 7 active tools + 3 schema-only #107), parent UI (Phase 1: Parent-control web UI (mobile-responsive) for v0 demo #110), memory mock data, xiaozhi-server mcp_server_settings.json config. Idempotent per CLAUDE.md.
• MagicLick 2.5 captive-portal steps: how to point the device at wss://demo.agentkeys.io/ws via the device's WiFi config flow.
• Three-act script:
  • Act 1 (permissioned memory): exact prompts to give the toy, expected responses, what to point at on the parent UI
  • Act 2 (deterministic denial): out-of-scope request, expected denial path, audit row to highlight
  • Act 3 (revocation): parent revokes via UI, next device attempt fails, what the parent + audience see
• Troubleshooting per act (top 5 failure modes with cause + fix)
• Reset between demos: one-command state clear + memory re-seed so vendor pitches don't bleed state

docs/pitch/vendor-15min.md

• 15-minute slide deck outline (Markdown, not slides — slides derived later)
• Opening (2 min): vendor's pain (stateless chatbots, no identity, no audit, no cross-vendor portability)
• Three-act live demo (5 min): the runbook above, run live
• Agent IAM positioning (3 min): cross-vendor moat, why AgentKeys can't be built natively by Anthropic/OpenAI/ByteDance (walled-garden problem per agent-iam-strategy.md §6 Risk 1)
• Pricing (2 min): $2-3/active-device/month base + 30% revshare on consumer Pro upgrades (from ai-hardware-companion-office-hours.md)
• Close (3 min): "what would block you from a pilot in the next 30 days?" — the YC office-hours forcing question

Acceptance criteria

• A reviewer who has never touched the codebase takes the runbook, runs bash scripts/setup-demo-iam.sh, flashes MagicLick captive-portal config, and within 15 minutes is doing all three acts live
• Demo can be re-run cleanly between back-to-back vendor pitches (state resets in ≤30 seconds)
• Pitch deck outline tested with one internal reviewer + one friendly external advisor before vendor outreach
• The three-act script lists, per act, the deterministic outcomes the audience should see — no LLM variance allowed in any of the verdicts the demo depends on
• Runbook documents the kill criterion from Phase 2: FoloToy outbound + first vendor pilot tracking #116 (FoloToy vendor outreach) — when do we stop trying to convert this vendor and pivot?

Out of scope (defer to M2)

• Per-vendor-customized pitch decks (M2 with vendor onboarding portal)
• Localized pitch versions (Mandarin + English for M2)
• Video recordings of the demo (nice-to-have; M2 marketing surface)
• A/B testing of pitch outline variants (M2 once we have multiple vendor conversations)

Risks

Risk	Mitigation
Setup script is non-idempotent on the demo host → state corruption	Apply CLAUDE.md "Idempotent remote-setup rule"; every step has a pre-check
WiFi captive-portal flow varies by MagicLick firmware version → demo fails on a vendor's loaner unit	Pin firmware version in runbook prerequisites; ship a portable backup AP config
Vendor asks a question the pitch doesn't anticipate ("what about orchestration?")	Pitch script includes the §2.4 hard-line answer up front; if vendor pushes harder, the answer is "AgentKeys IS NOT an agent runtime — they pick their runtime"

References

• docs/spec/plans/milestones-roadmap.md §2 (M1 scope) — operational anchor
• docs/research/agent-iam-strategy.md §4.3 (three-act demo storyboard), §6 (strategic risks for pitch hardening)
• docs/research/ai-hardware-companion-wedge.md — positioning + naming
• docs/research/ai-hardware-companion-office-hours.md — pricing + the YC office-hours forcing questions
• docs/research/xiaozhi-esp32-magiclink.md — MagicLick 2.5 hardware details
• Phase 1: AgentKeys MCP server — 7 active tools + 3 schema-only #107 (MCP server), Phase 1: Memory namespace model — wire to cap-token + worker filter #108 (namespaces), Phase 1: Two-tier audit wiring (real-time off-chain feed + 2-min on-chain anchor) #109 (audit), Phase 1: Parent-control web UI (mobile-responsive) for v0 demo #110 (parent UI) — all integration points the runbook exercises
• Phase 2: FoloToy outbound + first vendor pilot tracking #116 (FoloToy outreach) — the vendor this pitch is first aimed at

Effort

~half day. The hard part is not writing — it's coordinating with #107–#110 to know they're ready to demo. Plan to write the runbook AFTER those are passing acceptance, and the pitch deck in parallel with #116 outreach.

Pickup notes for the next agent / developer

• Wait until Phase 1: AgentKeys MCP server — 7 active tools + 3 schema-only #107, Phase 1: Memory namespace model — wire to cap-token + worker filter #108, Phase 1: Two-tier audit wiring (real-time off-chain feed + 2-min on-chain anchor) #109, Phase 1: Parent-control web UI (mobile-responsive) for v0 demo #110 all pass their acceptance gates before drafting the runbook. Otherwise the script will document phantom features.
• The runbook lives at docs/runbooks/demo-three-act-iam.md. Create the docs/runbooks/ directory if it doesn't exist (it's not in the current CLAUDE.md docs layout — add to the layout if you make it permanent).
• The pitch deck lives at docs/pitch/vendor-15min.md. Same — create docs/pitch/ if absent. After M2, the per-vendor variants land here too.
• Use the /agentkeys-issue-create skill for any follow-up issues you open during the writing pass
• Watch for: the runbook is operator-facing (write for someone new to the codebase); the pitch deck is vendor-facing (write for a non-technical PM at FoloToy / Ropet / BubblePal). Different voices. Don't blend them.
• Don't include AgentKeys jargon in the pitch deck. "Cap-token" → "permission slip"; "actor omni" → "device identity"; "deterministic denial" → "the toy refuses out-of-scope requests." Per agent-iam-strategy.md §3.4 dual narrative.