> ## Documentation Index
> Fetch the complete documentation index at: https://docs.karta.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Production readiness

> A launch checklist for deploying Karta agents with the right access, spend, release, observability, webhook, and support controls.

Use this checklist before a Karta agent handles real users or production work.
It is intentionally practical: each item points to the page that configures or
explains the control.

## Launch checklist

| Area                | Confirm before launch                                                                                                                    | Read                                                                                                                                    |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| Agent release       | The active release is the version you intend to serve, and rollback has been tested.                                                     | [Releases & rollback](/deploy/releases-and-rollback)                                                                                    |
| Local parity        | `karta dev` can reproduce the session API locally for integration testing.                                                               | [CLI overview](/cli/overview)                                                                                                           |
| API keys            | CI, backend, and operator keys are separate, scoped, named, and revocable.                                                               | [API keys](/platform/api-keys), [Authentication](/api-reference/authentication)                                                         |
| Browser credentials | Browser clients use session tokens or publishable embed keys, never `kt_live_...` keys.                                                  | [Session tokens](/security/session-tokens), [Chat widget security](/security/chat-widget)                                               |
| Identity            | Signed-in users use verified identity when memory or per-user actions matter.                                                            | [Identity](/sdks/widget/identity), [Authenticated agent](/sdks/widget/authenticated-agent)                                              |
| Memory model        | You have chosen the stable karta id grain: user, virtual employee, backend task, or fleet member.                                        | [Kartas & memory](/concepts/instances-and-memory)                                                                                       |
| Spend controls      | Org budget, API-key sub-limits, user caps, karta caps, seat caps, and anonymous-widget ceilings are set where needed.                    | [Usage & budgets](/platform/usage-and-budgets)                                                                                          |
| Model credentials   | Managed model access or BYOK is selected, and provider-key rotation is understood.                                                       | [BYOK](/platform/byok)                                                                                                                  |
| Webhooks            | Account, billing, budget, session, and turn events that matter to your systems are subscribed and signature verification is implemented. | [Webhooks](/platform/webhooks)                                                                                                          |
| Audit               | Owners know where account-change audit events live and how long your team expects to keep them.                                          | [Audit log](/platform/audit-log)                                                                                                        |
| Errors and retries  | Clients handle `401`, `402`, `403`, `404`, `409`, `422`, `429`, stream errors, and `503` retry behavior.                                 | [Errors](/api-reference/errors), [Troubleshooting](/platform/troubleshooting)                                                           |
| Security review     | The architecture, security model, trust posture, and widget data path have been reviewed.                                                | [Architecture review](/security/architecture-review), [Security model](/security/security-model), [Trust & compliance](/security/trust) |

## Day-0 smoke test

Before inviting users, run the same narrow flow you expect them to use.

<Steps>
  <Step title="Deploy or confirm the release">
    Deploy the agent, or confirm the intended release is active in the dashboard
    or with `karta agent show`.
  </Step>

  <Step title="Send one production turn">
    Use `karta send "..." --json` or your backend integration to send a safe,
    representative turn. Confirm the response and `session_id`.
  </Step>

  <Step title="Exercise the browser path">
    Open the hosted widget, verified widget, custom UI, or adapter client you
    will actually ship. Confirm the browser never receives a `kt_live_...` key.
  </Step>

  <Step title="Check usage and limits">
    Confirm the turn appears in usage reporting, then verify the relevant hard
    caps and threshold webhooks are configured.
  </Step>

  <Step title="Test rollback">
    Know which previous release you would roll back to and who is allowed to do
    it. For launch-critical agents, perform a rollback rehearsal before go-live.
  </Step>
</Steps>

## Operational runbook

Write down the answers before launch:

* Who owns deploys, rollback, API keys, BYOK, budgets, webhook endpoints, and
  audit review?
* Where do operators check live platform status?
* Which customer-facing failures should show retry, limit-reached, or support
  messaging?
* Which logs or session transcripts can support access, and under what policy?
* Which webhook events wake your team or update your internal systems?
* What is the first action when a release fails, a model key is rejected, a
  budget is exhausted, or a webhook endpoint auto-disables?

## Status and support

* Live platform status: [status.karta.sh](https://status.karta.sh).
* Security and trust materials: [karta.sh/trust](https://karta.sh/trust).
* Product or account help: `support@karta.sh`.
* Vulnerability reports: follow the public security policy linked from the trust
  page.