Stop Condition
An agent run needs more than one way out. Finishing is only one of them.
A loop that is meant to end needs a stop condition. In code review it is one of the first things a careful reader checks, because a loop without one keeps running until something outside it breaks. An agent run is a loop too: observe, decide, act, repeat. Yet many agent instructions describe the work in detail and say almost nothing about when to stop, other than "when you're done."
Done is the stop condition that does the least to keep a run safe. It tells the agent when it has succeeded. It says nothing about when it should stop even though it hasn't.
A stop condition is any rule that ends a run. The ones this post is about halt an autonomous run before its next step and hand the choice to a person, even though the agent could keep going.
Three runs that should have stopped
The cases below are hypothetical, but the shapes are common. In each one the agent finished, and finishing was the failure.
The pricing page. An agent is asked to update pricing page copy to match new plan names. It notices the page advertises a 20 percent annual discount while a config file says 15, and corrects the page to 15. The 20 percent was a promise sales had made to a group of customers through the end of the quarter. The copy was in scope. The number was a decision someone else owned.
The cleanup migration. An agent is told to remove a deprecated field because nothing reads it anymore. While tracing references, it finds a nightly export job that still reads the field. The instruction says one thing and the code says another. The agent treats the instruction as the stronger signal, rewrites the export to skip the field, and finishes. The partner that consumes the export finds out a week later.
The retry. An agent sending onboarding emails hits a rate limit, waits, and retries the batch. The retry resends to everyone who had already received the email before the limit hit. Each step was reasonable on its own. The second send broke a commitment, one email per person, that the agent never knew existed.
| Case | What the agent ran into | The stop condition it lacked |
|---|---|---|
| The pricing page | A number another team owned | Stop when the next step changes a decision you don't own |
| The cleanup migration | Evidence that contradicted the instruction | Stop when what you find disagrees with what you were told |
| The retry | A promise invisible from inside the task | Stop when you can't name what the next step commits to |
Why done is the wrong default
The completion check is local. Whether the task is finished is a question the agent can test against the request it was given. Two of the three conditions in the table are not local, and the third can be detected locally but not resolved there. Each depends on a fact outside the task: who owns a decision, what the team believed when it wrote the instruction, which promises already exist. An agent can resolve one of these conditions only if that outside fact is somewhere it can read.
This is also why adding "ask if unsure" to a prompt changes so little. In two of the three cases the agent had no reason to feel unsure. In the third it saw the conflict and settled it alone. Uncertainty is a feeling, and an agent can talk itself past a feeling. A stop condition has to fire on facts about the world, because the agent's sense of its own certainty is exactly what failed.
How to write stop conditions that fire
A working stop condition has three parts: a trigger the agent can check, a halt that leaves things recoverable, and a handoff that names who decides next.
- Ownership. Before changing a value, a rule, or a promise, check whether a recorded decision covers it and who made it. If the call belongs to someone else, stop and propose instead of acting.
- Contradiction. When evidence disagrees with the instruction, the instruction loses its authority until a person reconciles the two. Stop and report both sides.
- Unknown commitments. If the next step reaches customers, partners, or shared records and the agent can't list what it touches, that is the blast radius problem. Stop and preview.
The halt deserves as much care as the trigger. A migration stopped halfway can be worse than one finished or never started. Check the triggers before each step that can't be taken back, which is the placement One-Way Doors argues for, not after it.
The handoff needs a name. "Escalate to a human" is a hope, because no specific person owns it. A real handoff goes to the person who owns the decision being crossed, along with the evidence that tripped the trigger.
Where this fits at Brief
Each trigger needs something the agent can't supply from inside its task, whether to detect it or to resolve it: a record of what has been decided and whether it still stands. Keeping that record is Brief's job, and it serves the two triggers that prompts handle worst.
Coverage becomes a question the agent can ask. A coding agent working with Brief can run brief ask --mode check "We plan to change the annual discount to 15 percent" before it acts. Check mode validates a proposed approach against the team's existing decisions, as the CLI guide describes. In the pricing case, if the discount promise is on record, the answer is where the agent learns a recorded decision already covers that number. From inside the task, "has someone already decided this?" is a question the agent can't answer. Against a decision record, it is one command, run before the edit instead of discovered in review.
Contradiction gets a third witness. The cleanup migration went wrong because the agent had two sources, an instruction and the code, and nothing to settle the tie. The same check can say whether any recorded decision backs the instruction. If one does, and it replaced an older decision about the export, the supersession record shows which one governs. That tells the person reconciling the two what the team intended, and the stop still fires. If none does, the instruction is the only thing saying the field is dead, the code says otherwise, and that is the moment to stop and report both.
The check belongs in the middle of the run, too. A check run once at planning time sees only the request, and none of the three requests mentioned the discount, the export job, or the already sent batch. The agent learned about each of them partway through. The habit that catches them is to ask again whenever the work reaches something the original request didn't mention: a value nobody asked to change, a consumer nobody listed, a side effect outside the task.
Brief holds its own agents to the same rule. The judgment agents among the sixteen stop at a proposal in the review queue, and a new agent's first run is a dry run that never delivers. Those apply the ownership and unknown-commitments rules as fixed product behavior instead of leaving them to a prompt.
The limits are worth stating plainly. Check mode is an answer, not a lock. The agent has to ask, and the answer is a judgment over what Brief has on record, which can be wrong in either direction. Brief can only check against what it has: the retry's one-email promise stops the agent only if someone wrote it down where Brief can read it. What Brief changes is that the facts a stop condition depends on have a place to live where an agent can read them.
Pick the agent your team trusts most. Could you name the conditions under which it would stop before finishing?
Frequently asked questions
What is a stop condition for an AI agent? A rule that ends an autonomous run. Finishing the task is the obvious one. The ones that keep a run safe halt it before its next step and hand the choice to a person, even though the agent could continue. They fire on ownership, contradiction, and unknown commitments.
Isn't telling the agent to ask when unsure enough? Not on its own. An agent that crosses a boundary may not feel unsure at all, or may settle the doubt itself. A useful stop condition fires on a checkable fact, such as a recorded decision that already covers the change, rather than on the agent's sense of its own certainty.
Does every stop need a formal approval? Not always. A stop can end in a proposal someone accepts later, a preview someone inspects, or a narrower action that stays inside the agent's own scope. What matters is that the run doesn't take the crossing step on its own and that the handoff names who decides.
How does Brief help an agent know when to stop? It keeps the record the triggers depend on. A coding agent can run brief ask --mode check to validate an approach against existing decisions, and Brief tracks which decisions replaced which. Brief's own judgment agents stop at a proposal in the review queue. Check mode doesn't enforce a stop in your coding agent; it makes the condition something the agent can check.