What Did Your Agent Believe Last Tuesday?

On 5 August your deployment agent skipped a staging check that it had run correctly for six weeks. You have the trace. You have the tool calls. You have the exact prompt. None of them answer the only question that matters, which is what the agent believed about your deploy process at 09:14 that morning.

Observability tools reconstruct behaviour. Almost nothing reconstructs knowledge. That gap is why agent postmortems so often end in a shrug and a prompt tweak. Memanto has three temporal recall modes built for the knowledge side of the question, and once you have used them on a real incident it is hard to go back.

Three modes, one flag each

Each one answers a different question, so you pick exactly one per command and the result is unambiguous about which reconstruction you asked for.

Temporal queries take no search string

“A temporal query is a reconstruction, not a search. It lists the memories that satisfy a moment in time, and you shape the result with structure rather than with a query string.

bash# the shape of every temporal query: a moment, and optional structure
memanto recall --as-of 2026-08-05
memanto recall --changed-since "last 14 days"
memanto recall --recent

This is what makes the answer trustworthy. --as-of rebuilds the complete set of memories that were live at a date. Ranking that set by similarity to a phrase would return the ones that resemble your wording rather than the ones that were true, and the whole point of a point-in-time query is to get all of them.

You narrow the result with structure, which is sharper than a phrase and completely predictable.

bash# what decisions were in force on 5 August
memanto recall --as-of 2026-08-05 --type decision --limit 50

# what changed in the deploy tag since the release
memanto recall --changed-since "last 14 days" --tags deploy,release

# the 20 newest instructions, whatever they are about
memanto recall --recent --type instruction -n 20

--type, --tags, and --limit are the three that work. --min-similarity and --min-confidence belong to standard semantic recall and have nothing to score against in a temporal query.

--as-of: reconstructing what was true

A memory is included in an --as-of result when both of these hold: it was created at or before the target moment, and it had not yet expired at that moment.

The second half is the one worth dwelling on. A memory that expired after the target date is still returned, because it was true at the point in time you are asking about. Expiry does not rewrite history. It only changes what your agent gets briefed on going forward.

Those memories also come back marked active, because active is what they were on the date in question. Reporting today's lifecycle state inside a historical reconstruction would be answering a different question than the one you asked.

A date means the end of that day

A date-only value covers the whole of that day. --as-of 2026-08-05 resolves to the very end of 5 August rather than midnight at its start, so everything written during the day you named is included, which is almost always what you meant by naming a day.

bashmemanto recall --as-of 2026-08-05              # end of 5 August
memanto recall --as-of 2026-08-05T09:14:00Z    # 09:14 that morning, to the second
memanto recall --as-of yesterday               # end of yesterday, not its start

yesterday is special-cased for exactly this reason. The general relative-time helper returns the start of a day, because its usual consumer is a "what changed since" query. Using that value for --as-of yesterday would drop nearly everything created yesterday, so --as-of resolves it to the end of the day instead. If you are investigating a specific incident, pass the full ISO timestamp and remove the ambiguity entirely.

--as-of already answers the lifecycle question

bash# live on 5 August
memanto recall --as-of 2026-08-05

# live right now, ranked against a question
memanto recall "deployment policy" --active

--active means live now. --as-of means live then. A point-in-time query already returns exactly the memories that were active at the date you named, so the lifecycle filter has nothing left to do. Keep them as two separate questions and each one stays easy to reason about.

The delete-and-recreate case

Here is a subtlety that separates a real point-in-time query from an approximate one. Suppose a memory was deleted and recreated with the same id in September. The obvious implementation fetches every version, picks the newest, and then checks whether it existed in August. The September version wins the newest-version contest, fails the date check, and the August version you actually wanted never makes it into the result.

Memanto applies the date cutoff before deduplication, so only versions that existed at the target moment compete to be the one returned. A rewrite that happened after your target date cannot evict the version that was valid then.

A second guard sits next to it: point-in-time recall fetches every lifecycle state and applies its own expiry check against the target date, so a memory that was valid in August and has aged out since still appears in the August reconstruction. Both guards only matter on an estate that has been running for months, which is precisely when you reach for the feature.

--changed-since: the diff

A memory qualifies as changed when it was created after the boundary, or updated after it. Each result is tagged with which of the two it was, and the tag shows up in the recall panel.

Creation is checked first, so a memory that was both created and edited inside the window is reported as created, which is the more informative of the two. Results are sorted newest change first, using whichever timestamp qualified the memory: created_at for a new one, updated_at for an edited one. Sorting all of them by updated_at would scramble the ordering of new memories that have never been touched since.

bash# everything the fleet learned this sprint
memanto recall --changed-since "last 14 days" --limit 100

# only the decisions, since a specific morning
memanto recall --changed-since 2026-08-05T09:00:00Z --type decision

--recent: the cheapest one

No boundary, no query, just the newest memories first. It is the fastest way to answer "what has this agent learned lately", and it is the one temporal mode that does honour --active and --expired.

bashmemanto recall --recent --limit 10
memanto recall --recent --type error --active -n 20

That second command is a genuinely useful daily habit for anyone running an agent fleet: the twenty most recent live failures, in order, with no query to guess at.

The relative-time grammar

Every temporal flag accepts a relative phrase as well as an ISO timestamp. The full accepted set:

last and past are interchangeable. last month and last year are fixed lookbacks of 30 and 365 days rather than calendar-window arithmetic, because the flag resolves to a single instant and calendar months do not have a fixed length. Extra whitespace is collapsed, so last 7 days parses the same as last 7 days.

Four things to actually use this for

1. The agent postmortem

Start from the incident timestamp and work outward. First reconstruct what the agent knew, then find what moved just before.

bash# what was in force at the moment it went wrong
memanto recall --as-of 2026-08-05T09:14:00Z --type instruction --limit 50
memanto recall --as-of 2026-08-05T09:14:00Z --type decision  --limit 50

# what had changed in the 48 hours before that
memanto recall --changed-since 2026-08-03T09:14:00Z --limit 100

In practice the answer is usually visible in the second command. Something was written two days earlier that contradicted an older instruction, both were live, and the agent was briefed on both.

2. Onboarding a person, not an agent

Someone joins the project on Monday. --changed-since scoped to their start date is a genuinely readable answer to "what has changed since I last looked", and it is far better than a diff of the repo, because it is written in decisions rather than in code.

bashmemanto recall --changed-since 2026-07-01 --type decision --limit 100
memanto recall --changed-since 2026-07-01 --type learning --limit 100

3. Verifying a migration or an import

After importing an estate from another provider, --as-of is the check that tells you whether the timestamps survived. If a migration wrote everything with today's date, a point-in-time query from before the import returns nothing, and you know the history was flattened.

bash# should return the memories that predate the import
memanto recall --as-of 2026-03-01 --limit 20

# should return the import itself
memanto recall --changed-since "last 2 days" --limit 100

4. The weekly review

bashmemanto recall --changed-since "last 7 days" --limit 100
memanto recall --recent --type error --limit 20

Two commands, once a week. The first is what the fleet learned. The second is what it keeps tripping over. If the second list has not changed in a month, you have found a real problem worth fixing in code rather than in memory.

Reach for the right mode

The last row is worth stating explicitly, because it is the one people forget once they discover the temporal flags. Semantic recall is still the right tool for "what do we know about X". The temporal modes answer "when", and the two compose: reconstruct the moment first, then search the present for what has changed about it.

The habit worth forming

Most people discover temporal recall during an incident, which is the worst time to learn a new flag. The better move is to run memanto recall --changed-since "last 7 days" every Friday for a month. You will start noticing the shape of what your fleet actually learns, and by the time something goes wrong you will already know which of the three modes answers the question.

Logs tell you what happened. This tells you why the agent thought it was the right thing to do.