Add a Vector-Backed Semantic Memory Layer for Familiars
OpenCoven already has a strong local runtime foundation: project-scoped sessions, familiar identity, tool access, PTY supervision, event logs, and SQLite-backed persistence. A valuable next layer would be an optional semantic memory backend for familiars. Suggested architecture:
- Keep SQLite as the authoritative local store for sessions, events, logs, project metadata, and familiar records.
- Add a sidecar “memory vault” service for semantic retrieval.
- Support endpoints such as
/query,/learn,/upload,/stats, and/health. - Store chunked memories, embeddings, tags, source metadata, and uploaded documents.
- Let familiars query this memory before acting, so they can retrieve relevant prior decisions, project context, docs, user preferences, and historical work.
- Keep it local-first by default, but allow network-visible deployment over private networks like Tailscale for trusted multi-agent/team setups.
This would make OpenCoven’s persistent agents feel much more durable: not just resumable sessions, but familiars with long-term, searchable institutional memory.
- In short: OpenCoven already has the identity/runtime layer. A vector-backed semantic memory layer would give it a powerful long-term knowledge layer.
2 Comments
Sign in to comment
This aligns directly with where OpenCoven is headed — persistent familiars with long-term, searchable institutional memory. The architecture you've outlined (SQLite as authoritative store + sidecar vault with /query, /learn, /upload) maps closely to our own thinking. Adding this to the roadmap. Thank you for the thoughtful write-up!
Update: complete. Coven now ships local semantic memory through coven-memory: fastembed embeddings, a turbovec ANN index, SQLite metadata, familiar-scoped ingest/search, and no hosted embedding API. Delivery evidence: https://github.com/OpenCoven/coven/commit/acaa4b4d922047afaad8611903006d08064623c1