Production architecture review

Use this page as the architecture review index. It ties together the agent runtime, account-management systems, credential model, durable kartas, spend gates, releases, and audit surfaces that matter before a production launch.

First-pass model

Karta separates the code that runs agents from the systems that manage identity, money, keys, billing, webhooks, and audit.

Your app or SDK
  -> Karta session API
  -> isolated agent runtime for one session and karta
  -> typed event stream back to the caller

Karta management systems
  validates credentials, enforces budgets, stores account state, records audit,
  manages releases, keys, billing, BYOK, webhooks, and team access

The security property to review is the boundary: a running agent handles the current session, but it does not become the account administrator, billing system, or key manager.

Review checklist

Concern	What to confirm	Read
Agent execution boundary	Each session runs in an isolated runtime environment, and durable workspace state belongs to the selected karta.	How Karta works, Multi-tenancy
Memory and privacy grain	Your product chooses the stable karta id: per user, per virtual employee, per backend task, or per fleet member.	Kartas & memory
Prompt injection containment	Hostile instructions are assumed possible; review what the platform contains and what your agent tools still own.	Security model, Inputs
Browser credential safety	End-user browsers never receive a `kt_live_` API key. They use a short-lived session token or a publishable widget key fenced by allowed origins.	Session tokens, Chat widget security
Server credential authority	API keys are scoped and revocable. Use the narrowest scope for CLI, CI, backend, and management integrations.	API keys, API authentication
End-user identity	Anonymous, soft, and verified identity are distinct. Verified identity is the path for durable per-user memory and sensitive host-attested actions.	Widget identity, Authenticated agent
Spend control	Requests are gated before execution when credits or caps are exhausted. Caps can be set at org, key, user, karta, seat, and embed-key grains.	Usage & budgets, Errors
Model-provider keys	Managed model access and BYOK are separate choices. Provider keys are encrypted at rest and fetched only when needed for a request.	BYOK, Trust & compliance
Release control	Deploys create immutable releases; activation and rollback are pointer flips under the same stable agent URL.	Deploy loop, Releases & rollback
Auditability	Material account changes write immutable audit events. Use webhooks for events your own systems must receive.	Audit log, Webhooks
API confidence	The run surface is uniform: sessions, messages, approvals, streaming events, and adapter shapes.	API reference, Streaming events
Failure handling	Budget exhaustion, auth failures, rate limits, stream errors, and provider failures have documented behaviors.	Troubleshooting, Errors
Launch readiness	Access, spend, release, webhook, status, and support controls are assigned before real users arrive.	Production readiness

Integration patterns

Private backend integration

Your server holds a scoped API key, creates sessions, sends messages, and streams events to your own UI.

Public widget

Your page ships a publishable embed key, fenced by allowed origins, and Karta mints browser-safe session credentials.

Signed-in customer app

Your backend vouches for the end user so Karta can route durable memory to the right karta.

Existing AI client

Keep an OpenAI or Anthropic-shaped client and point it at a Karta agent adapter.

Questions to answer before launch

Which stable id creates the karta for each user, virtual employee, backend task, or fleet member?
Which client surfaces need API keys, session tokens, publishable embed keys, or adapter credentials?
Which spend caps should be hard stops, and who receives threshold webhooks?
Which people can deploy, roll back, mint keys, configure BYOK, and view audit?
Which events should your incident, billing, analytics, or CRM systems receive?
Which user identity level is required before the agent can read durable per-user context or request sensitive actions?
Which release rollback and troubleshooting steps should be in your runbook?

How Karta works

The request path, isolation model, and runtime/management separation.

Trust & compliance

Encryption, authentication hardening, secrets, webhooks, audit, and operator access.

Security model

Prompt injection assumptions, containment boundaries, credentials, and residual risks.

Production readiness

Launch checklist for releases, access, spend controls, webhooks, audit, and support.

API authentication

API keys, session tokens, route families, and auth failures.

Usage & budgets

Metering, caps, credits, threshold alerts, and 402 behavior.

Chat widget security

CSP, origin allowlists, graceful limits, privacy, and disclosure guidance.

Troubleshooting

Operational symptoms, likely causes, and the first fix to try.

Get started

Concepts

Agent project

The CLI

Deploy

Platform

Security

Enterprise

Tutorials

Production architecture review

First-pass model

Review checklist

Integration patterns

Private backend integration

Public widget

Signed-in customer app

Existing AI client

Questions to answer before launch

Read next

How Karta works

Trust & compliance

Security model

Production readiness

API authentication

Usage & budgets

Chat widget security

Troubleshooting

​First-pass model

​Review checklist

​Integration patterns

Private backend integration

Public widget

Signed-in customer app

Existing AI client

​Questions to answer before launch

​Read next

How Karta works

Trust & compliance

Security model

Production readiness

API authentication

Usage & budgets

Chat widget security

Troubleshooting

First-pass model

Review checklist

Integration patterns

Questions to answer before launch

Read next