Spec-driven tools get you to agree on what to build before an agent writes code. Keel starts there and keeps going: it holds the spec as linked, versioned records, gives each task a small context pack built from its links, has agents ask when the spec runs out, has a different agent review the work, and decides done from the merged change and CI.
Agents tend to fill the gaps in a vague request with guesses. Writing the requirements, acceptance criteria and plan down first, and keeping them in the repository where the agent reads them, removes a lot of those guesses. If that is all you need, a spec file is a fine place to start.
The trouble starts later. In a typical setup, the spec is still text the agent reads. When a decision changes, finding the places that depended on it is usually left to whoever edits it. When the spec doesn't cover something, the agent often picks a reading. And "done" is often whatever the agent reports.
| A typical spec file the agent reads | Keel | |
|---|---|---|
| Where the spec lives | A document or folder of documents in the repo, edited in place | Small versioned records (requirements, acceptance criteria, rules, decisions, tasks) with typed links |
| When a decision changes | Typically, someone edits the text and checks the dependent places by hand | Changes go through reviewed changesets; acceptance criteria and tests linked to a revised requirement are marked for review |
| What the agent reads | The spec, or as much of it as fits | A context pack built from the task's links; the decisions, rules, acceptance criteria and dependencies linked to it are always included |
| When the spec runs out | The agent often picks the reading that lets it finish | By rule, the agent stops and raises a design question with options; only that task waits, and the answer is recorded with who decided |
| Who checks the work | Often the same agent that wrote it | A different agent reviews every merge request; tests must prove acceptance criteria the coding agent can't change |
| When is it done | Usually when the agent reports it | The server marks the task done from the merged change and its CI verdict |
DynoInvoice, an e-invoicing system for Singapore, is built by agents under Keel, and its source is published on GitHub for study. From the record:
One task, start to finish: a coding agent that stopped three times and raised nine questions.
It starts from the same idea: agree what to build before the agent writes code. Keel keeps requirements, acceptance criteria, rules, architecture decisions and tasks as small versioned records with typed links, and then governs the work against them: each task gets a context pack from its links, a different agent reviews every merge request, and the server marks a task done from the merged change and its CI verdict.
No. Your agents keep running where they already run, with the model provider you already use. Keel works through a command-line tool, hooks and CI reporting in your own environment. Its service doesn't call an AI model, and its server never connects to your repository.
For one person and one agent session on a small codebase, a spec file the agent reads may be all you need. Keel is for teams running several agents on a system they'll maintain for years, where decisions change and someone has to answer for why the code is the way it is.
Keel is open to a small group of design partners: engineering teams already building with coding agents. During the beta it's free, and we set up each team by hand. We ask for one real project and candid feedback.
We're opening Keel to a small number of engineering teams already building with agents. It's free during the beta. We set up each team by hand, and ask for one real project and candid feedback.
Apply for early access