Reliable Agents Need Stop Conditions

Most agent failures are described as mistakes in the middle of the run.

The agent searched the wrong place. It trusted a stale assumption. It chose the wrong tool. It skipped a validation step. Those are real problems, but they often hide a deeper one: the system never clearly defined what would make the work complete.

A human can improvise that boundary. We notice when enough evidence has accumulated. We know when to stop digging, when to ask for approval, when to ship, and when to say the task is blocked.

An agent needs that boundary designed into the work.

If the stop condition is vague, the run has two bad options. It can stop too early with a confident summary, or it can keep working until time, budget, patience, or context runs out.

Reliable agents need stop conditions.

Completion Is Not the Same as Exhaustion

A lot of agent systems stop because something external forces them to stop.

The model reaches the end of a turn. The loop hits a max-iteration limit. A timeout fires. The user stops responding. A tool fails enough times. The context window fills up. The agent produces a final answer because the interface expects one.

Those are exhaustion conditions, not completion conditions.

Exhaustion says the run cannot or should not continue. Completion says the run has enough evidence to claim a specific state of the world.

That distinction matters. A task can be exhausted without being complete. It can also be complete long before the agent has used every available tool. Without a designed stop condition, the system has to infer the difference from vibes.

That is how background agents become hard to trust. They eventually say something, but the product cannot explain whether they stopped because the work was done, because the loop gave up, or because the agent found a persuasive way to summarize partial progress.

Define Done Before the Run Starts

For production work, “done” should be a contract the system can inspect.

That does not mean every task needs a rigid checklist. It means the agent should start with a clear answer to a practical question:

What evidence would justify stopping?

For a code-editing task, the answer might include changed files, a passing build, a relevant test, and a clean diff summary. For a research task, it might include searched sources, primary-source quotes, unresolved caveats, and a recommendation. For a publishing task, it might include a local draft, matching metadata, a hero asset, a build result, and an explicit publish gate.

The point is not bureaucracy. The point is to make the agent's completion claim falsifiable.

A good stop condition has three parts:

• The artifact that should exist.
• The evidence that proves it is usable.
• The boundary that says what remains outside the run's authority.

When those are defined up front, the agent can work toward a state instead of merely working until it has a plausible ending.

Stop Conditions Reduce Quiet Failure

Quiet failure happens when the final message sounds better than the actual result.

The agent says the issue was fixed, but no test ran. It says a post is ready, but the route was never generated. It says the customer has been handled, but the email is only a draft. It says the data was reviewed, but the source was stale. It says the deployment is live, but the public edge is still serving an old app shell.

Those failures are not always caused by bad reasoning. Often, the system did not require the right proof before allowing the agent to claim completion.

A stop condition turns the final answer into a checked state:

• If the route exists and contains the expected title, the draft is locally verified.
• If the build failed, the work is not complete even if the Markdown looks good.
• If publishing requires approval, local preparation is complete but publication is not.
• If a tool returned a fallback page, a 200 status alone is not enough evidence.
• If no primary source was found, the research should stop with a caveat instead of inventing certainty.

The agent may still fail. But the failure becomes visible at the boundary instead of being hidden inside the tone of the summary.

Some Stop Conditions Should Stop the Agent Cold

Not every boundary is a success boundary.

A reliable system also needs stop conditions for risk. The agent should know when to stop because continuing would exceed its authority or make the result less trustworthy.

Examples are common:

• The next step would publish externally.
• The run found unrelated dirty files it should not overwrite.
• A credential or secret is missing.
• A source contradicts the planned claim.
• A build or validation step fails for an unknown reason.
• A destructive operation would be required to proceed.
• The task depends on a human decision, legal approval, or customer-specific fact.

These are not annoyances to route around. They are part of the reliability model.

A good agent should be able to say: “I advanced the safe part, verified this much, and stopped here because the next step requires authority I do not have.”

That is a stronger completion state than pretending the whole job is done.

The Stop Condition Belongs in the Product, Not the Prompt

You can describe stop conditions in a prompt, and that is often a useful start. But production systems should not leave them only in prose.

The product should encode them in the surrounding machinery: task state, tool policies, validators, approvals, artifact checks, retry rules, and final reporting. The model can help interpret ambiguity, but the system should enforce the boundaries it already knows.

If a blog post must not be published without approval, that boundary should be part of the workflow. If a build is required before claiming readiness, the agent should run it and attach the output. If the final artifact must contain a generated route, the verification should check the file. If a customer-facing action requires review, the UI should represent that as a distinct waiting state.

This is another reason agent reliability is mostly plumbing. The model can decide the next step, but the system has to decide what counts as a complete, blocked, waiting, failed, or verified run.

Those states are product design.

Make the Final Message Evidence-Based

A stop condition changes the shape of the final message.

Instead of saying “I finished the task,” the agent can report:

• What artifact was produced.
• What verification passed.
• What verification failed or was not attempted.
• What authority boundary stopped further action.
• What approval is needed next.

That is less theatrical and more useful. It gives the user a review surface. It also gives the system a recovery surface if the next run needs to continue.

The final message should not be the place where the agent invents a sense of closure. It should be where the run exposes the closure it already earned.

Design the Ending First

Agent work is easier to trust when the ending is designed before the beginning.

Define the artifact. Define the proof. Define the authority boundary. Then let the agent work inside that frame.

The result is not a less capable agent. It is a more operational one. It can move quickly without treating every confident answer as completion. It can stop honestly when the evidence is missing. It can distinguish local preparation from publication, draft from send, attempted from verified, retry from recovery, and blocked from done.

That is the practical standard for production agents.

They should not just decide what to do next.

They should know what would let them stop.