Skip to main content
Karta runs your agent as durable kartas and exposes it through one uniform API. You push an agent project; Karta builds an immutable release, serves it, routes each turn into the right karta, runs that turn in a per-session isolated runtime environment, streams the result back as typed events, and meters what it costs. This page is the mental model for everything in between.

​
The request path

1

Authenticate

A client calls the API with an Authorization: Bearer credential - a kt_live_... API key from your backend, or a short-lived session token from an end user’s browser.
2

Check the budget

Karta validates the credential and checks your org’s budget. If a cap is already exhausted it returns 402 Payment Required before running anything - no surprise bills.
3

Resolve the session & release

Karta resolves the session (creating one if needed), resolves the durable karta it belongs to, confirms both are inside your organization boundary, and pins new sessions to the agent’s currently active release.
4

Run the harness in isolation

Karta hands the turn to the harness running in a per-session isolated runtime environment. The harness runs the agent loop - tools, MCP, memory - and emits typed events.
5

Stream back

Karta relays those events to the caller as they happen (SSE), pausing for approval prompts when the agent needs permission to act.
6

Meter

When the turn completes, Karta records token and cost usage against your budget.

​
Per-session isolation

Every session runs in a per-session isolated runtime environment. One karta cannot see another’s filesystem, processes, or memory, and a misbehaving or prompt-injected karta is confined to its own short-lived execution environment. That environment is created for the session and torn down after it, while durable workspace state is preserved only through the karta’s own storage boundary.
Embedding Karta in your own process instead? See the two isolation models in Multi-tenancy.

​
Running agents vs. managing them

Karta separates the agent runtime from account-management systems. Security and platform teams should look for this boundary in anything that runs agent code:

Agent runtime

The request path: sessions, harness execution in isolated runtime environments, release serving, streaming, and request-time budget enforcement. This is where agent code actually runs.

Management systems

The system of record: identity, team membership and roles, API keys, usage metering and budgets, billing, BYOK provider keys, outbound webhooks, and the audit log.
The two sides are separated by a trust boundary, so the runtime that runs agent code does not hold billing, identity, or account-management state. A compromise of a running agent - the highest-risk surface on any agent platform
  • cannot by itself reach your billing, your team’s credentials, or another tenant’s data.

​
The harness owns conversation state

The harness owns conversation history, persistence, resumption, and tool/MCP integration. Karta’s session is a lightweight handle over it - metadata, participants, the current sub-agent, and pending approvals. Karta can record transcripts for inspection and export, but the session record itself is not the transcript store. Because history lives in the harness, resuming a session continues where it left off. Karta keeps the harness’s own session model instead of converting history into Karta session records.

​
Streaming is the primitive

Every entry point is event-streamed. A non-streaming request accumulates the same typed events (text, tool use, reasoning, approvals, errors) into one response. Build real-time UIs directly, or collect the final result; it is the same underlying model.

Agents

What you actually ship, and how a harness is detected.

Releases

Immutable snapshots, atomic activation, and instant rollback.

Multi-tenancy

Isolation models for embedded and hosted deployments.

Streaming events

The typed event model every surface is built on.