Temporal memory & evolution
Bi-temporal, symbol-level change history — what changed, when, with what, and what it did to complexity — plus a daily briefing, hotspots, and session review.
Memtrace records history at save granularity, not just commit granularity. Every file save while a repo is watched becomes a working_tree episode; every commit becomes a git_commit episode. That stream of episodes is what every tool on this page reads — from a single symbol's timeline to a repo-wide daily briefing.
Overview#
Evolution, timelines & episode replay#
get_evolution is the primary tool for "what changed in this window" and "what did I just break" questions. Give it a from timestamp (and optionally to, defaulting to now) and it walks the episode stream in one of three modes:
| Mode | Shape | Use it for |
|---|---|---|
recent | Default. Per-episode adds/removes/modifies, paginated (default 100/page) | Walking exactly what happened, episode by episode |
compound | Top-N changed files + top-N touched symbols, rolled up | A quick "what moved" summary after a work session |
summary | Totals + first/last episode metadata only (cheapest shape) | A cheap sanity check on activity volume |
get_evolution works across both git_commit and working_tree episodes, so you can diff against uncommitted changes too. A useful pattern: call it with from=<timestamp before your change>, mode=compound right after implementing something, to catch unintended regressions before they land in git.
get_timeline narrows to one symbol: its full version history across every episode, with signature, content, and AST hash at each point — enough to see whether an edit was structural or just whitespace, and whether someone else touched it recently.
detect_changes and get_changes_since answer the same family of question from different entry points. detect_changes takes a diff or a list of changed files and resolves them to the affected symbols and their structural roles (community, process, blast radius) — useful for scoping a PR description precisely. get_changes_since takes a since timestamp (plus optional until and branch) and returns the flat list of episodes in that window with per-episode node/edge add/remove counts and repo-wide totals — a lighter-weight alternative to get_evolution when you just want the window's activity, not a full replay.
get_episode_replay goes one level deeper still: it replays exactly what a single episode (one commit or one save) added, modified, and removed in the graph — the change story behind one change, including abandoned attempts and reversions, without re-running git yourself.
Co-change coupling#
get_cochange_context finds symbols and files that historically change together — i.e., appear in the same commits — ranked by co-occurrence frequency across episodes. This surfaces coupling the static call graph can't show: if two files always change together but never call each other, editing one should still put the other on your checklist. It's the complement to get_impact's structural (caller/callee) blast radius, and it's one of the inputs preflight_check bundles together before you edit an existing symbol.
Daily briefing, hotspots & session review#
Three tools read the same bi-temporal version history to support a daily rhythm around editing:
| Tool | Answers | Default window |
|---|---|---|
get_daily_briefing | What changed recently, with complexity delta per function, new functions, new API endpoints, and per-module change distribution | 24 hours |
find_hotspots | Which functions rank highest by complexity × churn — where the next bug is likely to live | 14 days |
review_agent_sessions | Recent editing sessions clustered by actor and time gap, each judged clean / review / risky by net complexity added | configurable |
Use get_daily_briefing at the start of a session to see what moved before you touch anything, and again afterward to check your own net effect — a negative complexity delta means you left the code simpler than you found it. find_hotspots beats a raw complexity ranking for prioritizing refactors, because it weights risk by how often code is actually touched, not just how complex it looks sitting still.
review_agent_sessions is meant as a self-audit: if your own session comes back "risky", simplify what you added before calling the work done, rather than waiting for a human reviewer to flag it.
Session attribution#
review_agent_sessions's per-session actor attribution comes from last_agent_id, a field stamped directly onto symbol versions as they're written during an editing session. This means the review is graph-derived, not transcript-derived — Memtrace isn't reading chat logs or tool-call history to figure out who did what; it's reading who last wrote each version of each symbol, straight from the temporal graph itself.

For a broader tour of how the graph itself is structured, see the knowledge graph, or for the visual face of this same history, see the dashboard.