When Is a Memory Safe Enough to Act On? Action-Conditioned Verification for Long-Lived Agents: what it means for business leaders

Whether an agent should re-check a remembered fact depends on what it is about to do with it, and a gate built on that idea cuts verification cost by a third without letting harmful actions through.

1. What the method is

AMV-Guard is a verification gate that sits between an agent's planner and its executor. For each proposed action that changes state or has outside consequences, it picks which remembered facts the action depends on and should be re-checked, then decides whether to proceed, verify or decline. The advance is to treat the need for verification as a property of the action, not of the memory. The same stored shipping address can be used without checking for routine documents but must be re-confirmed before a high-value shipment. The authors frame this as a sequential stopping problem: a check is worth its cost only if its result could change what the agent does next. They prove that as the consequence of an action rises, one fixed memory can move from proceed, to verify, to declining without verifying. The gate combines premise extraction, calibrated error probabilities and value-of-information check selection with a two-step lookahead.

2. Why the method was developed

Agents that persist across sessions act on memory, and many of their actions, such as payments, messages and shipments, cannot be undone, so a stale fact turns straight into harm. Earlier work improves the memory itself: better retrieval, detection of stale entries, provenance tracking, resolution of conflicts. None of those signals depends on what the agent is about to do, so none can tell two shipments to the same address apart. The authors cite a benchmark where the best model reached only 55.2% accuracy on invalidated memories even with the updated fact retrieved, and they cite agents seen taking irreversible actions before realising they should have declined. Environment-probing and cost-aware query methods help, but they score checks without regard to the action or to how several premises support it together. The paper also exposes a quieter flaw: scoring a check by how much it lowers the expected loss of a fixed action is never positive under Bayesian updating, so a planner built that way never verifies.

3. Who should care

The direct audience is teams building agents that keep customer or account state across sessions and act on it, whether in support, commerce, fulfilment, scheduling or internal operations. Engineering leads get a concrete design for a pre-execution gate that works without retraining the agent model. Product and operations owners get a control they can set: the gate is driven by an explicit loss function, so someone must write down what a wrong recipient, a policy violation or a failed task costs us, and that document becomes something auditors can review. Risk and compliance should care because declining to act becomes a deliberate outcome with a measured cost in lost coverage, not an afterthought. Finance should note the trade: fewer verification calls mean lower tool and API spend and fewer confirmation prompts for users. When we buy agent platforms, we can ask vendors whether their agents scale checking to the consequence of each action.

4. How the method works

For each action, two components propose the premises it rests on: an LLM extractor and a rule layer derived from the tool's public contract. Each premise is tagged as direct, transitive or joint. An LLM proposal must point to a memory entry, a verifier or a public target, and a filter trained on counterfactual outcomes removes premises that keep proving irrelevant. A logistic model estimates how likely each remembered claim is to be wrong, using features such as the claim's age, source trust, how many entries support or contradict it, and its position in the memory graph; it is calibrated by Platt, beta or isotonic scaling, chosen on held-out task families. These estimates become probabilities that the action's preconditions are violated, weighted by losses for task failure, wrong recipient and policy violation. The gate proceeds only when expected loss and harm probability pass their thresholds and proceeding costs no more than declining. Otherwise it runs the most valuable check, falls back to two-step lookahead, updates by Bayes' rule and repeats, and asks for a new plan when a premise is refuted.

5. How it was evaluated

The main testbed is ToolSandbox, a stateful tool-use benchmark, rebuilt into 3,520 replayable instances split 2,240, 640 and 640 for training, development and test. Each instance records memory during a clean session, then applies a hidden change drawn from ten families. These include single and multiple critical changes, irrelevant changes, premises that cannot be verified, noisy, conflicting or cost-inverted verifiers, and misleading source trust. The agent's first action is frozen and passed through the gate. Harm is measured by the environment's own state checks rather than by a language-model judge, over three observation seeds. The baselines are always proceed, always verify, a static AMV policy given identical inputs, an environment-probing method and a cost-aware acquisition method. An exact dynamic-programming planner with the same information serves as the regret reference. Three open-weight model backbones were tested on ToolSandbox. Transfer was tested on AppWorld, 100 state-changing tasks under clean and stale memory, carrying over only the stopping and value-of-information core of the method.

6. How it performed

On ToolSandbox, AMV-Guard executed 100% of safe actions and let no harmful action past the gate. It cut mean verification cost by 33.9% against the static policy (1.219 against 1.843) and by 38.3% against verify-all, while raising the share of cases that ended in an approved action from 38.83% to 44.17%, and it matched the exact planner on every metric. The cost savings held on all three backbones (33.9%, 42.3% and 58.9%), though coverage fell 5.68 points on one of them. End-to-end harm was still 7.03%, coming from planning and intent errors that the gate does not catch, and 31.83% of cases ended without an approved action. On AppWorld, cost fell 21.3%, but task success dropped from 30.50% to 28.00% and 7.89% of actions that passed the gate were harmful. The authors flag losses that must be set by hand, approximate modelling of linked premises, and real-world harms that simulators cannot score. Our call: pilot the gate on one class of irreversible action where we can write down the loss. (Source: arXiv 2610.31446, 2026)