Memory Sidecar v3.5.1 is the operational hardening release for the public agent-agnostic memory system. If you’ve been running memory sidecars in production with multiple agents, you know the friction points: resource contention, recovery time after failures, and configuration drift across deployments. This release directly targets those areas with defaults tuned for stability and explicit controls for experienced operators. No new features were added for the sake of it—every change here had to prove itself under load in multi-tenant setups.
What Changed in This Release
The core improvement is in memory limit enforcement and error feedback loops. Previous versions relied on soft caps that could be exceeded during bursts, leading to cascading failures. v3.5.1 introduces a two-tier allocation model: a hard ceiling set via max_memory and a soft watermark at 80% that triggers preemptive cleanup. The cleanup routine itself was rewritten to avoid holding locks during I/O, which reduces contention when the sidecar serves concurrent requests from different agents.
Agent-agnostic support means the sidecar must handle varying request patterns without assuming a specific payload format or lifecycle. The new async middleware dispatcher decouples memory operations from network I/O, allowing you to plug in agents via standardized WebSocket or gRPC endpoints. The dispatcher uses a bounded channel with backpressure—if the buffer fills, the sidecar rejects new connections gracefully instead of crashing or leaking memory.
