Skip to main content

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.

A harness application is the deployable unit Karta runs and manages. It’s a folder that configures an agent harness — picture what you’d git push to Heroku, except the artifact is a folder a coding-agent harness already knows how to run.
In prose we say harness application. In code, the CLI, the HTTP API, and the database, the same thing is called a project (ProjectRegistry, project_name, karta project add, AgentProject). They’re the same unit.

​
Anatomy

The minimum is a single instructions file. Everything else is additive. 
my-app/
├── CLAUDE.md              # agent instructions (the one required file)
├── .claude/
│   ├── agents/            # specialist sub-agents, one .md each
│   │   ├── billing.md
│   │   └── shipping.md
│   ├── skills/            # skills the agent can invoke
│   └── settings.json      # harness settings (tools, permissions, MCP)
├── karta.toml            # optional: deploy/build hints
└── karta.jsonc           # optional: Karta CLI/runtime settings
The agent definitions are in the harness’s own native format. That’s the point: examples from Claude Code’s or OpenCode’s docs drop in unchanged, and Karta never maintains a second copy.

​
Harness detection

Karta auto-detects the harness from the folder layout, so you rarely specify it explicitly:
SignalHarnessAdapter
.claude/ directory or CLAUDE.mdClaude Code (via the Claude Agent SDK)ClaudeAdapter
.opencode/ directoryOpenCode (driven as a CLI subprocess)OpenCodeAdapter
neitherdefaults to OpenCodeOpenCodeAdapter
Adding a new harness means implementing one HarnessAdapter class — discover agents from its format, and stream a single turn mapped to Karta’s event model.

​
What the harness owns vs. what Karta owns

The harness owns

Conversation history, session persistence and resumption, tools, MCP servers, memory, context management, skills, and the agentic execution loop.

Karta owns

Session handles, participant attribution, agent routing, policies, lifecycle hooks — plus the platform: HTTP/CLI/SDK surface, multi-tenancy, metering, budgets, BYOK, webhooks, releases.
Because Karta delegates conversation state entirely, there’s no second store to keep consistent — no sync races, no divergent copies of history.

​
Configuration files

Two optional files tune behavior without touching your agent definitions:
  • karta.toml — deploy and build hints used when the app is published as a release: the entry point, buildpack, and so on. See the karta.toml reference.
  • karta.jsonc — Karta-specific CLI, harness, and runtime settings (hidden event types, approval policy, idle timeouts, thinking budget). See Configuration.
Neither is required to run locally.

​
Next

Project structure

Lay out a real harness app, file by file.

Defining agents

The .md frontmatter format for specialist agents.