Agents fail by acting too soon. New benchmarks and guardrails target that exact habit.

The dominant failure is over-action

HALO is a human-annotated benchmark and dataset designed to evaluate proactive agents, and its headline finding is uncomfortable for builders who prize initiative. Over-proactivity is the dominant observed failure mode for proactive agents, and premature timing or excessive intensity account for 61.20% of rejected responses in the HALO-8K dataset. The problem is not that agents do too little; it is that they intervene before they should, or more forcefully than the situation warrants. m:…4609

The benchmark is built to make that judgment granular rather than impressionistic. HALO-8K is a dataset of 8,000 responses from 10 models across 400 scenarios, annotated by 20 experts for action level, acceptability verdicts, and human diagnosis. HALO-Arena covers four proactive need types, Dependency, Blockage, Risk, and Opportunity, across 10 everyday domains and 50 personal environments, so a failure can be located in a specific kind of situation rather than blamed on agents in general. m:…4609

Current models are far from clean on this measure. The best proprietary models achieved 72.88% acceptability on HALO-Arena, and the best open-source models achieved 56.63%. That gap matters for anyone shipping a proactive feature: even the strongest models in the study are rejected more than a quarter of the time, and the dominant reason is doing too much, too soon, rather than missing the moment entirely. m:…4609

Acting on stale assumptions

A second preprint, BlindToChange, names a related failure: agents do not check whether the world has changed since they formed their plan. AI agents fail to account for recent world events because they do not proactively search to verify their own assumptions, and there is a 27.5-point performance gap in agentic systems when recent events are not explicitly mentioned compared to when they are. In other words, agents can find changes when asked, but they do not look when needed. m:…2253

The mechanism is specific. Over 50% of agent failures in the BlindToChange benchmark are attributed to the lack of direct search queries to verify fact changes. The agent is not necessarily reasoning badly about the facts it has; it is acting on facts it never rechecked. That connects directly to the HALO finding: an agent that acts early on an unchecked assumption combines the two failure modes at once, intervening forcefully on information that may already be out of date. m:…2253

For developers, the implication is that proactivity needs a verification habit, not just a better trigger. A system that waits for the user to mention a change will look capable in demos where changes are announced, and fail quietly in deployment where they are not. The benchmark makes that gap measurable instead of anecdotal, which is what makes it useful as a design target rather than a warning. m:…2253

Approval before execution

One answer is to put a consequence-aware approval step between the agent's plan and its execution, at least for coding agents that touch the file system. The paper titled Shall We Approve proposes a sandbox-based pre-execution layer that observes actual file-system effects rather than relying on static text analysis, and the reported results are large. The approach reduces harmful-outcome rates on the SABER benchmark to 6.7%, compared to at least 14.8% for existing systems, and on the YoloFS-Ext benchmark to 7.8%, compared to at least 35.3% for existing systems. m:…0374

Crucially, the layer does not buy safety by blocking everything. It maintains a low false-positive rate, blocking only 1.0% of safe tasks in the YoloFS-Ext benchmark. That balance is the whole design problem for approval systems: a gate that stops legitimate work will be disabled by its users, while a gate that waves everything through is decoration. The reported numbers suggest a pre-execution check can be strict about consequences without being indiscriminate about blocking. m:…0374

Approval and verification are different tools, and the distinction matters. Approval asks whether this particular action should happen at all, given its observable effects. Verification asks whether the agent is still on track toward its goal, and what to do when it is not. A careful agent needs both, because an action can be safe in isolation and still be a step in the wrong direction. m:…0374 m:…0288

Verify, then backtrack

The Verify-Backtrack Loop addresses the second half of that problem for long-horizon language agents. It is a training-free extension of ReAct that turns precondition discovery and failure diagnosis into structured planning-state updates, replacing ad-hoc reflection with explicit goal-stack operations. The loop performs dual-horizon verification, checking both terminal goal alignment and feasibility, to trigger precise recovery actions like backtracking or retrying. m:…0288

The reported improvement is substantial: task success improves by up to 22.07 percentage points over ReAct on the AppWorld benchmark. And the ablation result is the more instructive one. Removing either verification or diagnosis mechanisms degrades performance below ReAct, indicating the mechanisms are complementary. Neither checking nor diagnosing alone is enough; the agent needs to check, diagnose what went wrong, and then act on that diagnosis through a structured state update. m:…0288

Taken together, the four papers describe a maturing view of agent reliability. The benchmark work shows the failure is over-action on unchecked assumptions. The approval work shows how to stop a harmful action before it lands. The verification work shows how to recover when a plan goes wrong mid-task. None of these papers claims agents should be less capable; they argue that capability without timing, checking, and recovery is what users actually experience as failure. m:…4609 m:…2253 m:…0374 m:…0288