The Memory Sidecar has always been the invisible workhorse behind decentralized agent interactions—providing agent-agnostic memory persistence without coupling to any single AI framework. With v3.5.1, the focus shifts from feature velocity to operational maturity. This release, delivered via the hermes-memory-installer, is expressly designed for teams running memory sidecars in production at scale. If you’ve been treating your memory layer as a pet, it’s time to make it cattle.
What’s Changed in v3.5.1
This is not a feature drop. There are no new memory backends, no fancy compression algorithms, and no API-breaking changes. Instead, v3.5.1 closes long-standing gaps in resource governance, fault isolation, and observability—the three pillars that separate a prototype from a service.
Tighter Resource Governance
Memory sidecars are notoriously hungry when handling large vector embeddings or replay buffers. Earlier versions relied on the host OS to enforce limits, leading to cascading OOM kills. In v3.5.1, the hermes-memory-installer now generates systemd drop-in units that wire cgroup v2 memory and CPU limits directly into the sidecar process. You define the ceiling in the installer config; the installer ensures no single sidecar can starve the host or adjacent containers.
