Done should come from evidence the agent can't edit.
An agent can report that it finished. That tells you it stopped; the tests and the review tell you whether the work meets the requirement. Decide done from acceptance criteria written before the work started, tests that prove them and that you have seen fail, CI on the merged change, and a review by someone other than the author.
Your agent says it's done and CI is green. What would actually convince you the requested behaviour works? If one agent writes the code, the tests and the definition of done, it can pass its own exam without doing what you meant. The criteria have to come from outside the task. Green tells you nothing failed. It doesn't tell you the right things ran.
A merge request might say "verified locally", "a known flaky test" or "only two files changed". On DynoInvoice, each of those was found untrue in review at least once and corrected.
A definition of done you can use today
Write acceptance criteria before the agent starts, as outcomes someone can check on the running program.
Map each criterion to a test that proves it. A criterion with no test is the first place to look.
See each negative test fail before you trust it: break the thing it guards and watch it go red.
Count what ran. Compare the test cases in the report with the test methods in the source, so skipped tests can't hide behind a green build. A log line saying the test task ran isn't evidence; the class's JUnit XML (tests, skipped, failures) is.
Have someone other than the author review the change, including any change to the tests.
Close the task from CI on the merged change, not from the agent's summary.
How Keel decides done
Tests must prove acceptance criteria held in Keel; the coding agent can't change those criteria.
Before a coding agent starts, the server checks the task's readiness and lists what's missing.
A coding task is marked done by the server from the merged change and its CI verdict, not by an agent. The done check passes only when every criterion of the requirement is covered, each criterion key is traced to named tests, and the change stays inside the task's declared scope. Keel has refused manual completions that lacked the required evidence.
How a team reviews is its own choice, not part of Keel. On DynoInvoice, a different agent in a separate session reviews every merge request.
Of 687 merge requests merged across DynoInvoice's 24 repositories as of 26 October 2026, 259 (38%) were sent back by an independent reviewer at least once before merging.
In one merge request in October 2026, 16 of 17 negative tests had never run through one review round and two green pipelines. An independent agent spotted it from the test report before merge, and a gate now requires each class's reported case count to match its test methods. The story and the gate.
Questions
Isn't green CI enough?
Green CI tells you the checks that ran passed. It doesn't tell you that the right tests exist, that they ran, or that they can fail. Pair CI with criteria written beforehand, tests you've seen go red, a check on how many cases ran, and an independent review.
Should the same agent write the code and the tests?
It can write both, but the acceptance criteria the tests must prove should come from outside the task, and someone else should review the change, including the tests. In Keel the coding agent can't change the criteria; on DynoInvoice, a different agent reviews every merge request.
Can I use Keel today?
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.
Want done to mean done?
If that sounds like your team, apply to try Keel as a design partner. Beta access is free; we set up each team by hand and ask for one real project and candid feedback.