An agent that refuses to guess is often behaving more capably than one that confidently continues.
That can feel counterintuitive. We have trained ourselves to judge assistants by whether they produce a result, complete a workflow, or take the next step. But a tool-using agent operates in a setting where an action can be premature because the request is unclear, the evidence is incomplete, a prerequisite has changed, the tool outcome is ambiguous, or the agent lacks the authority to proceed.
In those cases, continuing is not initiative. It is unbounded inference.
The useful alternative is not a generic apology and not permanent paralysis. It is a disciplined decision to abstain: preserve the current state, explain why the next effect is not justified, identify the smallest missing condition, and make the route back to useful work explicit.
A reliable agent should know when it has reached the edge of what it can responsibly infer.
The recent AgentAbstain preprint calls attention to the distinction between should-act and should-abstain conditions. Production systems need a corresponding product behavior. A user should be able to tell whether the agent is done, blocked, awaiting input, awaiting verification, or deliberately holding a task at a safe boundary.
Abstention is not silence
Several behaviors can all look like an agent “not acting,” but they carry very different meanings:
- Behavior: Silent stop — What the user sees: No useful state or explanation — Reliability consequence: The user cannot distinguish completion, failure, or abandonment
- Behavior: Generic refusal — What the user sees: A broad statement that the agent cannot help — Reliability consequence: It may hide a narrow, solvable information or authority gap
- Behavior: Endless clarification — What the user sees: Repeated questions with no durable record of what is blocked — Reliability consequence: The task can loop without converging
- Behavior: Best-effort guess — What the user sees: A plausible action taken without sufficient basis — Reliability consequence: The agent may create an incorrect or irreversible outcome
- Behavior: Structured abstention — What the user sees: A clear hold state, rationale, owner, and re-entry condition — Reliability consequence: Work stays bounded and can resume from an honest state
The aim is not to make agents timid. It is to separate productive uncertainty management from unproductive avoidance.
A good abstention does three things at once:
- It prevents an unjustified action.
- It preserves what is already known and still valid.
- It gives a person or another system a specific way to unblock the work.
That makes abstention a positive capability: the agent can identify its decision boundary, not merely announce that something went wrong.
The Abstention Contract
The Abstention Contract is a proposed record for any moment when an agent decides not to continue an action. It does not require a particular database, model, or workflow engine. It is a compact policy for making a pause reviewable and resumable.
- Contract field: Trigger — Question it answers: What changed or was discovered that made the next action unjustified? — Why it matters: Prevents an opaque “I cannot continue” response
- Contract field: Known facts and evidence posture — Question it answers: What is verified, inferred, missing, stale, or contradictory? — Why it matters: Keeps a future continuation from treating uncertainty as fact
- Contract field: Held effect — Question it answers: Which proposed action is being withheld, at a high level? — Why it matters: Makes the safety boundary understandable without describing sensitive operational detail
- Contract field: Safe current state — Question it answers: What work is complete, what remains unchanged, and what has not been attempted? — Why it matters: Prevents a hold from being misreported as completion
- Contract field: Decision owner and required input — Question it answers: Who or what can resolve the block, and what minimal clarification, evidence, or approval is needed? — Why it matters: Turns a refusal into a finite handoff
- Contract field: Re-entry condition — Question it answers: What must be true before the agent may resume, and what must be rechecked then? — Why it matters: Stops an old abstention from turning into an automatic future permission
The fields deliberately separate evidence from authority. An agent can have enough information to understand what a user might want and still lack permission to create the resulting effect. It can also have permission to act but insufficient evidence to know what action is correct.
Both situations deserve a hold. Neither is solved by a more confident sentence.
When an agent should pause
The right threshold depends on the task, but the decision can be made legible through four questions:
- Is the intended outcome clear enough to state precisely? If multiple reasonable interpretations would produce materially different results, the agent should ask or hold rather than select one invisibly.
- Is the supporting information sufficient and current? If a consequential claim relies on an unverified, stale, or disputed premise, the next step should be verification, not continuation.
- Is the agent authorized for this effect? Scope, confirmation requirements, and delegated responsibility do not become optional because a plan sounds helpful.
- Can the outcome be safely corrected if the agent is wrong? Reversibility matters, but it is not a substitute for evidence or authority. A reversible action can still waste time, confuse collaborators, or contaminate a record.
These questions do not require the agent to expose internal reasoning. A useful explanation can stay at the level of observable state: “The requested outcome has two plausible interpretations,” “the source is no longer current enough to support this conclusion,” or “this step requires confirmation from the designated owner.”
Make the hold visible to people and systems
An abstention that exists only in a model response is fragile. The next turn may lose it during compaction, a handoff may reinterpret it, or a retry may run as though nothing was blocked. OpenAI's model guidance emphasizes preserving important task state and constraints across long-running work, while Anthropic's long-running-app harness account describes structured artifacts for carrying work across sessions. Neither source defines this contract; together they support making unresolved state durable rather than relying on a transient explanation.
Treat the hold as part of the task state instead. At minimum, the user-facing view should say:
- what the agent completed before it paused;
- what it deliberately did not do;
- why that boundary exists in plain language;
- what input, evidence, or approval would unblock it; and
- whether the task can expire, be reassigned, or be safely revisited later.
The system-facing record can carry the same categories more structurally. The important design choice is that a resumed agent reads the hold before choosing a new action. Otherwise a pause is only a momentary preference, not a durable constraint.
This also improves handoffs. Another agent does not need to reconstruct a vague feeling that “something was uncertain.” It can see the known facts, the unresolved condition, and the specific re-entry test.
Do not turn every uncertainty into a stop
Abstention can be overused. An agent that pauses whenever a small ambiguity appears may force people to do work the system could safely handle.
The distinction is between uncertainty that changes the legitimacy of the next action and uncertainty that the agent can resolve through ordinary, low-risk work. For example, a task may allow the agent to consult an already approved public source, compare alternatives, or prepare a clearly labeled draft. It should not invent a factual conclusion, claim an ambiguous tool result succeeded, or reinterpret an approval after the conditions changed.
Teams can make this boundary practical by defining task-specific categories:
- Condition: A routine fact can be verified from an approved, current source — Appropriate posture: Verify and continue
- Condition: A non-consequential formatting preference is unclear — Appropriate posture: Make a reversible default and disclose it, if the task rules permit
- Condition: A request has competing interpretations with different material outcomes — Appropriate posture: Ask for clarification or record a hold
- Condition: A source, prerequisite, or tool outcome is ambiguous — Appropriate posture: Preserve the uncertainty and seek verification
- Condition: The next step exceeds the agent's delegated scope — Appropriate posture: Escalate to the designated owner
The table is a policy pattern, not a universal rulebook. The user, organization, and task type should decide where confirmation is required.
Evaluate abstention as a product behavior
If teams only measure completion rate, an agent that guesses may look more successful than one that pauses appropriately. That rewards the wrong behavior.
Add measurements that expose the quality of holds:
- Justified-hold precision: Of the times the agent paused, how often did review confirm that more evidence, clarification, or authority was actually needed?
- Missed-hold rate: How often did the agent act where a later review found that it should have stopped?
- Resolution latency: How long does it take for a blocked task to receive the required clarification or verification?
- Re-entry accuracy: When a task resumes, how often does the agent correctly apply the recorded condition instead of treating the old hold as a blanket permission?
- User comprehension: Can a reviewer explain the block and the next step without reading the full conversation?
No metric can infer intent perfectly. The goal is to see whether the system creates understandable, narrow holds instead of hidden failures or false certainty.
A practical adoption path
- Find one workflow where an agent currently asks repetitive questions, makes unsupported assumptions, or silently stops.
- Define the kinds of uncertainty that require a pause in that workflow: unclear goal, missing evidence, missing authority, changed prerequisite, or ambiguous effect.
- Add the six contract fields to the task record or approval view.
- Test paired examples: one where the agent should continue after ordinary verification, and one where it should hold.
- Require the resume path to recheck the specific condition that caused the hold.
- Review holds as product feedback. If users repeatedly supply the same missing information, make that requirement visible earlier in the task.
The result is not an agent that says “no” more often. It is an agent that can say, “I know exactly why this should not proceed yet, what remains safe, and what would make it safe to continue.”
What we are learning building Virillio Code
Virillio Code is in development. High-level work around durable execution and task boundaries points to a general principle: a well-designed agent needs a first-class way to preserve uncertainty without either losing the task or converting that uncertainty into an action. The Abstention Contract is a proposed educational model, not a description of a released product behavior.
Sources and further reading
- AgentAbstain: Do LLM Agents Know When Not to Act? — Xun Liu et al. — A research preprint evaluates whether agents can identify paired should-act and should-abstain conditions, including ambiguity, conflicting constraints, and tool-failure contexts.
- OpenAI Model Guidance — Long-running agent work benefits from intentional handling of state, constraints, and unresolved conditions.
- Harness design for long-running application development — Anthropic — Structured task artifacts and explicit state help work continue across many model turns or sessions.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.