From demo to production

Launch day. A builder posts her memoir-maker link on LinkedIn.

Within an hour: a user who speaks only in one-word answers. Another who tells the agent his entire divorce, unprompted, in the first two minutes. A third on a train with a screaming toddler in the background. A fourth who asks the memoir interviewer for stock tips.

None of these appeared in her twelve careful test sessions. Nothing about her agent changed at launch. Everything about its inputs did. That is the demo-to-production gap: it is operational, not technical, and it is crossed with operations, not cleverness. Four gates before launch, one discipline after.

The four readiness gates

Gate 1: access configuration. Every platform asks some version of these three questions; answer them deliberately rather than by default:

• Availability window. Public always, or scheduled? Interview and assessment scenarios often gate access to time windows via shareable or single-use links. An always-open assessment is an invitation to rehearse it.
• Auto-recording. For conducted interviews you likely want everything recorded. But platforms don’t switch recording on by default, for privacy reasons: the user should get the option. Decide per use case, and announce it either way; a recorded user who didn’t know is a trust incident regardless of the legal fine print.
• Result visibility. Do participants see their own analysis, or only you? Coaching says share, because the feedback is the product. Screening often says don’t, because the rubric is the test.

Gate 2: privacy posture. Four commitments, all cheap before launch and expensive after: recording consent surfaced in the opening turn; memory disclosure per Chapter 12 (“Last time we discussed X” is the disclosure); a reset and delete path users can find; and the Chapter 12 rule re-checked, meaning don’t record sensitive categories you don’t need.

Gate 3: an observation plan. Decide before launch what you will watch: session completion rate, early-exit points, tool-call frequency, guardrail triggers, and first-turn drop-off (users who say one thing and leave, which is almost always an opening problem, per Chapter 20). You cannot fix what you didn’t plan to see, and post-launch is too late to start instrumenting.

Gate 4: a rollback path. Your versioned prompt log from Chapter 21 is the mechanism: launch on a tagged version, give every post-launch edit its own tag, and a bad fix reverts in one paste. Boring is the point.

On Tough Tongue: the access surface is configuration, not code: public or private scenarios, passcodes, short-lived access tokens for private embeds, and single-use links; recording is per-scenario (is_recording), and analysis_access controls whether participants see results. Webhooks fire on session lifecycle events (session.started, session.completed, session.analyzed), which is how your observation plan runs without polling.

Launch week operations

Watch the first twenty sessions individually. Not dashboards. Transcripts, whole ones. Twenty real sessions surface 80% of the failure modes you will spend the next month fixing, and no aggregate metric shows you the moment things went sideways the way the transcript does.

Triage with the Chapter 21 table. Every observed failure maps to a layer: prompt, tools, knowledge, memory, guardrails, model. Batch by layer, fix the most frequent failure first, one change per day maximum. Attribution discipline survives launch or it never existed.

Know the variance categories the opening dramatized, because each has a standard response: one-word users want a re-prompting behavior in the prompt. Oversharing wants scope guardrails (Chapter 19). Hostile audio environments are a model-layer question (Chapter 2). Off-purpose use gets the redirect-then-exit treatment, Chapter 19’s three strikes.

Embed as productization. The pattern that turns a scenario into a product: wrap it in a simple app (a V0, Lovable, or Replit-class build is plenty) that owns onboarding, framing, and follow-up around the embedded conversation. The agent is the engine; the app is the car.

On Tough Tongue: embedding is an iframe (full, basic, or minimal styles) with the agent’s context personalized per user via t_ query parameters that fill the prompt’s {{ variables }}, and lifecycle events (onStart, onStop, onSubmit) posted to your page so the app can react when a session ends. The embedding guide covers it, the API best practices doc shows the end-to-end pattern, and the ttai-simple-course repo is a working example you can fork.

Tip: write your launch post before you launch. Not as marketing advice, as a forcing function. If you can’t write two sentences on what your agent does and who it’s for, Chapter 4’s scoping isn’t actually done, and production will prove it within a day.

Launch week ends. The transcripts keep coming, every session, forever. The last chapter is what to do with them.