[Radar] Track persistent coding-agent memory as adjacent surface

[luoyuctl]

Background

Recent ecosystem scan surfaced a distinct adjacent surface around persistent memory for coding-agent sessions. Tools in this space capture what an agent did, compress observations, store semantic memory locally, and inject relevant context into future sessions. agenttrace currently focuses on local observability, completed-session diagnosis, health, cost, anomalies, reports, and CI evidence. The overlap is session capture and context evidence; the product difference is diagnostic reporting versus memory writeback into future agent runs.

Evidence

• Tavily scan on 2026-05-04 surfaced thedotmack/claude-mem: https://github.com/thedotmack/claude-mem
• Public writeups describe it as a Claude Code plugin that captures coding-session activity, compresses observations, and injects relevant context into future sessions.
• The same scan surfaced mirrored and explanatory pages describing local SQLite storage, vector search, lifecycle hooks, tool usage capture, and semantic summaries.
• The signal is specifically about context preservation across sessions, not just searching history or viewing logs.
• Duplicate checks for claude-mem persistent memory session capture context and memory context compression Claude Code sessions found no exact open issue.

User value

Users with long-running coding-agent projects may need to distinguish two related questions: what went wrong in a past session, and what context should carry forward into the next session. agenttrace answers the first today; persistent-memory tools target the second.

Adoption rationale

Tracking this signal helps keep agenttrace's local-first observability positioning clear while monitoring whether users start expecting report outputs, summaries, or anomaly evidence to feed memory systems safely.

Suggested scope

• Keep as radar until there is direct user evidence that agenttrace outputs should support memory workflows.
• Compare current JSON/HTML overview fields against the minimum evidence a memory layer might consume: session identity, tool failures, anomalies, cost, health, and key paths.
• If promoted, split into a narrow product/parser task such as memory-safe export fields or clearer summary text for external tools.
• Prefer interoperability with existing reports before adding any memory capture or writeback behavior.

Non-goals

• Do not add persistent memory from this radar item.
• Do not inject context into future agent sessions.
• Do not add vector search, semantic compression, or local databases.
• Do not collect or upload prompts, secrets, raw sessions, or private logs.
• Do not position agenttrace as a memory system without a separate product decision.

Acceptance criteria

• Maintainer decides whether this remains radar, informs docs/positioning, or becomes a focused interoperability task.
• Any promoted work names the external workflow and the minimum safe artifact agenttrace should expose.
• Follow-up preserves local privacy and keeps completed-session diagnosis separate from memory writeback.
• Related session-search and observability radar issues are cross-checked before implementation.

Suggested lane

lane/radar, priority/P2, status/needs-human

Risk

Medium. Persistent memory is adjacent and useful, but it can blur privacy, context hygiene, and product scope. The low-risk path is to track the signal and only promote export/interoperability work with clear user evidence.

Source

source/radar: Tavily ecosystem scan and duplicate checks on 2026-05-04.

[luoyuctl]

ok

[luoyuctl]

Additional ecosystem validation (2026-05-04):

Dedicated MCP search refreshed the persistent-memory adjacency signal and surfaced a local-first tool mention:

• Aura result: local-first AI daemon for persistent memory across tools.
• Search summary also mentions verifying agent claims and tracking AI session cost, which crosses memory, validation, and session observability.

Duplicate check for Aura local-first AI daemon persistent memory found no exact open issue; persistent memory cost sessions across tools maps back to this radar item.

Product routing: keep #105 as radar. This reinforces the adjacent memory surface, but agenttrace should not become a memory daemon without a concrete local observability workflow, such as annotating session summaries with memory/context reuse evidence or identifying when stale memory caused cost/tool-failure churn.

Event: Evidence
Actor: Product
Scope: #105
State change: none
Evidence: dedicated MCP search; Tavily unavailable in this session.
Next owner: Human

[luoyuctl]

Event: Evidence
Actor: Product
Scope: #105
State change: none; keep lane/radar,status/needs-human
Evidence: Current master f354b39 improves the safe artifact side of this radar without changing product scope:

• JSON/HTML overview reports now include incident timelines, failure families, health/cost/tokens, and tool-surface evidence that an external workflow could read after a run.
• Baseline comparison can describe local regressions without requiring prompt upload, hosted storage, or writeback into future sessions.
• No current behavior injects memory, stores semantic summaries, or changes future agent context.
  Next owner: Human

Product read: keep this as radar. If promoted later, the narrow scope should be interoperability wording or memory-safe export fields for completed-session evidence. It should not become persistent memory, vector search, context injection, or a local daemon unless a separate product decision explicitly changes that boundary.