Wanted to follow up on this... I dug into the codebase after your comment. You're right that the data is all there (last_access, access_count, raw Ebbinghaus relevance score, provenance source type) but it's siloed behind secondary tool calls rather than inline in the Activate response. That's the gap. I'm going to surface those fields directly in the next release so agents can make trust/refresh/ignore decisions in a single round-trip without needing to call muninn_read or muninn_provenance after the fact. Thanks for the sharp feedback! Exactly the kind of thing that comes from actually building multi-agent systems in production.
@xing_horizon Thanks! I really appreciate the feedback. You're spot on that downstream agents need clear signals to decide whether to trust, refresh, or ignore a recalled memory.
Right now `Activate()` already returns:
- Bayesian confidence per engram
- Full mathematical "Why" explanation (the 6-phase pipeline with exact contributions from ACT-R temporal decay, Hebbian strength, content match, etc.)
- `last_access` timestamp + access frequency (which directly feeds the decay calculation)
This already gives a solid freshness signal via the temporal weighting. Provenance (original source + creation context) is tracked internally but not yet exposed as clean first-class fields in the response... excellent callout, and that's jumping up the roadmap.
Would love to hear what specific provenance/freshness fields have worked best in the multi-agent systems you've worked with.
This is the project I just posted. Happy to dive into any details... the exact ACT-R decay formula, how the Hebbian graph updates in log space, the 6-phase Activate pipeline, or why I went with embedded Pebble. Fire away!