Skip to main content

Kiwi — coding agents that run in infrastructure you control

Kiwi turns a task into a real pull request, verified against your own test command.

You describe a task and point Kiwi at a repository. A Control Plane admits the task and hands it to a Data Plane daemon over a Postgres lease queue; the daemon runs the task in an isolated sandbox through an Architect/Implementer session — a persistent Architect plans and reviews, an agentic Implementer explores the repository and makes the change with real tools, and every round is re-verified against your test command — then opens a PR.

The task → PR flow, in one sentence: submit a task and a repo, a daemon leases it, the Architect and Implementer work it in rounds until the Architect approves, and you get a real pull request.

:::note Your description is the goal; your tests are the guard The task you write is what Kiwi is trying to achieve. The test command is a guard that proves the change did not break anything — not the definition of done. That distinction is what makes additive work possible: "add an example to examples/" does not make a healthy suite start failing, so a run that treated a green suite as "nothing to do" would report success without doing the work. See the Architect/Implementer session. :::

One execution loop​

Kiwi runs every task the same way: a persistent Architect plans the task and reviews each round's work, while an agentic Implementer does the editing with real tools — read, grep, write, run — starting fresh each round on a brief the Architect wrote. There is no separate "fast mode" that skips exploration: an Implementer that can read the repository does not need a planner to guess file names for it up front, so nothing decomposes a task before the Architect has seen it. See Agentic sessions.

Two planes​

Kiwi is split into two cooperating planes with a clean seam between them:

  • Control Plane (cmd/kiwid, pkg/orchestrator) — the API, authentication, admission (pkg/planner), a Postgres lease queue, and encrypted credential storage. It decides whether a task may run and hands it out; it never runs your code and never plans its contents.
  • Data Plane (cmd/kiwidaemon, pkg/daemon) — a pull-model daemon that polls the Control Plane over HTTPS, unseals its org's credentials in memory, provisions a workspace, runs the Architect/Implementer session, and opens the PR. It is the only component that touches your source, and the only one that plans it.

Managed or BYOC​

The same Data Plane daemon can run in two deployment models:

  • Managed — Kiwi operates the Data Plane for you. The fastest way to start; every signup begins here on the Free tier.
  • BYOC (Bring Your Own Cloud) — you run the Data Plane daemon inside your own cloud. Your code and credentials never leave your VPC, and the Control Plane never sees plaintext credentials.

:::note Zero-knowledge is a BYOC property In BYOC, the daemon runs in your cloud and the Control Plane never sees plaintext credentials. In managed mode, Kiwi operates the daemon and holds its private key, so it can decrypt — managed is not zero-knowledge. See Security & credentials. :::

What is live today​

A task flows end-to-end — submit one and get a real PR back. The self-serve Free tier is deployed to production: a signup runs tasks on a Kiwi-operated shared fleet (per-org daemon processes, gVisor sandbox, agent-minute metering). Every job also produces a verified execution record. Still in progress: the Pro upgrade (arranged by contacting the team — there is no self-serve checkout) and the Firecracker managed-dedicated path. See the status table in the repository for the authoritative list.

Where to go next​