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

Dan Eble released Keel, an open-source harness for coding agents that provides auditable stopping conditions and durable memory, installable via `cargo install keel-harness`. Keel introduces falsifiable oracles for acceptance criteria, a persistent knowledge store, and gate checks that block on high/critical security defects, with support for tree-sitter across 8 languages. The tool aims to prevent agents from over-rewriting code, weakening tests, and forgetting past lessons, positioning itself as a conductor rather than an agent loop.

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