Memory Sidecar v3.5.1: Operational Hardening for Agent-Agnostic Memory

Memory Sidecar v3.5.1 ships today as the operational hardening release for the public agent-agnostic memory service. If you’re running Memory Sidecar in production, this is your upgrade target. The focus is straightforward: tighten failure recovery, reduce memory pressure, and eliminate edge cases that only surface under sustained load. There are no new APIs or breaking changes—just the kind of robustness that keeps your agents’ memory consistent when the infrastructure wobbles.

The core value proposition remains unchanged: Memory Sidecar provides a persistent, queryable memory layer for AI agents without tying you to a specific agent framework. It runs as a sidecar process, exposing a gRPC interface for reading, writing, and searching memories. v3.5.1 doubles down on that operational contract.

What Changed

Three areas got significant attention:

Circuit Breaker for External Storage

The storage adapter now supports a tunable circuit breaker. Previously, connection retries could pile up during outages, causing backpressure on the entire sidecar. v3.5.1 introduces configurable failure thresholds and reset timeouts. When the backend (PostgreSQL, Redis, or SQLite) starts returning errors, the breaker opens after N consecutive failures and stops all write operations for a defined period. This prevents the sidecar from wasting resources on a dying connection and lets it return UNAVAILABLE upstream quickly. Writes are queued internally when the breaker is open, avoiding data loss if the backend recovers within the reset window.

Memory Pooling for Serialization

The internal memory representation—used for embedding vectors, metadata, and timestamps—now ships with object pooling. Every serialized record used to allocate fresh slices, putting pressure on the garbage collector under high throughput. v3.5.1 pre-allocates a pool of fixed-size buffers that the serializer borrows and returns. Our benchmarks show a 40% reduction in GC cycles with 1000 concurrent write requests. This matters when your agent’s memory write volume spikes during user interactions.

Graceful Shutdown with Write Barrier

Shutdown was previously best-effort. If the process received SIGTERM while flushing a batch of memories, those writes could vanish. v3.5.1 installs a shutdown hook that blocks termination until all in-flight writes complete or a configurable timeout (default 15 seconds) expires. The sidecar also drains the gRPC connection pool so clients get a clean UNAVAILABLE status instead of half-written state. This is critical for agent workflows that checkpoint after each conversation turn.

Configuration Example

The circuit breaker settings are exposed through the configuration file. Here’s a typical configuration for a PostgreSQL backend with conservative limits:

storage:
  adapter: postgres
  config:
    host: "pg.example.com"
    db: "memory_sidecar"
    pool_size: 20
  circuit_breaker:
    failure_threshold: 5      # Open after 5 consecutive write failures
    reset_timeout: "30s"       # Attempt half-open after 30 seconds
    max_queued_writes: 500     # Buffer writes during open state

The failure_threshold and reset_timeout replace the old unconditional retry loop. Setting max_queued_writes to zero disables the queue and fails the write immediately, which is useful if your agent prefers retry on the client side. The reset timeout defaults to 10 seconds if omitted.

Migration Notes

Upgrading from v3.4.x requires no schema changes or manual steps. The hermes-memory-installer package in v3.5.1 handles the binary replacement and configuration migration automatically, including the new default circuit breaker values (threshold=5, timeout=10s). If you rely on the old unlimited retry behavior, you can achieve it by setting failure_threshold: 0, but that voids the hardening guarantee—not recommended for production.

The one behavioral change to watch: the new shutdown hook introduces a slight delay during termination. If your orchestrator expects instant process death, bump the shutdown_timeout in the configuration file to match your deployment’s grace period. The default is already aligned with most Kubernetes pod termination grace periods.

Why This Release

Memory Sidecar v3.5.1 is not a feature release. It’s a declaration of operational maturity. The patterns for circuit breaking, memory pooling, and graceful shutdown are well-understood in distributed systems, but they hadn’t made their way into the memory sidecar until now. If you’ve been running v3.4.x in production, you’ve likely hit the retry storm issue during a backend hiccup or seen GC pauses affect agent response times. This release exists to close those gaps.

The agent-agnostic design means you can plug Memory Sidecar into any system—from LangChain agents to custom inference loops—and get predictable performance. v3.5.1 makes that prediction more reliable. Upgrade, test your workloads, and adopt the circuit breaker configuration that matches your latency tolerances. The rest of the internals are invisible but felt in the metrics.