RMM Durable Memory: EFS + Postgres Fallback

2026-03-17

rmmmemorypaths

What We Built

Agent memory now survives ECS task replacement. The state directory resolution checks for EFS mounts first (BRAINSTORMROUTER_EFS_MOUNT / EFS_MOUNT_PATH), making SQLite-backed RMM durable with zero code changes to the memory layer. For environments without EFS, a Postgres fallback adapter (PostgresRmmStore) uses an in-memory SQLite as the working database with async Postgres sync for persistence.

Why It Matters

Previously, agent memory (core facts, archival knowledge) was lost every time an ECS task was replaced — during deployments, scaling events, or crashes. This made the memory system unreliable in production horizontal scaling scenarios.

How It Works

The fallback chain: EFS mount → Postgres adapter → ephemeral SQLite (with warning). EFS is the primary solution because it requires zero changes to the RMM layer — SQLite files are simply stored on a network-attached filesystem. The Postgres adapter pre-loads from rmm_core_memory/rmm_archival_memory tables into an in-memory SQLite, preserving the synchronous DatabaseSync API that all 25+ RMM functions use, with background write-through on mutations.

Lockstep Checklist

[x] API Routes: No changes.
[x] TS SDK: No changes needed.
[x] Python SDK: No changes needed.
[x] MCP Schemas: No changes needed.
[x] Master Record: N/A — infrastructure change.