DIRECT ANSWERAn agent must stop before changing real team, client or public state when the action is hard to reverse, the evidence is incomplete, or a named person must own the decision.
I first started thinking seriously about where an agent should stop not because it could not do the work, but because it moved through the work too smoothly.
It could read the source material, assemble a plan, complete a table and write the result into a shared system. The final step changed the nature of everything before it. Analysis was a candidate. Once written back, it became the current state that other people would trust and reuse.
If the source was stale or a field still required client confirmation, the error no longer stayed inside a chat. It entered documents, tables, live configurations and later automations.
Capability and authority are two different questions.
I now decide where to stop using four factors: the reach of the change, how easily it can be reversed, how certain the evidence is and who owns the outcome.
The dangerous part is not generation. It is changing state.
Drafting copy is usually low risk because I can reject it. The following actions may all look like simple tool calls, but their consequences are different:
- overwriting a field in a shared source of truth;
- changing a draft into something ready to send;
- creating or modifying a live ad configuration;
- writing a business conclusion from incomplete data;
- sending a message that represents current status.
These actions change the external world. Other people may continue from the result without seeing the evidence the agent used.
I used to treat correct formatting and permission to write as one gate. Complete fields, valid links and a successful API response felt like enough. Real use showed the gap. Format proves that the result resembles the expected object. It does not prove that the facts are current or that a disputed choice was authorized.
Four questions that determine the stop point
1. Who will this affect?
A local candidate affects the operator. Updating a team record, sending to a client or changing a live system expands the impact quickly.
| Level | Typical action | Default behavior |
|---|---|---|
| Personal candidate | Draft, summarize, prepare alternatives | Agent may complete automatically |
| Team state | Update a shared table, project status or knowledge base | Check the fields and responsible owner before writing |
| External outcome | Send to a client, launch an ad or change a public page | Require explicit confirmation |
The more people who will treat the result as true, the less reasonable it is to treat the agent’s judgment as authorization.
2. How cheaply can a mistake be reversed?
Reversibility is not whether recovery is technically possible. It is whether the recovery cost is low.
A local draft can be discarded. A client message cannot be unseen. A configuration can be edited back, but it may already have created data or cost.
The harder an action is to reverse, the closer confirmation should sit to the moment of execution.
This is why I avoid approving a long chain at the beginning. The person sees a plan, not the specific result that later steps will generate. A safer system prepares the change, stops before the irreversible action and shows exactly what will happen.
3. Is the decision based on evidence or inference?
Some conditions are deterministic: required fields, character limits, file formats and reachable links.
Other decisions depend on business truth and context. Is a claim supported? Does a blank mean zero or unavailable? Is this an internal draft or an approved deliverable?
If the agent has to infer through missing material, it should expose the gap and stop. The most dangerous signal is not an error message. It is a complete-sounding conclusion without evidence.
4. Who owns the final outcome?
If someone must answer to a client, team or business for the result, that person should see the final candidate, not approve only an abstract process.
Human review should not mean redoing the agent’s work. The agent should make the decision cheap: show the source, proposed change, completed checks and unresolved uncertainty.
The reviewer makes an ownership decision rather than searching the raw material again.
Three stages for tool-using agents
- Read and analyze. Gather evidence within the allowed scope and organize facts, conflicts and candidate options.
- Prepare the change. Produce the exact content to write, run deterministic checks and show the difference.
- Commit and read back. After approval, perform the external write and read the target again to verify the real result.
Low-risk, local and reversible work can still flow through all three stages automatically. The human gate appears only when the task crosses a boundary of impact or responsibility.
A good human gate does not put a person back into every step. It stops once, where a person must actually own the judgment.
Confirmation is also a design problem
A confirmation request that asks only “Continue?” is not enough. It should show:
- the active source and when it was verified;
- the exact content that will be added, replaced or sent;
- deterministic checks already completed;
- unverified assumptions or missing information;
- who will be affected and how the action can be reversed.
No response is not approval. A timeout should not silently trigger a high-risk write. If the action genuinely requires authority, stopping is the correct behavior.
When the agent can continue automatically
I usually allow full execution when all of these conditions hold:
- the action stays in a local or isolated environment;
- the result is easy to undo and does not pollute shared truth;
- sources are explicit and current enough;
- acceptance can be tested deterministically;
- failure is exposed rather than skipped quietly;
- the result is read back and verified automatically.
Drafting an unsent message, organizing candidate topics or checking links can often continue. External communication, real configuration, client status and public publishing should stop even when the technical action is simple.
A practical decision table
| Question | If yes |
|---|---|
| Will this change what a client, team or public system sees? | Confirm before execution |
| Could a mistake create cost, data or communication damage? | Confirm before execution |
| Does the decision rely on missing, conflicting or stale evidence? | Gather evidence or confirm |
| Must a named person own the final result? | Show that person the final candidate |
| Can the result not be verified through readback? | Do not write automatically |
I no longer judge an agent by how many steps it can complete without interruption. Maturity shows up in whether it knows which steps are preparation, which actions change reality and when the decision must return to a person.
Related Writing
- A Better Prompt Will Not Fix a Broken Workflow
- Why a Complete Media Plan Can’t Launch
- Automated Price Checks Still Need Me
PUBLIC NOTEThis article comes from real work. Client details, data and non-public implementation details have been removed.