When Is Agent Memory Safe Enough to Act On? Scale Verification to the Action, Not the Memory

TL;DR

• A preprint posted to arXiv on October 22, 2026, "When Is a Memory Safe Enough to Act On? Action-Conditioned Verification for Long-Lived Agents" (Wang et al.), makes one claim worth stealing: how hard you re-check a remembered fact should depend on what the agent is about to do with it, not only on how trustworthy the memory looks.
• The authors frame it as a stopping problem with three outcomes: proceed, verify first, or abstain. Their system, AMV-Guard, cut mean verification cost by 33.9% against a static baseline on ToolSandbox while keeping a 0.00% gate-harmful rate and 100% safe-proceed recall.
• On the second benchmark (AppWorld) the picture is weaker: cost fell 21.3%, but task success and safe-proceed recall slipped. I cover that below, because the honest reading is "promising, simulated, not solved".
• I wrote a 12-line version of the three-regime decision in Python and ran it. In my toy setup (numbers are illustrative, not from the paper), the same stale-memory risk produces different decisions for different actions, and a weak verifier flips "verify" into "abstain".

What problem does action-conditioned memory verification solve?

Long-lived agents carry memory across sessions: a customer's address, a project's deploy branch. Memory goes stale, and the usual response is a better memory store: retrieval, timestamps, confidence scores.

The paper argues that this attacks the wrong variable. A memory entry has no fixed "safe to use" status. The same entry, "the contact's email is x@y", is harmless when the agent is drafting a note to itself and dangerous when the agent is about to send a contract. What matters is the action's premises (the facts the action silently depends on) and the cost of being wrong for that specific action.

The authors split memory into three nested classes:

• Relevant: semantically related to the task, which is what retrieval returns.
• Action-supporting: supports a premise in the action's preconditions.
• Critical: if wrong, it materially changes the loss for this particular action.

Critical is a subset of action-supporting, which is a subset of relevant. Most memory stores stop at the outer ring. The verification budget should be spent on the inner one.

Why not just verify everything?

Because it is expensive, and it does not even maximize safety per unit cost. In the paper's ToolSandbox runs (3 observation seeds over 640 test instances), the "always verify all" baseline carried a mean verification cost of 1.976 and still let harmful actions through 23.67% of the time. "Always proceed" let 66.67% through. The gate-harmful rate is the share of gate-approved actions that turned out harmful under the benchmark's perturbations.

Policy	Gate harmful	Verify cost	Task success	Proceed coverage
Always proceed	66.67%	0.000	68.23%	100.00%
Always verify all	23.67%	1.976	74.58%	62.67%
EnvProbe-Simple	49.00%	2.018	74.48%	87.00%
CTA	63.61%	0.123	67.71%	96.89%
AMV-Static	0.00%	1.843	72.34%	38.83%
AMV-Guard	0.00%	1.219	73.91%	44.17%

Source: Table 1 of the paper, as reported by the authors. "Proceed coverage" is the share of cases where the gate allowed the action to run.

Two things stand out. First, the two policies that reason about the action and its premises (AMV-Static and AMV-Guard) are the only ones at 0.00% gate-harmful, while the cheap or crude baselines (CTA and EnvProbe-Simple) barely improve on doing nothing. Second, AMV-Guard gets there with 38.3% less verification cost than verify-all (1.219 against 1.976).

Note the distinction the authors draw themselves: the gate-harmful rate is 0.00%, but raw end-to-end harm is 7.03%. That residue comes from planning and intent errors upstream of the gate (6.25% of initial candidates were wrong before the gate ever saw them). A gate cannot fix a plan that was wrong from the start.

What are the three regimes, and why does consequence create them?

The core proposition: with a fixed memory, a prior probability p that a premise is false, an abstention cost kappa, and a verifier with cost c and reliability r above one half, the optimal first move changes with the size of the loss from acting on a false premise. Below a first threshold the best move is to proceed. Between two thresholds it is to verify. Above the second it is to abstain.

In plain terms:

• Low stakes: being wrong is cheap, so the check is not worth its cost. Proceed.
• Medium stakes: a reliable check pays for itself. Verify.
• High stakes: even after a check the residual risk stays too high, or the verifier is too weak to move the belief. Abstain, or replan.

The paper adds a subtle point (its Remark 1). For a fixed action, observing something never lowers the average loss of that action under Bayesian updating. Information only has value because it can change the decision. That is why "reduce uncertainty" is the wrong objective for a verification step, and "could this check flip proceed to abstain, or abstain to proceed?" is the right one. This is a value-of-information formulation, and AMV-Guard selects checks by bounded value of information.

Does verification effort really track consequence?

In the paper's controlled test, it does. AMV-Guard verified 0%, 15.8%, and 62.8% of low-, medium-, and high-loss cases. Its harmful-proceed rate in the high-loss tier was 0%, against 64.2% for a variant without loss conditioning, and baselines without loss conditioning verified at the same rate in every tier.

How does AMV-Guard pick which checks to run?

The pipeline has three stages, which are a reasonable template even if you never touch the authors' code.

1. Premise extraction. Pull candidate premises from the tool schema, the plan prefix, and retrieved memory. An LLM extractor and a rule layer propose independently, then a counterfactual filter drops premise-target pairs that are repeatedly irrelevant. Premises are tagged direct, transitive, or joint.
2. Calibrated risk. Estimate the probability that each claim is wrong from features such as recency, source, consistency, and graph position, using logistic calibration (Platt, beta, or bounded isotonic, chosen on held-out likelihood). On the paper's data, calibration moved expected calibration error from 0.319 to 0.082, Brier score from 0.319 to 0.209, and negative log-likelihood from 4.401 to 0.588. Raw model confidence was badly miscalibrated, which is the usual story.
3. Adaptive greedy verification. Compute the one-step value of information for each affordable verifier and run the best one. If no single check has positive value, look two steps ahead for complementary pairs. Return proceed, abstain, or "replan required" if the probability that a needed premise is violated crosses a threshold (0.95 in the development configuration).

"Adaptive" matters. Re-picking the next verifier after seeing each answer lowered mean cost on all three backbones the authors tried, with the gate-harmful rate staying at 0.00% each time:

The gains are uneven: 33.9% on Qwen3.5-35B-A3B, 42.3% on Qwen3.5-27B, and 58.9% on DeepSeek-V4.1-Flash. Proceed coverage moved +5.33 points, 0 points, and -5.68 points respectively, so on one backbone the cheaper gate also approved fewer actions.

Can I try the decision logic myself?

Yes. The following is my own toy implementation of the three-regime idea, not the paper's code. It assumes you can put numbers on four things: the prior chance the premise is false, the harm if you act on a false premise, what a check costs, and how reliable that check is.

def decide(p, loss, kappa=1.0, c=0.1, r=0.9):
    """p: prior P(premise false). loss: harm if we proceed and the premise is false.
    kappa: cost of abstaining. c: verifier cost. r: verifier reliability."""
    proceed = p * loss
    p_ok  = (1 - p) * r + p * (1 - r)          # P(verifier says "premise holds")
    p_bad = 1 - p_ok
    post_ok  = p * (1 - r) / p_ok               # P(false | says holds)
    post_bad = p * r / p_bad                    # P(false | says broken)
    verify = c + p_ok * min(post_ok * loss, kappa) + p_bad * min(post_bad * loss, kappa)
    costs = {"proceed": proceed, "verify": verify, "abstain": kappa}
    return min(costs, key=costs.get), costs

The verify branch is the whole idea: pay c, then take the better of "proceed" or "abstain" given what the check said, weighted by how likely each answer is. I ran it with a 20% chance that the premise is stale, abstention cost 1.0, check cost 0.1, and two verifiers.

Action (illustrative loss)	Verifier r = 0.9	Verifier r = 0.6
Read a calendar entry (0.5)	proceed	proceed
Draft an email (1.5)	proceed	proceed
Send an email to a client (6)	verify	abstain
Wire a payment (15)	verify	abstain
Delete a production table (60)	abstain	abstain

Illustrative numbers from my own script. The loss values are invented to show the shape of the decision, not measured.

Three observations from running it:

• Same memory risk, different decisions. The 20% staleness estimate is identical in every row. Only the action's consequence changes, and the decision moves from proceed to verify to abstain. A memory-only trust score cannot express this.
• The switch points move with verifier quality. With r = 0.9 the proceed-to-verify boundary sits at a loss of 2.0, and verify stays best until a loss of about 32. With r = 0.6 the boundaries are at 4.51 and 5.76, so a poor verifier leaves a very narrow band in which checking is worth it. A check you cannot trust is not a safety control, it is latency.
• A rare risk can still justify a check when the action is big. At a loss of 6, a 5% staleness prior already tips the choice from proceed to verify in this model (0.30 against 0.27), while at 1% it stays proceed.

What does the paper not show?

This is a preprint evaluated on simulated and replayed environments, and the authors list several limits that matter for anyone planning to adopt the idea.

• AppWorld transfer is mixed. Across 100 state-mutating tasks (200 episodes), AMV-Guard cut verification cost by 21.28% against its static variant (2.090 against 2.655), but task success was 28.00% against 30.50% and safe-proceed recall was 70.53% against 72.63%. The gate-harmful rate was 7.89%, not zero, and the bootstrap intervals are broad. "Always proceed" scored 35.50% task success there, so on this benchmark the guard trades completed tasks for lower harm.
• Extraction caps the guard. Premise extraction is partly model-driven, and the counterfactual filter cannot recover a premise that was never proposed. Critical recall on out-of-distribution slices was 95.91% for unseen tool families, 92.45% for unseen domain schemas, and 94.97% for unstructured language, with gate-harmful rates of 8.23%, 15.19%, and 10.13%. Dependency accuracy on unstructured language fell to 61.92%.
• The loss function is an input. It needs an executable consequence signal or an explicit policy. Where neither exists, someone has to supply the asymmetry by hand, and the authors say sensitivity analysis characterizes that dependence without removing it.
• Harm is only what the simulator models. Reputational damage, downstream human cost, and delayed effects are out of scope, so reported rates are harm on the modeled consequences.

None of this invalidates the idea. It does mean "0.00% gate-harmful" is a statement about one benchmark's perturbations, not a deployment guarantee.

What should I change in my own agent this week?

You do not need AMV-Guard to apply the principle.

1. Tag actions by consequence tier before anything else. Three tiers is enough: reversible, recoverable with effort, irreversible. Attach the tier to the tool definition, not to the prompt.
2. Extract premises per action. For each tool call, list the two or three facts it silently depends on (target ID, environment, recipient, version). If a fact came from memory rather than from this session, mark it.
3. Make the check depend on the tier. Reversible actions proceed. Recoverable ones verify the memory-sourced premises against a system of record. Irreversible ones verify and also require a verifier you trust (a database read, not another model's opinion), otherwise abstain and ask.
4. Measure your verifiers. The toy model shows that verifier reliability decides whether checking is worth doing at all. Log how often a check changes the decision. A check that never flips anything is dead weight, and one that always flips things is a sign your premises are mislabeled.
5. Track gate-local and end-to-end harm separately. The paper's own numbers (0.00% against 7.03% on ToolSandbox) show they move independently.

FAQ

What is action-conditioned memory verification?
It is the practice of deciding which remembered facts to re-check based on the specific action being considered, rather than on the memory's overall reliability. The check is chosen by its ability to change the decision to proceed, verify, or abstain.

Is AMV-Guard open source or production-ready?
I have not verified a public release, and the paper itself is a preprint evaluated on ToolSandbox and AppWorld, not on live deployments. Treat it as a design pattern and a set of baselines, not a drop-in library.

Does a 0.00% gate-harmful rate mean the agent is safe?
No. It means that on ToolSandbox's perturbation families, no action the gate approved was harmful. End-to-end harm was still 7.03% because of planning and intent errors upstream, and on AppWorld the gate-harmful rate was 7.89%.

How do I estimate the probability that a memory is stale?
Start with features you already log: age, source, whether it was written by the user or inferred by the model, and whether another source contradicts it. Fit a calibration model on labeled outcomes. The paper's calibration step cut expected calibration error from 0.319 to 0.082, which suggests raw confidence should not be used directly.

What if I cannot quantify the loss from a wrong action?
Use tiers instead of numbers, and be conservative: unknown consequence is treated as high. The paper notes that the loss asymmetry has to come from an executable signal or an explicit policy, and that it is the input most likely to be wrong.

Further reading

• Should Your AI Agent Act? An Engineer's Guide to Action Gates, Confidence, and the Latency Budget
• Your Agent's Gate Threshold Is a Winner's Curse: Tuning Per-Action Thresholds Without Fooling Yourself

Sources

• Wang, Wang, Zhang, Wu, Duan, Cai, Zheng, "When Is a Memory Safe Enough to Act On? Action-Conditioned Verification for Long-Lived Agents", arXiv:2610.31446, submitted October 22, 2026. All paper figures above (tables, percentages, calibration metrics, limitations) are the authors' reported numbers.
• Decision-logic table, thresholds, and chart 3: my own script, illustrative values, not from the paper.