Hiro development journal

Hiro memory-landscape review: durable records before agent recall

2026.07.22 at 07:38:22 America/Los_Angeles Published Machine-readable JSON

Executive summary

A review of the curated AI second-brain landscape found several useful memory layers, but no product should become Hiro's sole source of truth for calendar, task, reading-list, or approval state.

Hiro's present Markdown-plus-SQLite memory is adequate for simple facts but lacks explicit provenance, freshness, contradiction handling, retrieval observability, and a durable typed record model for planned assistant workflows.

The recommended path is a small local, typed system of record plus an inspectable recall layer. Evaluate memory behavior with held-out, stateful, provenance-aware tests before adopting a hosted service or graph substrate.

Work completed

Memory-landscape review

Completed

Reviewed the referenced landscape's end-to-end applications, local workspaces, agent-memory layers, graph substrates, and platform baselines.
Evaluated the options against Hiro's stated goals: calendar support, task and reading-list maintenance, useful proactive assistance, remote dashboard visibility, and approval-gated external actions.
Used the lifecycle distinction of collect, organize, evolve, use, and govern; retrieval quality alone is not a sufficient acceptance criterion.

Hiro architecture fit

Diagnosed

Hiro currently combines a manually maintained Markdown memory file with SQLite facts and conversation history, and injects selected memory into prompts.
The existing project goals and synthetic assistant cases require typed, approval-aware state for calendar, tasks, and reading lists, not merely semantically retrieved text.
No memory provider, connector, or runtime behavior changed during this review.

Decisions and reasoning

Keep canonical calendar, task, reading-list, contact, approval, and action records in a local typed database with source, revision, confidence, timestamps, and explicit deletion or supersession semantics.
Treat any LLM-derived memory as a candidate recall signal, never as autonomous authorization to send, schedule, modify, or delete external data.
Prioritize a governed local workspace or an application memory layer only after a small adapter can prove provenance, inspectability, correction, export, and access boundaries.
Do not choose a graph substrate first. Temporal or knowledge graphs may later improve relationship recall, but they add operational complexity and cannot compensate for weak write discipline or weak evaluations.
Do not claim that memory adoption advances Hiro autonomy until held-out evaluations demonstrate correct recall, contradiction resolution, stale-memory handling, non-use of irrelevant memories, and preservation of approval gates.

Validation and evidence

Check	Status	Result
Referenced landscape and source repository	reviewed	The landscape groups products by lifecycle coverage and explicitly distinguishes end-to-end apps, local workspaces, memory layers, graph substrates, and platform baselines.
Local Hiro memory and goal inspection	completed	The repository confirms a Markdown-plus-SQLite memory design, read-only calendar integrations, and stated approval-gated calendar, task, reading-list, and proactive-assistance goals.
Runtime or evaluation change	not-run-by-design	This was a research and architecture review; no provider was installed, no credentials were added, and no production or evaluation behavior was changed.

Current state

Hiro has a baseline persistence mechanism but not yet a measured, governed agent-memory subsystem suitable for autonomous action.
The current evaluation program has recently shown that high scores on repetitive synthetic prompts are not credible evidence of broad assistant capability; memory work needs harder stateful and blind tests before promotion.
The most suitable near-term direction is local structured state plus an inspectable recall adapter, with optional evaluation of Mem0 or a local workspace approach rather than immediate wholesale replacement.

Next steps

Define a versioned memory record schema and write policy for facts, preferences, tasks, reading items, plans, approvals, and source-derived observations.
Add memory-specific evaluations: correct recall, distractor rejection, contradiction and supersession, time-sensitive expiry, provenance citation, deletion, scope isolation, and action-boundary preservation.
Prototype one local adapter behind a feature flag, compare it against Hiro's current storage on held-out stateful scenarios, and retain it only if it improves measured behavior without weakening governance.
Consider graph memory only after the typed record and recall-evaluation foundations establish a real relationship-retrieval bottleneck.