AI Tip

Before You Give an AI Agent Access, Write Its Stop Rules

An AI agent is easy to make more capable. Give it another tool, another data source, or permission to take the next step and it can do more.

The harder question is when it should stop.

That question matters because an agent does not understand consequences the way a person responsible for the outcome does. It can notice that a task is incomplete, but it cannot reliably decide whether an unusual customer request, a strange invoice, or a risky production change is merely inconvenient or genuinely dangerous.

Before an agent gets access to email, a payment system, a codebase, or a publishing workflow, write down its stop rules. These are not vague instructions such as “be careful.” They are conditions that force the workflow to pause and hand control back to a person.

Stop when the input is ambiguous

If two reasonable interpretations would produce different actions, the agent should not choose silently.

For example, “clean up the old subscribers” could mean remove bounced addresses, archive inactive contacts, or delete records. Those are different operations with different consequences. A stop rule might be:

Pause if the requested action could mean more than one thing and the difference changes what gets deleted, sent, published, or charged.

This is especially important when the request comes from a short message, a forwarded email, or a transcription with missing context.

Stop when the evidence is incomplete

An agent should not fill a missing fact with a plausible guess merely to keep moving.

Require it to pause when a source is unavailable, a number cannot be verified, a file is missing, or two sources disagree. The handoff should say exactly what is missing and what decision depends on it.

A useful output is not “I could not finish.” It is “I found two different delivery totals. I need the approved figure before updating the public page.” That makes the human reviewable instead of forcing them to reconstruct the problem.

Stop before an irreversible action

Some actions can be undone. Others only look reversible because a backup exists.

Sending a customer email, publishing a claim, deleting a record, merging code into production, changing a price, and placing an order should normally have an explicit approval boundary. The agent can prepare the action, show the exact payload, and validate the prerequisites. It should stop before execution unless the owner has deliberately approved that class of action.

Do not hide this boundary inside a general prompt. Put it in the workflow and test it.

Stop when the scope changes

A workflow designed to update a blog post should not quietly start changing navigation, analytics, or account settings because those changes seem useful.

Define the allowed surface. If the agent discovers a related problem outside that surface, it should report it separately rather than expanding its own assignment.

This is how you prevent a small automation from turning into an unreviewed system migration.

Stop when the result fails its check

Every action needs a success condition that can be checked without trusting the agent's description of what happened.

After a content update, read the public page back. After a data export, check the row count and a sample. After a deployment, verify the intended marker on the real domain. If the check fails, stop. Do not retry blindly or report success because a command returned zero.

The important distinction is between a completed command and a completed outcome.

Make the stop rules visible

Keep the rules short enough that the operator can scan them before granting access. A useful list often fits on one screen:

• pause on ambiguous intent;
• pause when evidence is missing or contradictory;
• pause before deletion, payment, publication, or external messages;
• pause when the request expands beyond the named files or systems;
• pause when the verification check fails;
• pause after a bounded number of retries.

Then define the handoff format: what the agent attempted, what it found, what it did not change, and the exact decision needed from a human.

This is not bureaucracy for its own sake. It is the difference between an agent that performs bounded work and one that keeps improvising until somebody notices.

The next time you give an AI workflow another permission, do not start with the prompt. Start with the stop rule. Capability tells you what the agent can do. Stop rules tell you whether you still control the result.