Production launch checklist

Use this checklist after the Quickstart works locally and before routing real users to your agent. The goal is not just a successful chat turn — it is a release you can identify, observe, improve, and roll back.

1. Separate preview from production

• Create a test key for local and preview deployments.
• Create a distinct live key for production.
• Store both in server-only environment variables; never expose either key to a Client Component or NEXT_PUBLIC_* variable.
• Confirm the dashboard's Preview usage reflects Playground testing and the Production view contains only end-user traffic.

2. Publish a known configuration

In the agent Playground:

1. Choose the production model.
2. Review the system prompt, greeting, output limit, appearance, and enabled features in the generated configuration view.
3. Test representative happy paths, refusals, ambiguous questions, and tool failures.
4. Save a version, then publish that exact version.
5. Keep the previous known-good version available for rollback.

Do not treat an unsaved browser draft as deployed configuration. Save creates an immutable version; publish deliberately promotes one version to production.

3. Verify persistence and ownership

Run these checks with two separate test accounts:

• A conversation survives refresh and can be resumed by its owner.
• A user cannot load a conversation id owned by the other account.
• Delete removes only the authenticated user's targeted conversation.
• Attachments use private storage and short-lived signed URLs.
• Revoking a key prevents new requests made with that key.

See Authentication, Persistence & history, and Attachments for the underlying contracts.

4. Wire the improvement signals

A production assistant needs both answer-quality and coverage signals:

• Enable feedback on <ChatWidget>.
• Wire onFeedback: createHostedFeedback({ apiKey }) in the server handler.
• If the agent should answer from your content, configure hosted retrieval and ingest the authoritative sources under Knowledge.
• Ask questions that should and should not be answerable. Confirm citations render for grounded answers and weak retrieval appears under Usage & cost → Unanswered questions.
• Review recurring misses before adding an answer. End-user questions are input, not trusted documentation.

See Feedback and Knowledge / RAG.

5. Exercise failure paths

Before launch, intentionally test:

• Invalid or revoked API key.
• Model or upstream provider failure.
• Knowledge service unavailable.
• File upload rejected by type or size.
• Network interruption during streaming.
• A tool request that fails or requires human approval.

The UI should explain the failure without losing the conversation, leaking a secret, or exposing another user's data. For streaming-specific checks, use Streaming reliability.

6. Confirm the operating loop

After a small internal release, verify the dashboard supports the full loop:

1. Observe message volume, spend, feedback, and unanswered questions.
2. Investigate the relevant conversation metadata without exposing message content in the control plane.
3. Improve the system prompt, model, tools, or knowledge.
4. Test the change in Preview.
5. Publish a new version deliberately.
6. Rollback if production signals regress.

Launch record

Record these values in the release or deployment note:

A launch is ready when identity isolation passes, a known version is published, feedback and usage arrive in the correct environment, and the team knows which version to restore if quality or reliability regresses.