When an AI agent should stop and ask

“Use your best judgement” is not a boundary

That instruction sounds empowering, but it gives the agent no way to distinguish a reversible code choice from a decision about billing, permissions, or user data.

The model may be capable of proposing an answer. That does not mean it has the authority or missing context to choose it.

Imagine a request to hide cancelled subscriptions from the dashboard. The interface change is easy. Whether those records should disappear from invoices, exports, support tools, and retention reports is a product and compliance decision. A confident implementation cannot replace that missing authority.

Confidence is not evidence that the decision belongs to the agent.

Divide the work into three zones

1. 01
   Continue. ▶️

   Local, reversible implementation choices that follow an existing pattern and contract.

2. 02
   Verify. 🔍

   Choices that can be resolved by checking the schema, tests, documentation, or current interface.

3. 03
   Ask. 🛑

   Choices that change product meaning, public behaviour, security, cost, or irreversible state.

This keeps the agent moving through ordinary work while protecting the moments where guessing is expensive.

The zones should be written in terms of consequences, not file types. Editing CSS may still require an answer if the change hides a legal disclosure. Updating a database can be safe when it is a reversible local fixture. Risk comes from what the action means, not where the code lives.

Five signals that should stop the build

• The public contract is unclear.The change affects an API, integration, URL, or behaviour other people may rely on.
• The action is hard to reverse.Data deletion, migrations, access changes, and external writes need explicit direction.
• Two sources disagree.Code, docs, tests, and product language do not describe the same behaviour.
• Security changes meaning.The task alters who can see, create, edit, or delete something.
• The user outcome is ambiguous.Several implementations are valid, but each creates a different product.

One signal is enough to pause the affected branch, not necessarily the whole task. The agent can still finish safe discovery, identify the exact contract, run read-only checks, and leave the repository in a clean state. A good stop preserves momentum without crossing the boundary.

A good escalation brings the decision closer

“What should I do?” gives the whole problem back to the human. A useful escalation explains the discovery, the options, and the consequence of each.

A concrete question is easier to answer: “The API stores `draft`, while the interface now says `exploring`. I can change only the label with no migration, or rename the stored value and update exports. The first option preserves every public contract. Should I keep the stored value?”

That question exposes the real choice, offers a recommendation, and gives the human enough information to answer without reopening the whole investigation.

Make the answer easy to resume from

After the human chooses, the decision should become durable context. Record it in the relevant document, test, contract, or build log before implementation continues.

Otherwise the next agent will reach the same fork with the same missing information.

A useful checkpoint records four things: the decision, the evidence behind it, the parts of the system it affects, and the next safe action. It should also name what was deliberately left unchanged. That prevents a narrow approval from being interpreted as permission to redesign the surrounding product.

When work resumes, the agent should restate the chosen boundary, recheck any state that may have changed, and continue from the saved checkpoint. The pause is complete only when the implementation and its acceptance evidence agree with the human decision.