# Show HN: Keel - A conductor, not an agent loop

> Source: <https://daneb.github.io/keel/>
> Published: 2026-08-31 20:22:28+00:00

A conductor, not an agent loop.

The keel is the one member every rib bolts to — the part that decides
whether a hull holds its shape under load. Coding agents are good at writing code
and bad at knowing when to stop. keel owns the two things they don't: **auditable
stopping conditions**, and **memory that outlives the session**.

`cargo install keel-harness`

Installs a binary called `keel`

. The `keel`

and `keel-cli`

names on crates.io belong to unrelated projects.

An agent will happily rewrite a module you never mentioned, declare victory on a test it weakened, and forget by Tuesday what it learned on Monday. None of that is a model failure — it's a missing harness. keel supplies the harness and stays out of the way of the model.

Every acceptance criterion carries a falsifiable oracle — a command, a test, a schema, a doctest, or a named human. A gate that cannot fail is not a gate, so keel reports which of its own checks have never fired.

Knowledge lives in a durable store and is projected into whatever file your
agent reads. Recurring mistakes are classified, and the ones that recur across
*distinct* runs become gate checks rather than more prose to ignore.

Each is useful alone. The wire schemas between them are frozen and additive-only, so a new agent or a new check plugs in without touching the spine.

One store per repository, projected into every agent's own file —
`CLAUDE.md`

, `AGENTS.md`

, `.kiro`

,
`copilot-instructions`

. Two hashes: one goes stale when the
source moves, one refuses to overwrite a human edit. House rules
travel between repos; the map and product notes stay local.

tree-sitter across 8 languages — Rust, Python, JS, TS/TSX, Go, Java, C#. Agents work from outlines and symbols, and pull a full body only when they need one.

Reviewable files, not chat scrollback. Requirements in EARS; every criterion carries an oracle that can say no.

Five checkpoints, three verdicts. Blast radius is computed from the import graph and rechecked, not taken on trust.

An event stream per run, exportable and re-verifiable against its manifest. Approvals bind to the artefact's hash.

Episodes are classified and promoted only on a second occurrence in a separate run, and only with a human decision.

Each gate answers one question and refuses to answer it vaguely.

Every requirement falsifiable, every criterion carrying an oracle. A spec that cannot fail cannot pass either.

Blast radius computed from the import graph and compared with what the plan declared — not with what it hoped.

Build, lint, tests, line budget, blast radius, store drift, baseline ratchet.
G2.5 adds test-invalidation review, and grades the diff for security defects —
a model, a scanner, or both — where `high`

/`critical`

block the gate.

Evidence complete, change reviewable in size, earlier gates green, a human verdict where one was required.

Episodes classified, promotions proposed, decay reviewed. G4 forces the decision; it does not make it for you.

The checks ran and held.

A check ran and said no.

A check could not run. It never silently passes, and it is never counted as an agentic failure.

All of these are measured by keel on real repositories. The provenance matters as much as the value.

`-D warnings`

.Point keel at a repository and take one small change all the way
through. The [getting-started
guide](https://github.com/daneb/keel/blob/master/GETTING-STARTED.md) walks the same path with commentary.

```
# install
cargo install keel-harness      # binary is called `keel`

# set up the store, index the repo, render projections
keel init
keel map

# describe one change, then let the gates argue with you
keel spec new short-invocation
keel gate g0 short-invocation

# plan it, run it, and export what happened
keel plan short-invocation
keel run  short-invocation
keel export --verify
```


