Karta - Karta

Karta is a managed agent harness platform. You bring a harness application — a folder that configures an agent runtime (a .claude/ directory and CLAUDE.md, or a .opencode/ directory) — and Karta turns it into a multi-tenant, metered, billable service. You don’t reinvent the agent; you ship the one you already have.

Quickstart

First streamed response in under a minute, locally.

Core concepts

Harness applications, sessions, agents, streaming, releases.

Deploy

The ship → serve → consume loop, releases, and rollback.

API reference

/v1 sessions, streaming, and OpenAI- and Anthropic-shaped adapters.

The idea in one line

Heroku took your web app and gave you git push → a live URL on a dyno. Karta takes your harness application and gives you a publish → a live URL that speaks a uniform agent-session protocol on an isolated sandbox.

The analogy is close to one-to-one:

Heroku	Karta
Your repo (a Rails/Node app)	Your repo (a harness app: `.claude/` + `CLAUDE.md`, agents, skills, tools)
`git push` builds a slug	A publish builds a versioned release
Runs the slug on a dyno	Runs the harness in an isolated sandbox
Stable URL `myapp.herokuapp.com`	Stable URL `myproject.karta.app`
Consumer hits your custom routes	Consumer opens a session over one fixed protocol
Next push → new slug, same URL	Next publish → new release, same URL

The one row that isn’t a mirror is the consumer surface. A web app exposes whatever routes its author invents; every Karta project exposes the same session protocol — create a session, send a message, stream the response. A fixed API is what lets one chat widget talk to any Karta project. What a harness app ships is agent behavior, not custom endpoints.

Why build on a harness instead of a framework?

Agent frameworks — LangGraph, CrewAI, AutoGen, the OpenAI Agents SDK — build agents from scratch: their own tool systems, memory, context management, and execution loops. Karta takes the opposite bet.

Frameworks build the agent

You assemble tools, memory, context, and the agentic loop yourself — then maintain them.

Karta builds on the agent

Claude Code and OpenCode already solved tools, MCP, memory, context, and the loop. Karta adds the platform around them.

Agent harnesses already solved the hard problems and are battle-tested. Karta contributes the layer they lack — multi-user sessions, multi-tenancy, identity, billing, usage metering, budget enforcement, BYOK, webhooks, and a uniform HTTP/CLI/SDK surface. Because agents are defined in the harness’s native format (.claude/agents/*.md, CLAUDE.md), examples from the harness’s own docs work unchanged. There is no second copy of your agent to keep in sync.

What you get

Multi-user sessions

Route conversations by metadata; multiple humans and AIs in one session, each message attributed to its sender.

Streaming-first

Every surface — HTTP, CLI, SDK — streams typed events: text, tool use, reasoning, approval prompts, done.

Multi-tenancy

Isolated workspace per tenant/user, or a shared server with auth-enforced org scoping. Default-deny across orgs.

Metering & budgets

Per-org token and cost caps with exact-integer money. Hit a cap and the API returns 402 before running anything.

BYOK

Bring your own provider key (Anthropic, OpenAI, Bedrock, Vertex, OpenRouter), encrypted at rest.

Deploy & rollback

Immutable versioned releases; activation is an atomic pointer flip, so rollback is a flip back.

Two planes

Karta is two independently-deployed services that talk over HTTP and are versioned together:

Data plane — karta-python

Python · FastAPI · harness SDKs. The request path: sessions, harness execution, sandboxes, request-time budget enforcement, usage emission. Published to PyPI as karta-python.

Control plane — karta-web

Ruby · Rails 8. The system of record: identity, API keys, metering, budgets, Stripe billing, BYOK storage, outbound webhooks, audit log.

The split is the central design decision: the plane that runs customer agent code is kept separate from, and minimally trusted by, the plane that holds money-and-identity state. A leaked data-plane token does not by itself reach the control plane’s sensitive surface. See Architecture.

Who Karta is for

Harness-app builders

You author a harness app and ship it as a metered product. You live in the dashboard, the karta CLI, and your own backend.

Your end users

They chat with your deployed app through a widget on your site, with a short-lived session token. They never see Karta.

The platform operator

Karta itself — runs the substrate, rotates service tokens, monitors abuse. A separate, more-privileged admin plane.

See Personas & trust boundaries for the full actor map and the credential each one holds.

Where to go next

Build your first response

Install, point Karta at a folder, stream a reply.

Understand the model

The vocabulary the rest of the docs assume.

Author a harness app

Project layout, agents, skills, and karta.toml.

Build a support bot

A complete end-to-end walkthrough.

Documentation Index