Production checklist

Before making the assistant available to your users, review its knowledge, permissions, frontend integration, and funding. Use this checklist to confirm not just that the settings are in place, but that the assistant behaves as intended in your app.

Some checks apply only if you use the corresponding feature, such as API actions, identified users, memory, or delegation. Follow those where relevant; you do not need to enable a feature just to complete the checklist.

Knowledge

If the agent uses your documentation:

• Enable the knowledge tools it needs: Search docs, Browse docs as files, or both.
• Release the docs it should use. Draft edits are not available to the agent until released.
• Review its knowledge scope and confirm that customer-facing agents cannot access internal docs. If you use both tag and folder filters, a doc must match both.
• For code-backed docs, review the latest verification results and pending update proposals. Resolve known inaccuracies before relying on the docs in production; an empty proposal queue alone does not establish that everything is current.

An agent can run without docs. In that case, make sure its prompt and available tools support the role you expect it to perform.

Agent

• Review the full compiled prompt, including the instructions around your own text, and confirm the agent's role, scope, and limits are clear.
• Check the model and context settings against the tasks and conversation lengths you expect. If you need resilience to provider failures, configure and test a fallback chain.
• If you use memory, confirm the single Remember signed-in users switch is on only for the agents that should remember. Also review the approval mode on the two memory rows: Read memory, which sets one shared mode for searching memory and opening notes, and Save memory.
• If you provide opening suggestions, confirm they describe tasks the agent can actually handle with its current knowledge and grants.
• Use the Playground to try representative questions and requests, including ones outside the agent's intended scope. Test browser-dependent actions and navigation in your app.
• Publish the reviewed configuration. Draft changes do not affect the embedded assistant until published.

Actions

If the agent performs API actions:

• Review each catalog entry's policy: Allow, Ask, or Deny. Pay particular attention to destructive actions and those without a consequence tier; an unclassified action should not be assumed safe.
• Approve or archive the relevant proposals from your latest scan so the catalog reflects the operations you intend to expose.
• Grant each agent only the actions it needs. Adding an action to the catalog does not grant it to any agent, and a grant does not override its policy.
• Test representative actions through the embedded assistant in a staging or controlled test environment. Check the actual API result, not just the agent's description of it.
• For an Ask action, confirm approval is required before the request executes, and that declining approval leaves the action unexecuted. Confirm denied and ungranted actions cannot run.
• Test API authorization failures and other non-success responses. The assistant should report the failure rather than claim the operation succeeded.

Installation

• Mount the assistant once in the shared layout that wraps your pages. Confirm it remains available as users navigate, rather than resetting on every route.
• If your app uses a Content Security Policy, allow the assistant loader's origin in script-src and confirm the widget loads under the deployed policy.
• If navigation is enabled in a single-page app, wire onNavigate. Review the approved sitemap and allowed path prefixes under App access, then confirm navigation works within those limits.
• If you enabled API actions, wire the actions adapter to the intended API using the current user's authentication. Without an adapter, the assistant cannot execute catalog actions.
• If you use a request adapter, make it throw on non-success HTTP responses, including responses such as 401, 403, and 500. A resolved value is treated as a successful action result.
• If you use custom tool views, confirm they display the action results correctly, including empty results and errors.
• Load the assistant on the actual production origin and start a conversation. Check the agent's Install section for a session seen with the intended key, and verify that a response arrives in the app. The session indicator confirms a connection; it does not identify the origin or prove actions are working.

Security

• Use a live-mode publishable key restricted to your production origins, with a separate test-mode key for staging and development. A key's mode cannot be changed after creation.
• Decide whether the agent allows anonymous visitors or requires sign-in. Verify the behavior for both signed-in and signed-out users.
• If you identify users, issue end-user tokens on your backend using the authenticated user's stable ID. Keep the signing secret server-side and use short-lived tokens, with expiry of an hour or less.
• If you identify users, wire both userId and getEndUserToken on every identified surface. The ID supplied to the assistant must match the token's user_id claim. If sign-in is required, every surface carrying the assistant needs this wiring.
• If your app has sign-in, test sign-out and account switching in the same browser. Confirm the previous user's conversation, history, and pending prompts are cleared from the assistant. For identified sessions, keep userId synchronized with your app's authentication state.
• If you use API actions, confirm your API enforces the current user's permissions. A Teaflask approval or identity token does not grant additional privileges in your app.
• If you rotate the identity signing secret, coordinate the dashboard and backend changes and verify new tokens are accepted. Old tokens become invalid immediately; there is no grace window. See Identity.
• If you enable Workspace or Delegation, review the access they add: shell and file access for the workspace, and permitted tools for background subagents. Grant only what the agent's role requires.

Billing

• Confirm the model usage you expect is funded through your organization's balance, your own model provider keys, or both. Account for any models or work your provider keys do not cover.
• If you use the prepaid balance, fund it for expected traffic rather than relying solely on a welcome credit. Set Low-balance warning under Settings → Billing high enough to leave time to act.
• For balance-funded usage, configure auto top-up where available, or assign responsibility for monitoring and replenishing the balance. Check for any dashboard notice that top-up is paused or a payment has failed.
• If you bring provider keys, confirm they are valid and that the provider account has the funding and limits needed for production traffic, including any fallback models.

Monitoring

• Assign someone to review real conversations during the initial rollout, including failed actions, unanswered questions, and approval flows.
• Review usage by agent and funding source to understand actual consumption and spot unexpected changes.
• Use feedback to turn recurring problems into doc, prompt, or configuration fixes. Release updated docs or publish agent changes when those fixes are ready.

More resources

• Getting started: the setup process this checklist builds on.
• Lifecycle: how a message becomes an agent response and action requests.
• Glossary: definitions of the terms used here.
• Support: getting help from the team.
• Troubleshooting: diagnosing setup and runtime problems.