Your AI Agent Can Act. Should It?
An agent may be able to read, reason and call tools. That does not mean it should execute every step. Impact, reversibility, evidence and ownership determine where it must stop.
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 | Verify explicit authorization covers this action; ask only for a new decision |
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.
A standing authorization can cover a repeatable workflow when the target, permitted fields, limits and stop conditions are explicit. A new irreversible decision needs a concrete candidate for review. Approval of a vague plan cannot substitute for that decision, but valid authorization should not trigger the same question at every run.
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?
The owner should know what the authorization covers. They can approve a specific candidate or delegate bounded routine changes. The agent returns to them when a decision falls outside that agreement.
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, reversible work within an existing authorization can flow through all three stages automatically, including permitted updates to a shared system. 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 target, permitted action and limits are already authorized;
- 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 topics and checking links can often continue. So can a specifically authorized update to an agreed set of shared fields. Sending a new kind of message, changing the target audience or exceeding a budget is a new decision, even if the API call is familiar.
One delegated task, two different outcomes
Consider a hypothetical daily price check. The owner authorizes the system to collect from specified sources and update machine-owned observation fields. The agent can complete that routine update without asking again. Human decisions remain in separate fields.
A newly detected price change does not authorize the agent to change the accepted baseline or email customers. Those are separate actions. It should prepare the evidence and request the required decision. If a source cannot be read, the run records an incomplete result instead of quietly declaring no change.
A practical decision table
| Question | If yes |
|---|---|
| Is this shared or public change already within explicit authorization? | Execute within that scope, then verify |
| Would this exceed the agreed action, recipient, cost or reversibility limits? | Prepare the exact change and request a new decision |
| 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.