An automated system does not prove its usefulness by changing state every time it receives an instruction. Sometimes the correct operational result is that the state remains exactly as it was.
The reason matters. An operation may already be complete. A required condition may be missing. The evidence may be uncertain. A decision may belong to a human. Or policy may prohibit the requested action. These outcomes can all result in no immediate action, but they carry different meanings and different responsibilities.
The vocabulary of a safe pause
DO_NOTHING
Use DO_NOTHING when the system has evaluated the task and determined that no change to the governed state is required. The desired state may already hold; a repeated operation may be redundant.
This is a completed decision with no business-state transition. The system should make that outcome observable to the relevant workflow or operator. Silence alone does not show whether the system chose a no-op, failed, or never ran.
DO_NOTHING should not be a catch-all for missing evidence, unavailable services, or an action the system was not authorized to take. Those need their own dispositions.
DEFER
Use DEFER when an action may be valid later, but a specific prerequisite is not yet satisfied. The missing condition might be a required document, a future date, or a pending state change.
A deferral needs a way to resume: a time, an event, or an identified owner. Without that, a pending decision can remain unresolved indefinitely. Deferral also preserves the task as open; it does not mean that the system completed it.
UNCERTAINTY
Uncertainty describes the system’s evidence or interpretation. It is a condition to evaluate, rather than an operational outcome on its own.
The uncertainty may come from conflicting sources, stale context, an ambiguous request, or a task beyond the system’s validated capability. The next response could be to gather evidence, request clarification, defer, or escalate, depending on policy and the cost of error.
A model’s statement that it is “confident” cannot establish that its evidence is complete or that an action is permitted. Confidence signals need validation for the relevant task and context. Even a well-calibrated estimate of correctness cannot grant authority.
ESCALATE
Use ESCALATE when the next decision requires a person or role with authority the system does not have. The handoff should make the unresolved issue clear, identify the evidence already considered, and state what decision or information is needed.
Escalation transfers responsibility for the next decision. It should not imply approval, and the system should not execute the action while waiting.
REFUSE
Use REFUSE when the requested action is prohibited by policy or another governing constraint. This is different from uncertainty: more evidence may resolve uncertainty, but it does not make a prohibited action permissible.
A refusal should not be bypassed by changing the wording, choosing another model, or routing through a different tool. The governing restriction applies to the action, not merely to the path that proposed it.
ACT
Use ACT only when the action is within the system’s authority and its required preconditions have been validated. A model may propose an action. The operational system determines whether identity, permissions, policy, and state requirements allow execution.
The authorization boundary belongs at the point where the system can cause a side effect. A generated explanation or confidence score cannot substitute for that check.
An empty result is not an adequate record
A safe no-op leaves the business state unchanged. That does not require the system to be unobservable.
A reviewable outcome should let an operator understand what condition led to the no-op, what state was assessed, which rule or evidence supported it, and whether anything remains pending. The record can use references and concise reason codes; it does not need to retain sensitive prompts or duplicate source material.
The system should also distinguish a completed no-op from a pending task, a refusal, and a failure. Those statuses lead to different expectations:
- A completed no-op may need no further action.
- A deferred task needs a resumption condition.
- An escalated task needs an accountable recipient.
- A refusal needs to remain blocked under the relevant policy.
- A failure needs recovery or incident handling.
Combining these meanings into a blank response or generic “success” status makes it difficult to know whether the system behaved safely.
Abstention is a capability to evaluate
In June 2026, Han Luo, Bingbing Wen, and Lucy Lu Wang published an arXiv preprint studying “agentic abstention”: an agent’s decision to stop acting when a task cannot be solved reliably under the available conditions. Their benchmark covered more than 28,000 tasks and evaluated 13 agent systems. The authors report that most tested systems achieved less than 50% average abstention recall, while every tested model achieved less than 40% timely abstention recall. These are results from that benchmark, not universal estimates for deployed systems. [1]
Research on answer-level abstention offers a related, narrower finding. Zhang and colleagues’ NAACL 2024 paper on R-Tuning studies training models to answer questions they know and refrain from answering questions beyond their knowledge. That work concerns model responses; it does not establish whether an agent can safely govern tools, state changes, or operational authority. [2]
A system therefore needs to be assessed on both sides of the decision: whether it acts when action is justified, and whether it stops when the evidence, authority, or policy does not support action.
The cost of inaction belongs in the design
Doing nothing is not automatically safe. An unchanged state may be the correct outcome for a duplicate request, and a dangerous outcome when a time-critical condition requires intervention.
The system’s policy must define what “safe” means for the task and state being governed. It should also account for how long a decision remains valid. A no-op based on yesterday’s context may not remain appropriate after a new event. A deferral without an expiry or resumption condition can turn caution into neglect.
This is why a pause needs boundaries. The system should know whether it has completed a no-op, is waiting for a prerequisite, has handed off authority, or has stopped because policy forbids the action. Monitoring should make repeated deferrals and unresolved escalations visible rather than treating them as completed work.
CARM’INK’s architectural position
For CARM’INK, semantic structure and context help establish what information is relevant and what evidence supports a decision. Inference can help interpret ambiguity. Operational policy, identity, permissions, validation, and state controls determine whether a transition may occur.
This article’s decision vocabulary expresses that architectural position. It does not claim that CARM’INK already implements a DO_NOTHING feature or a specific disposition API. The implementation of these controls must be verified for each deployment.
NIST’s AI Risk Management Framework similarly treats governance as a continuing lifecycle responsibility. It calls for defined human roles and oversight, evaluation of system limits, and the ability to fail safely. It is risk-management guidance, not a prescribed implementation for these dispositions. [3]
A governed system can stop clearly
An AI system should do nothing when the authorized evaluation concludes that no state change is needed. It should defer when a defined prerequisite is pending, express uncertainty when evidence is insufficient, escalate when authority belongs elsewhere, and refuse when policy prohibits the action.
These outcomes should remain distinct, observable, and tied to the state and policy that produced them. Restraint is reliable when the system can explain why it stopped, preserve the right state, and make clear what happens next.
References
- Han Luo, Bingbing Wen, and Lucy Lu Wang, “Agentic Abstention: Do Agents Know When to Stop Instead of Act?”, arXiv preprint, 27 June 2026.
- Hanning Zhang et al., “R-Tuning: Instructing Large Language Models to Say ‘I Don’t Know’”, Proceedings of NAACL-HLT 2024, pages 7113–7139.
- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023.