keel

keel is an open-source Rust CLI tool built by daneb that acts as a conductor above AI coding agents like Claude Code, Codex, Copilot, and Kiro. Rather than replacing agent loops, it supplies the two things those agents lack: auditable stopping conditions (gates) and memory that persists across sessions. The project is dual-licensed MIT or Apache-2.0 and is currently macOS-only at v0.4.10.

What It Is

keel is an agent harness, not an agent. It sits above existing AI coding tools and enforces a structured pipeline of gates (G0–G4) that must pass before work advances. Each gate answers one specific question — is the spec falsifiable? is the plan honest about its blast radius? did the work stay in scope? — and returns one of three verdicts: pass (exit 0), fail (exit 1), or blocked (exit 3, meaning the check could not run). A blocked verdict never silently passes and is never counted as an agent failure.

Six-Component Architecture

keel is organized into six components that each own a distinct concern:

• Knowledge — a single durable store per repository, projected into each agent's own instruction file (CLAUDE.md, AGENTS.md, .kiro, copilot-instructions). Two hashes separate stale projections from human-edited drift.
• Structure — a tree-sitter symbol index across Rust, Python, JS, TS/TSX, Go, Java, and C#, backed by SQLite. Agents work from outlines and pull full source only when needed. The index reports as ripgrep when stale rather than silently degrading.
• Artefacts — spec, plan, and tasks as reviewable files. Requirements are written in EARS format; every criterion must carry a runnable oracle (a command, test, schema, doctest, or named human).
• Gates — five checkpoints (G0–G4) with frozen, additive-only wire schemas. Gate checks are subprocesses speaking JSON, so new checks plug in without touching the spine.
• Evidence — an append-only trajectory.jsonl per run, exportable as a bundle.tar.gz with a manifest and hashes. Approvals bind to the artefact hash at sign-off time.
• Learning — failure episodes are classified and promoted to gate checks only on a second occurrence in a distinct run, and only with a human decision.

Gate Design

Each of the five gates enforces a single, non-vague question:

• G0 — Is every requirement falsifiable and every criterion carrying an oracle?
• G1 — Does the plan's declared blast radius match what the import graph actually shows?
• G2 — Did the work stay in scope, and does it build, lint, and pass tests? G2.5 adds test-invalidation review and security grading; high/critical findings block the gate.
• G3 — Is the evidence complete, the diff reviewable in size, and any required human verdict present?
• G4 — Were failures classified, and should any lesson be promoted to a rule?

A lesson with an oracle compiles into a G2 check (tagged from: L-nnnn) and is no longer injected as context — spending tokens restating a rule that cannot be violated is treated as waste.

Measured Performance

The project page publishes benchmark numbers from keel measuring itself on real repositories. The retrieval benchmark shows a 14.6× token reduction vs. reading whole files at 100% recall across five fixed questions. keel map indexes 5,705 files in 1.25 seconds cold. The test suite reports 359 tests with zero Clippy warnings at -D warnings. The project also self-reports a known weak spot: G2's green path had an 11% pass rate across 18 runs during development inside keel itself, and the evidence base covers two repositories and one operator.

Update: v0.4.10

The latest release is v0.4.10, published 2026-09-01, up from v0.4.0 shown on the project homepage. The GitHub repository was created in August 2026 and last pushed in September 2026. The project is early-stage: the homepage explicitly notes that Windows branches compile but are unexercised, G2.5 passes on heuristics unless an adversarial reviewer is configured, and only three lessons are in force against the five the design targets. The roadmap keeps a full accounting of what is deferred and why.