The sprint contract template I require before any agent writes code.
One page, seven rows. The difference between an agent that ships and an agent that improvises the definition of done.
I learned this one the expensive way. Three months into the Electron build, I had twenty agents generating partially-correct code in twenty streams, and I had become the stitching bottleneck the agents were supposed to eliminate.
The agents weren't the problem. The missing piece was that nobody — not the agents, not me — had written down what "done" meant before the work started.
The contract is the done, written first
A sprint contract is one page with seven rows. Goal. Non-goals. Acceptance criteria that can be checked mechanically. Cost ceiling. What verification means for this specific task. It gets written before any agent writes code, and the agent's work gets judged against it — not against my mood when I review the diff.
The row that matters most is the acceptance criteria, because it has to be mechanical. "Works correctly" is not a criterion. "Passes these three checks" is. If a criterion can't be checked without my judgment, it gets rewritten until it can, or it gets cut.
Why agents need it more than people
A person will ask when the goal is fuzzy. An agent will fill the gap with its best guess and keep going at full speed. That is the entire failure mode: fast, confident work toward the wrong done. The contract doesn't make the agent smarter. It makes the target smaller and visible.
What this doesn't give you
The template doesn't write itself, and a bad contract is worse than none — it hands everyone false confidence. The discipline is in the writing, not the having. The full template, with worked examples across firmware, research, and web builds, lives in the lab's sprint contracts lesson and the Sprint Contract System playbook. This note is the why. Those are the how.