Free kit
The AI Agent Stop Line
Four lines you paste into any agent spec, so it stops for a reason you can act on. Not when the money runs out. Twenty minutes. Any tool.
Want the kit?
Set up & use
Four lines you add to any agent spec. Two of them you already write: the acceptance bar, and the context that makes hitting it worth anything. Two of them are usually missing: what the agent may call, retry and spend without asking, and when it stops and hands back. Underneath sits one rule that makes the rest work, which is that every stop has to name a reason, and the reason is either a limit it hit or a decision it made.
- 1
Download the ZIP and unzip it. You get the guide, a blank block, a filled example, and the ten rewrites.
- 2
Open stop-line-block.md and paste it at the bottom of an agent spec you already have.
- 3
Fill the four lines. Twenty minutes, and it is meant to be rough the first time.
How it works
Your spec is now a cost control
A vague brief used to cost you a rework cycle. Somebody read it, guessed wrong, and you lost a week.
Now the same brief goes to an agent. The handover feels human. The execution is software. You write one instruction and it turns into many paid steps, and it will keep taking them.
A person asks whether another run is still worth the cost. An agent does not. Not unless you wrote it in.
Agents do not take product judgement away. They move it earlier. The call about when enough is enough used to happen at review. It now happens before the run, in the spec, in writing.
Most specs set one finish line. Agents need two
Finish line one is the one you already write: the result is good enough.
Finish line two is the one that is missing: more work is no longer worth the cost.
They answer different questions. The first is about the work. The second is about whether to keep paying for it. A run can fail the first and still have to stop on the second, and if your spec has no way of saying that, the agent will keep going.
Finance sets the budget. Platform enforces the limits. Neither of them can say what good enough means on your product. That has always been your call.
| Step | Use | Why |
|---|---|---|
| 1 · Outcome | Finish line one | The acceptance bar, written before the run. Something you could hold the output against without arguing about it. |
| 2 · Context | Finish line one | What makes hitting that bar worth anything. The thing that would make a technically correct answer useless. |
| 3 · Decision rights | Finish line two | What it may call, retry or spend without asking you. Name the tools, the retries, the ceiling. |
| 4 · Review | Finish line two | When it stops, escalates or hands back, and what it has to tell you when it does. |
The rule that makes the other four work
Every stop names a reason, and the reason is one of two things. Either it hit a limit, or it made a decision.
"Hit the retry ceiling" is a limit. "Met the bar on run two" is a decision. "Confidence was low on the pricing field, handing back" is a decision.
If your agent stops and you cannot tell which one it was, you do not have a stop line. You have a timeout.
I got my own stop rule wrong first
I run my own build system this way. A plan gets written, a second AI reviews it adversarially and returns findings, I fix them, it reviews again. Round after round until the reviewer says the design is sound.
My stop rule was a hard cap. Four rounds, then stop and re-authorise. It seemed responsible. It was the wrong instrument, and here is how I found out.
One build ran ten rounds. Roughly ten findings every round, and the count never came down. On round ten, six of its ten findings were bugs in round nine's own fixes. Nothing ever shipped from it. A second one ran seven rounds with the finding count going up, not down: one, then two, then four, and every finding in the last round was about the same part of the design.
The cap would have stopped both of those at four. It would not have told me anything. I would have re-authorised and carried on grinding, because the cap measures how tired I am, not whether the thing is working.
So I replaced it with a slope. If the finding count does not fall across rounds, the design is wrong, not the implementation. Stop fixing and go back to the drawing board.
Replacing the design on that second build took one round.
That is the difference between a limit and a decision, in my own work. The cap was a limit: a number I hit. The slope is a decision: a reading of whether more work is worth the cost. Both are legitimate stops. Only one of them tells you what to do next.
The thirty second test
Open the last agent spec your team wrote.
Count the lines about what to build. Then count the lines about when another run stops being worth it.
Most people find the gap uncomfortable before they finish counting. That gap is what this kit fills.
- 1.Paste the block at the bottom of one spec you already have.
- 2.Fill the two lines you are missing. Leave the two you already write.
- 3.Run it once, and read the stop reason it gives you back.
Questions people ask
- What is a stop line in an AI agent spec?
- A stop line is the part of an agent spec that says when more work is no longer worth the cost, as opposed to when the result is good enough. It names what the agent may call, retry and spend without asking, when it must stop and hand back, and what it has to report when it does. Most specs contain only the acceptance bar, so the agent has no written basis for stopping short of it.
- Why do AI agents need two finish lines?
- Because good enough and worth continuing are different questions. A human doing the work asks the second one on their own and stops when the answer is no. An agent will not, because nothing in the brief told it to. Writing both means a run can end for a reason you can act on, rather than ending when a budget somewhere else runs out.
- Isn't spending an engineering or finance problem?
- They own the budget and the limits, and neither of them can say what good enough means on your product. A platform cap stops the spend but tells you nothing about whether the work was nearly there or nowhere near. The judgement about when to stop is a product call, and the spec is where it now gets written down.
- Should I cap the number of retries or use something else?
- Use both, and know what each one is for. A cap is a limit: it stops a run, and it tells you nothing. A slope is a decision: if the number of problems is not falling run to run, the design is wrong rather than the implementation, and another run will not fix it. A cap alone lets you grind for ten rounds and re-authorise every four.
- What is in the kit?
- Four files. A guide explaining the two finish lines, a blank block you paste at the bottom of any spec, a worked example filled in on a real job, and ten vague spec lines with the rewrite next to each one.
- Do I need to be technical to use it?
- No. It is four lines of plain writing that go into a document you already own. There is nothing to install and no code. If you can write an acceptance criterion, you can write a stop line.
- Does this work with any AI agent framework?
- Yes. It is a writing pattern, not a tool. It goes into a Claude Code project file, a prompt, a ticket, a Cursor rules file, or the brief you hand a supplier. The agent has to be able to read your spec, and that is the only requirement.