Thread

VK
Vladimir Kuzmin2:34 PMOpen in Slack
Hey team 👋 Nothing urgent here at all - hope you’re all having a great weekend and enjoying some downtime, I’ll just leave this thread here so you can share any thoughts whenever you have time.
Quick follow-up on the durable memory feature - I'll leave further detailed information inside the thread so as not to clutter the feed.

2 replies
VK
Vladimir Kuzmin2:35 PMOpen in Slack
I’m actively working on it and already have almost everything needed for the first version in place.
The current implementation is designed as a review-first memory system: memory candidates are extracted/proposed, reviewed by a human, and only then can become approved memory. I’ve also already laid the foundation for future expansion, including multiple memory scopes, so if later we want to support things like project-like memory sections similar to ChatGPT Projects, the core structure should already be ready for that.
A lot of the security-related concerns are also already accounted for: candidate-only writes, policy screening before persistence, approval guards, tombstones, scoped access, and guarded prompt-time injection. On the product side, the basic frontend flow is also covered: memory review queue, approved/archived states, manual proposals, approve/reject/archive flows, and visibility into policy flags/metadata etc.
@user tagging you separately since you opened the original issue and may be the best person for more detailed alignment here.
My assumption is that we probably want to roll this out gradually: first ship a conservative v1, test the full pipeline, observe how it behaves, and then expand from there.
Do you already have any specific thoughts or expectations (other than those already described in the task) about what should definitely be included in the first implementation?
IK
Innokentii Konstantinov (archestra team)9:30 AMOpen in Slack
Hi, answered in the github issue
🤝1