Real-Time Memory Sync

Architecture for live memory updates across distributed agent systems

advancedreal-timestreamingdistributedsync

Overview

Real-time memory sync enables multiple agent instances, devices, or systems to share memory updates instantly. When one agent learns something, all related agents know it immediately. This is essential for enterprise deployments, multi-device users, and collaborative agent systems.

Use Cases

Multi-Device Sync

User's agent on phone learns something → Laptop agent knows instantly

Agent Fleet Coordination

Support agent learns customer preference → All customer-facing agents updated

Collaborative Agents

Research agent finds information → Writing agent uses it immediately

Live Dashboards

Agent memory changes → Admin dashboards update in real-time

Architecture

┌─────────────────────────────────────────────────────────────┐

│ Agent Instances │

│ │

│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │

│ │Agent A │ │Agent B │ │Agent C │ │Agent D │ │

│ │(Phone) │ │(Laptop) │ │(Support)│ │(Admin) │ │

│ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │

│ │ │ │ │ │

└───────┼──────────────┼──────────────┼──────────────┼────────┘

│ │ │ │

└──────────────┼──────────────┼──────────────┘

│ │

▼ ▼

┌─────────────────────────────────────────────────────────────┐

│ Real-Time Message Bus │

│ ┌─────────────────────────────────────────────────────┐ │

│ │ Pub/Sub Channels │ │

│ │ ├── user:{user_id}:memories │ │

│ │ ├── tenant:{tenant_id}:shared │ │

│ │ └── system:global │ │

│ └─────────────────────────────────────────────────────┘ │

└──────────────────────────┬──────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐

│ Persistent Memory Store │

│ ┌─────────────────┐ ┌─────────────────┐ │

│ │ Vector Store │ │ Event Log │ │

│ │ (Qdrant) │ │ (Kafka/Redis) │ │

│ └─────────────────┘ └─────────────────┘ │

└─────────────────────────────────────────────────────────────┘

Message Flow

Memory Write

  • Agent A creates new memory
  • Write to persistent store
  • Publish to relevant channels:
  • - user:{user_id}:memories (user's other devices)

    - tenant:{tenant_id}:shared (if shared memory)

  • Subscribers receive update
  • 5. Each agent updates local cache

    Memory Read

  • Agent checks local cache
  • If miss, query persistent store
  • Subscribe to updates for accessed memories
  • Future updates arrive via subscription
  • Channel Design

    User-Scoped Channels

    `user:{user_id}:memories`

  • All memory updates for a user
  • Multi-device sync
  • Personal agent coordination
  • Tenant-Scoped Channels

    `tenant:{tenant_id}:shared`

  • Shared organizational knowledge
  • Team memory updates
  • Policy and preference changes
  • Topic Channels

    `topic:{topic_id}:updates`

  • Updates about specific subjects
  • Selective subscription
  • Reduces noise
  • Event Schema

    Memory Event

    MemoryEvent:

    ├── event_id: unique identifier

    ├── event_type: create | update | delete

    ├── timestamp: when it occurred

    ├── memory:

    │ ├── id: memory identifier

    │ ├── content: memory text

    │ ├── embedding: vector (optional, can recompute)

    │ ├── type: fact | preference | conversation

    │ └── metadata: additional context

    ├── source:

    │ ├── agent_id: which agent created

    │ ├── session_id: which session

    │ └── user_id: whose memory

    └── channels: which channels to publish to

    Sync Strategies

    Eager Sync

    Push all updates immediately:

  • Lowest latency
  • Highest bandwidth
  • Best for critical updates
  • Use for small number of subscribers
  • Lazy Sync

    Batch and push periodically:

  • Lower bandwidth
  • Higher latency
  • Good for less critical updates
  • Better for many subscribers
  • Pull-Based Sync

    Subscribers request updates:

  • Agent requests since last sync
  • Good for intermittent connectivity
  • Reduces unnecessary traffic
  • Requires tracking sync state
  • Conflict Resolution

    Last-Write-Wins

    Simple, deterministic:

  • Use timestamp ordering
  • Most recent update wins
  • May lose concurrent updates
  • Good for simple cases
  • Vector Clocks

    Track causality:

  • Detect true conflicts
  • Preserve concurrent updates
  • More complex implementation
  • Better for collaborative systems
  • Merge Strategies

    For different memory types:

  • Facts: Last-write-wins
  • Lists: Union merge
  • Counters: CRDT merge
  • Conflicts: Surface to user
  • Caching Layer

    Local Cache

    Each agent maintains:

  • Recently accessed memories
  • Subscribed memory updates
  • Hot working set
  • Cache Invalidation

    When update received:

  • Update cached entry
  • Or invalidate for re-fetch
  • Publish to dependent computations
  • Cache Warming

    On agent start:

  • Load user's recent memories
  • Subscribe to relevant channels
  • Pre-fetch likely needed data
  • Implementation Technologies

    Message Bus Options

  • Redis Pub/Sub: Simple, fast, limited durability
  • Kafka: Durable, high throughput, complex
  • NATS: Lightweight, fast, good for agents
  • Qdrant: Native change streams (emerging)
  • Persistence Layer

  • Qdrant for vector storage
  • PostgreSQL for structured data
  • Event log for replay capability
  • Client Libraries

    // Subscribe to user memory updates

    const subscription = memoryBus.subscribe(

    `user:${userId}:memories`,

    (event) => {

    localCache.apply(event);

    notifyAgent(event);

    }

    );

    // Publish memory update

    await memoryStore.save(memory);

    await memoryBus.publish(

    `user:${userId}:memories`,

    { type: 'create', memory }

    );

    Scaling Considerations

    Horizontal Scaling

  • Partition channels by user/tenant
  • Multiple message bus instances
  • Stateless agent instances
  • Geographic Distribution

  • Regional memory stores
  • Cross-region replication
  • Local caching for latency
  • Backpressure

  • Rate limit publishers
  • Buffer during spikes
  • Degrade gracefully