Home / Karta · In internal evaluation — not released

An agent inside your limits.

Karta is the AI coding agent we are building for teams that need control: it works inside the permissions a task allows, on a cost-governed route, stops for a person where it should, and keeps a record of every step.

  1. A road leaving the city past three lit GPU nodes, three dim lanes with meters and breaker lights, and a shut gate marked frontier, $0 cap.

    01 / 08

    The route

    Before any work, a request takes a governed route: our own GPU mesh first, in an order people set and checked for health; vetted free hosted lanes only if the mesh is down, each checked for credentials, remaining daily budget and a tripped breaker; frontier models behind a gate whose spend cap is $0 by default. It is a governed order with live checks, not a live auction for the cheapest answer.

  2. The repository as a city of blocks, a lit outline drawn round src and tests, and a red translucent fence round the deploy blocks.

    02 / 08

    The grant

    Karta sees the repository as a city of files. A task comes with a grant — the parts it may change — and a fence round protected paths: deployment, its own safety tooling, the rules it works by.

  3. The agent over a block in src, a red slice lifting out and a green one settling in, and a card showing the proposed change.

    03 / 08

    The work

    It reads, plans and proposes a change as a diff — here, adding input validation to a form handler in a sample repository (a fictional task).

  4. The agent stopped at the fence while a person approves; test lamps round the changed block, one red, then all green.

    04 / 08

    Approval and tests

    Touching a protected path stops the work until a person approves; the approval fails closed and cannot be replayed. Then the project's own checks and tests decide whether it is done — a failing test sends it back to revise.

  5. A lit ribbon along the front of the city with tiles for each step, older ones shrunk to beads, one reopening, and a brass chain beside it.

    05 / 08

    The trace

    Every step is written to a record. Older steps are compacted, yet each can be expanded back into its detail when needed. Security-relevant events go to a separate, hash-linked chain that can be verified end to end.

  6. Panels of history folding into a stack with two red error lines still visible; a lesson card entering a glass vault.

    06 / 08

    Context and memory

    Long histories fold without losing their errors — failure lines are always kept. What Karta learns is stored as a lesson only after the task that produced it passes its gates.

  7. A glass workshop beside the city: a copy of a block, a test lamp turning from red to green, a brass key turning, a rollback lever.

    07 / 08

    Improving, behind a locked door

    Karta can propose improvements to itself, built apart from the running version: a test that fails before and passes after, a person's approval, a shadow run and a way back. Changes to its safety controls are never promoted on their own, and nothing here runs unattended In development

  8. The city from above behind a console showing health, budgets, approvals and the record.

    08 / 08

    The control room

    A console will show it all in one place — health, budgets, approvals waiting, the verified record. Today the only interface is a terminal; the web app is in development In development

Control, not autonomy.

The parts running in our internal testing today.

A governed route

Local models by default, free lanes within budgets and breakers, frontier spend capped at $0 unless raised.

Permissions and protected paths

A grant for each task; protected paths it cannot change without a person.

Approvals that fail closed

A pending approval is bound to what it approves and cannot be used twice.

Tests decide “done”

Linting, type checks, the project's tests and a safety suite it cannot edit.

A record you can verify

Every step recorded; security events in a hash-linked chain that detects tampering.

Sandboxed work

Commands run isolated, with the network off and credentials kept out, by default.

The route, stated plainly.

How Karta chooses where a request runs
StepHow it decides
Our GPU meshFirst, always: models in an order people set, each checked for health; the first healthy one runs
Free hosted lanesOnly when the mesh cannot serve: a vetted order, then live checks of credentials, remaining daily budget and circuit breaker
Frontier modelsBehind a gate with a monthly spend cap of $0 by default
Learning the best route from dataIn development
A running record of spendIn development

A task, its grant and its record.

Illustrative: the checks a Karta task passes through, composed from the controls running in our internal testing. The task is fictional.

Task
Add input validation to a form handler
Grant
The parts of the repository this task may change
Blocked
An edit to a protected path waits for a person's approvalThe approval is bound to that edit and cannot be used twice
Checks
Linting, type checks, the project's tests and a safety suite Karta cannot edit
Record
Every step written; the security chain verified end to endVerification reports whether, and where, the chain breaks

What you can engage us for today

  • Conversations about governed AI engineering, and walk-throughs of Karta's controls.

In development

  • The Karta web console: health, budgets, approvals and the record.
  • Routing learned from data rather than a set order.
  • A release: Karta is evaluated internally and there is nothing to install yet.

Talk to us about Karta.

Tell us what an AI agent would need to be allowed to touch in your repositories, and what it must never touch. We will show you how Karta keeps to that.