This is a solid architecture. A few thoughts from someone building in a similar space:
On durable sessions with SQLite: If you're targeting edge deployments (robots, IoT), you might hit a wall with SQLite's concurrency model. SQLite uses file-level locking, which can block when you have multiple agent threads trying to write session state simultaneously. We ran into this on a robot project where perception, planning, and control loops all needed concurrent DB access.
On semantic memory: The word 'semantic' is doing a lot of heavy lifting here. Are you using HNSW/IVF for the vector indexes, or something custom? And how do you handle the cold-start problem when there's no prior context to retrieve?
On federated instances: This is the most interesting part to me. The idea of laptop + server sharing state is powerful. Are you using CRDTs, event sourcing, or something else for conflict resolution? This is genuinely one of the harder problems in distributed agent systems.
Would love to see more details on the storage layer. Good luck with Hacktoberfest!
On SQLite concurrency: You're absolutely right, SQLite's file-level locking is a real constraint for high-concurrency edge deployments. Rune's answer is multi-database architecture: SQLite is the zero-config local fallback, but PostgreSQL is the production target (Cosmos DB for Azure-native). The connection pool and write patterns abstract this — same binary, config-driven backend. For your robot use case (perception + planning + control loops), you'd want PostgreSQL or the async connection pooling we have in PgPool. We'd love contributions on SQLite WAL mode or read replicas if someone wants to push the embedded story further.
On semantic memory: We're using LanceDB (via lancedb crate) for vector storage, not raw HNSW/IVF. It's columnar, handles hot updates better than flat indices, and plays nice with our local-first requirement. For cold-start, we have explicit memory.level modes: file (scan local session files), keyword (FTS5), and semantic (hybrid with graceful fallback). The real challenge we're wrestling with now is fact deduplication — mem0's update semantics sometimes overwrite instead of merge. That's an active lane if you're interested.
On federated instances: Not CRDTs or event sourcing (yet). Current delegation is imperative with lease-based coordination, main instance picks a peer, reserves a branch/worktree, monitors health, and recovers on timeout. Shared state goes through the REST memory API (/api/v1/memory/*). You're right that conflict resolution is the hard problem, we're moving toward operation-based eventual consistency for vector stores, but right now it's "same user, different devices" rather than true multi-writer federation. We'd love eyes on this — it's genuinely unsolved in the agent space.
Storage layer details: happy to expand, we have rune-store with SQLite (rusqlite), PostgreSQL (sqlx), and Cosmos DB (azure_data_cosmos) implementations. The abstraction is StoreBackend trait, so new backends are ~300 lines.
Thanks for the thoughtful questions
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a solid architecture. A few thoughts from someone building in a similar space:
On durable sessions with SQLite: If you're targeting edge deployments (robots, IoT), you might hit a wall with SQLite's concurrency model. SQLite uses file-level locking, which can block when you have multiple agent threads trying to write session state simultaneously. We ran into this on a robot project where perception, planning, and control loops all needed concurrent DB access.
On semantic memory: The word 'semantic' is doing a lot of heavy lifting here. Are you using HNSW/IVF for the vector indexes, or something custom? And how do you handle the cold-start problem when there's no prior context to retrieve?
On federated instances: This is the most interesting part to me. The idea of laptop + server sharing state is powerful. Are you using CRDTs, event sourcing, or something else for conflict resolution? This is genuinely one of the harder problems in distributed agent systems.
Would love to see more details on the storage layer. Good luck with Hacktoberfest!
On SQLite concurrency: You're absolutely right, SQLite's file-level locking is a real constraint for high-concurrency edge deployments. Rune's answer is multi-database architecture: SQLite is the zero-config local fallback, but PostgreSQL is the production target (Cosmos DB for Azure-native). The connection pool and write patterns abstract this — same binary, config-driven backend. For your robot use case (perception + planning + control loops), you'd want PostgreSQL or the async connection pooling we have in PgPool. We'd love contributions on SQLite WAL mode or read replicas if someone wants to push the embedded story further.
On semantic memory: We're using LanceDB (via lancedb crate) for vector storage, not raw HNSW/IVF. It's columnar, handles hot updates better than flat indices, and plays nice with our local-first requirement. For cold-start, we have explicit memory.level modes: file (scan local session files), keyword (FTS5), and semantic (hybrid with graceful fallback). The real challenge we're wrestling with now is fact deduplication — mem0's update semantics sometimes overwrite instead of merge. That's an active lane if you're interested.
On federated instances: Not CRDTs or event sourcing (yet). Current delegation is imperative with lease-based coordination, main instance picks a peer, reserves a branch/worktree, monitors health, and recovers on timeout. Shared state goes through the REST memory API (/api/v1/memory/*). You're right that conflict resolution is the hard problem, we're moving toward operation-based eventual consistency for vector stores, but right now it's "same user, different devices" rather than true multi-writer federation. We'd love eyes on this — it's genuinely unsolved in the agent space.
Storage layer details: happy to expand, we have rune-store with SQLite (rusqlite), PostgreSQL (sqlx), and Cosmos DB (azure_data_cosmos) implementations. The abstraction is StoreBackend trait, so new backends are ~300 lines.
Thanks for the thoughtful questions