Agent-Native Teams Need Memory That Speaks First

Ask a team building with agents what their agent memory system does, and you will get an archival answer. It stores what happened. It retrieves what is relevant. It answers questions when asked.

That answer describes a filing clerk. It misses half of what memory is for.

Cognitive psychologists have split human memory along this line for decades. Retrospective memory recalls the past: what was said, what was decided, where the file lives. Prospective memory executes the future: remember to send the contract when the deal closes, remember to renew the certificate before it expires, remember to tell the client the deploy slipped before they ask. In everyday life, "remembering to do X when Y happens" accounts for roughly half of all memory lapses. Nobody forgets where the document is. They forget to act at the moment that matters.

AI teams are about to learn this the hard way, because the same asymmetry governs agent work — and almost nothing in the current stack measures it.

Retrospective recall is a solved-feeling problem

The benchmarks that dominate product pages are retrospective tests. LoCoMo scores very long multi-session conversations. LongMemEval pushes harder — larger archives, explicit knowledge updates, temporal reasoning, false premises. BEAM and its siblings stress agentic retrieval. These are reasonable questions, and systems have gotten good at them. Good enough that quoting leaderboard numbers has become the default marketing move for memory products.

But notice the shape every one of these tests shares: a question arrives first. The system's job starts when someone — human or harness — asks. Accuracy is measured against a known answer after the fact.

Agent-native work does not wait for questions.

Prospective memory: acting at the right future moment

A stored intention sitting quietly in a knowledge base until its trigger condition occurs somewhere in a live environment — then firing, once, at the right moment, while other work continues — is a structurally different task. Retrieval accuracy does not capture it. Timing does.

The first serious attempt to isolate this shipped as PM-Bench (COLM 2026), with code on GitHub.

The setup

It simulates a seven-day work week: eighty decision points, eighty-three task definitions, seventy-four distractor events designed to look like triggers without being them. At each step the agent picks an ongoing activity and chooses which deferred intentions to fire. Event-based cues ("when the invoice clears") and time-based cues ("before Friday's review") both appear.

The scoring makes the central tension explicit. Set-F1 over selected actions punishes both failure modes: aggressive policies spam every plausibly-relevant action, conservative ones under-fire and miss. Precision-recall control, made into a benchmark.

The results are humbling

The best configuration — a frontier model — reached 65.1% Set-F1. On tasks spanning multiple days, and on tasks where the stored intention had been updated mid-week, every setup scored below 50%. These are not obscure edge cases. Multi-day deferral and mid-flight updates are what actual work looks like.

So the state of the art on the only benchmark built for initiation is: worse than a coin flip exactly where real work gets hard.

Silence is an explicit action

The deeper problem is not just that agents fail to fire intentions. It is that nothing in the retrieval framing even represents the choice.

One recent system names it directly. Its authors observe what they call behavioral state decay: information sitting in a transcript or context window progressively stops exerting control over the next decision. The passport number is in the log; the agent still books the flight without checking expiry. Their fix, described in Remember When It Matters (code), reframes memory entirely — not as a store to query, but as an intervention problem. At each decision point, a separate memory process decides whether any retained state should become active now, or not.

Which means silence becomes an explicit, scoreable action. The intervention space is two-valued: remind, or stay quiet. Fire the stored intention, or hold it. This is the decision retrieval pipelines never make, because retrieval assumes a query asked the question already. Proactive memory has no query. Someone has to decide that this moment — out of all moments — is the one where the archive should speak.

Run that framing against standard agent benchmarks and the gains are immediate: +8.3 points on Terminal-Bench 2.0 and +6.8 on τ²-Bench, with a plain Sonnet-class model doing the intervening. No architecture change to the action agent. Just a process whose whole job is deciding when retained state should seize control of the next decision.

The cost asymmetry nobody prices in

There is a cost side too, and it is asymmetric. A missed reminder produces no error message. Nothing crashes. The trip gets booked, the passport expires in month three, and the failure surfaces far from its cause, attributed to nobody. A spurious reminder, meanwhile, burns trust on every false alarm. Any team that has muted a noisy alerting system knows exactly how this ends.

Intervention timing is a precision-recall problem wearing a memory costume, and the tuning point differs per team, per workflow, per stakes.

The system side already drifted here

While benchmarks ignored initiation, system builders moved toward it anyway, because deployments forced them.

Executable-memory systems — where user state lives as typed code and rules rather than retrieved fragments — started shipping what the User as Code paper calls Active Service: unsolicited anticipatory alerts. The canonical example is exactly right: the system notices the passport expires before the booked trip and tells you unprompted. No benchmark ever asked a question there. The value came precisely from the absence of a question.

The pattern generalizes past personal assistants. An agent-native engineering team runs on the same mechanics. One agent's merge is another agent's cue. A flaky test fixed on Tuesday is a stored intention for Wednesday's release pipeline. A pricing decision reversed in a Slack thread is a supersession event that should silence every document still citing the old number. None of these fire because someone queried a knowledge base. They fire because something changed and the memory system noticed.

Notice what all of these require: knowing what changed, whether the change propagates, and whether now is the moment to act. That is currentness plus timing — neither of which appears on any public leaderboard. The evaluation gap and the deployment need are pointing at the same hole.

What agent-native teams should measure

If you run agents in production, the useful questions are not "what is the LoCoMo score." They are:

1. Of the intentions that should have fired this week, how many did? Hits versus misses.
2. How many fired late — after the window where acting still mattered?
3. How many were false alarms, and did anyone start ignoring them?
4. When a stored premise changed mid-stream, did the dependent intention update or fire stale?
5. What did each correct intervention cost — tokens, latency, and human attention?

PM-Bench's diagnostic taxonomy — hit, late, miss, false-alarm, update-violation — is the closest public template. It maps almost one-to-one onto the incident review any serious team already runs for humans. And cost belongs on the list for hard reasons: one systems characterization of agent memory (arXiv:2606.06448) found up to 47× cost differences per correct answer across architectures — before counting the price of an un-timed intervention at all.

The uncomfortable summary

The industry can retrieve nearly anything, at rising and wildly varying cost, and still cannot reliably do the thing memory evolved to do in the first place. Act at the right time. Stay quiet otherwise.

Agent-native teams will not be built on better filing clerks. They will be built on colleagues who speak first, at the moment speaking matters, and who know the difference between that moment and every other one.

The benchmarks will eventually follow. Your deployment cannot afford to wait for them.