Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Memory architecture

Flock memory is the coordination substrate plus durable episode artifacts — not a vector store or chat transcript archive.

Layers

LayerWhereRole
HotIn-process blackboard + pheromone fieldLive stigmergy (decay, wake, dispatch)
Warm.flock/ JSON today; .flock/memory.db plannedEpisodes, traces, checkpoints, topology archive
ColdTurso Sync (optional, Phase 3)Team backup and multi-machine share

Today (Phase 0)

flock run --goal "reach target" --plugin gridworld   # → .flock/episodes/<id>.json
flock replay --episode .flock/episodes/<id>.json
flock replay --continue-run --episode .flock/episodes/<id>.json

Working state: flock_read_blackboard, flock_deposit_signal during live episodes (MCP tools).

Phase 2 (SQLite queries)

When [memory] backend = "sqlite":

  • flock evolve reads episode_metrics aggregates instead of scanning full episode JSON
  • substrate_heatmap() and plugin_grounded_fitness() use SQL-native corpus aggregates
  • MCP flock_query_field_history queries checkpoint-time field snapshots

When [memory] mirror_json = false, episodes are stored only in SQLite — the proposer skips JSON directory scans and reads exclusively from the memory store.

What never goes in the database

  • Live pheromone ticks (stay in-process)
  • Conversation transcripts for coordination
  • Vector embeddings (deferred)

See Coordination model for the coordination protocol.