Spacebot

Type: ../types/agent-memory-system-review.md · Status: current · Tags: trace-derived

Spacebot, from spacedriveapp/spacebot, is a Rust agent harness for multi-user messaging channels, background branches and workers, task execution, structured memory, skills, and scheduled autonomy. At the reviewed commit, its memory system is not a Markdown store: it combines SQLite records and graphs, LanceDB embeddings/FTS, generated working-memory summaries, prompt-injected knowledge context, explicit recall tools, and trace-derived persistence branches.

Repository: https://github.com/spacedriveapp/spacebot

Reviewed commit: ac52277404d3813045aa053b78c95810ab85e7c5

Last checked: 2026-06-05

Core Ideas

State is held by the harness, not by an LLM-managed scratchpad. The README explicitly frames Spacebot as an agent harness where "state belongs in structured storage" and the code backs that with SQLite migrations for memories, associations, conversations, tasks, worker runs, working-memory events, profile data, attachments, projects, and settings (README.md, migrations/20260211000001_memories.sql, migrations/20260319000001_working_memory.sql). The LLM processes reason over state selected by tools and prompt assembly; they do not own the storage substrate.

The long-term memory is typed, ranked, embedded, and graph-connected. Memory records carry content, memory type, importance, timestamps, source, channel id, access counters, and a forgotten flag; associations carry relation types such as updates, contradicts, caused_by, and part_of (src/memory/types.rs). Recall uses LanceDB FTS, vector search, high-importance graph traversal, and Reciprocal Rank Fusion rather than one retrieval mode (src/memory/search.rs, src/memory/lance.rs).

Spacebot has both explicit recall and ambient context. A branch or direct-mode channel can call memory_recall with hybrid, recent, important, or typed modes; every normal channel prompt can also receive working memory, channel activity, participant context, knowledge synthesis, and the memory bulletin without the acting channel asking for a specific memory (src/tools/memory_recall.rs, src/agent/channel.rs, prompts/en/channel.md.j2).

Context efficiency is layered rather than purely top-k retrieval. The channel prompt gets compact sections: generated knowledge synthesis for durable memory, programmatic working memory for recent events, channel and participant maps, skill summaries, project context, and status. The full skill body is not injected into every prompt; workers see skill names/descriptions and use read_skill on demand (src/skills.rs, src/tools/read_skill.rs, src/memory/working.rs). This reduces initial prompt volume, but the pushed context still grows in complexity because several memory surfaces can appear at once.

The memory write loop is trace-derived and partly governed. A silent memory-persistence branch periodically receives the channel history, must recall before saving, saves typed memories through memory_save, and terminates through a memory_persistence_complete contract that rejects fabricated saved IDs and can emit working-memory events (src/agent/channel.rs, src/agent/channel_dispatch.rs, prompts/en/memory_persistence.md.j2, src/tools/memory_persistence_complete.rs). The contract validates bookkeeping, not semantic truth.

Adoption is platform-native but operationally heavy. Spacebot exposes Discord, Slack, Telegram, Twitch, Signal, Mattermost, email, webchat, webhook, MCP, browser, file, shell, OpenCode, skills, tasks, cron, and secrets surfaces in one binary (README.md). The upside is an integrated team-agent runtime; the cost is that memory behavior depends on many runtime configs, prompt templates, background loops, and process roles.

Artifact analysis

  • Storage substrate: sqlite vector files — The durable agent state is primarily SQLite: memories/associations, conversation messages, tasks, worker runs, working-memory events/summaries, profile data, attachments, projects, and settings. LanceDB stores memory_embeddings with vector and FTS search. Skills live as directories containing SKILL.md files under instance and workspace paths, and ingestion consumes files dropped into an ingest directory (migrations/20260211000001_memories.sql, migrations/20260319000001_working_memory.sql, src/memory/lance.rs, src/skills.rs).
  • Representational form: prose symbolic — Memories, bulletins, working-memory summaries, skill bodies, prompts, wiki pages, task descriptions, and worker transcripts are prose. Memory types, association types, SQL schemas, task statuses, tool schemas, routing config, prompt templates, LanceDB rows, skill frontmatter, and model-routing rules are symbolic. Embeddings are used for ranking/search but I did not find retained model weights or adapters that carry learned behavior.
  • Lineage: authored imported trace-extracted — Prompt templates, skill files, configs, tools, schemas, and identity material are authored. Ingestion imports text/PDF-like files into the memory system through chunk processing. Conversation history, branch and worker outcomes, saved memory events, and working-memory events are trace-derived, then persistence branches, cortex synthesis, intraday synthesis, and daily summaries derive compact retained artifacts from those traces (src/agent/ingestion.rs, src/memory/working.rs, src/agent/cortex.rs).
  • Behavioral authority: knowledge instruction routing validation ranking learning — Memory records, wiki pages, working-memory summaries, bulletins, task records, and conversation history act as knowledge artifacts for agents and users. Prompts, skills, identity files, memory-persistence instructions, and worker/channel role templates instruct agents. Channels, branches, workers, cron jobs, task status, skills, model routing, and project context route work. Tool schemas, secret scrubbing, terminal memory-persistence contracts, association target checks, limits, and sandbox config validate or constrain behavior. Importance, access count, RRF, vector/FTS scores, graph weights, task priority, and model routing rank choices. Trace-derived persistence, cortex synthesis, working-memory rollups, maintenance, and skill installation are learning inputs for later action.

Typed graph memory. The central memory object is not just text. MemoryType changes default importance, associations change graph traversal, and forgotten controls search visibility (src/memory/types.rs, src/memory/store.rs). This gives the store more behavioral structure than an untyped transcript summary, but it still relies on LLM/tool calls to classify content faithfully.

Access structures. LanceDB embeddings and FTS rows are derived access artifacts. They make recall practical and supply rank signals, but SQLite remains the source of truth: on embedding creation failure, memory_save compensates by deleting the SQLite row and associations rather than leaving an orphan memory (src/tools/memory_save.rs).

Working memory and knowledge synthesis. Working-memory events are append-only temporal records around conversations; intraday and daily summaries are compressed prose views; knowledge synthesis is regenerated from selected memory/task sections and injected into future prompts (src/memory/working.rs, src/agent/cortex.rs). These are the strongest push-read-back artifacts because channels do not need to query for them.

Skills. Skill packages are file-backed system-definition artifacts: the channel receives a compact listing, the worker receives a listing with suggested flags, and the worker can call read_skill for the full instructions (src/skills.rs, prompts/en/fragments/skills_channel.md.j2, prompts/en/fragments/skills_worker.md.j2).

Promotion path. The implemented path is conversation trace or imported file -> typed memory/event/wiki/task/skill record -> generated synthesis or explicit recall -> future prompt/tool behavior. Maintenance can merge, decay, prune, and re-index memory, while skill installation can immediately raise a file artifact into worker instruction authority.

Comparison with Our System

Spacebot and Commonplace share the view that memory must be structured enough for agents to operate on it, but they put authority in different places. Commonplace uses repo-native Markdown, type contracts, validation, review gates, generated indexes, and source-grounded replacement. Spacebot uses a live service architecture: SQLite/LanceDB stores, prompt templates, runtime config, background branches, tools, and process-specific prompts.

The largest design divergence is read-back. Commonplace mostly relies on deliberate agent navigation and validation; Spacebot pushes ambient working memory and knowledge synthesis into channel prompts while also supporting explicit recall. That makes Spacebot better suited to chat agents that need continuous awareness, but it also risks context dilution and faithfulness problems unless the generated context is evaluated.

Spacebot's trace-derived path is also more automatic than Commonplace's ordinary note workflow. It periodically reviews conversation history and writes memories/events without a human editing the artifact. Commonplace would treat that as a high-authority ingestion path needing review, quote grounding, or validation before the distilled output changes durable methodology knowledge.

Borrowable Ideas

Layered memory surfaces. Commonplace could distinguish durable library memory, current-workshop activity, and cross-channel/process status as separate prompt sections instead of treating every retained artifact as the same kind of note. Ready for review-system and workshop automation.

Terminal contract for automatic memory extraction. Spacebot's memory_persistence_complete guard is a narrow but useful pattern: after an extraction agent writes records, require a terminal declaration that references only actually returned ids. Ready now for ingestion/review agents that produce machine-checkable side effects.

Pointer-first skill injection. Listing skills by name/description and letting workers read full instructions on demand is a good context-efficiency tradeoff. Commonplace already has skill discovery; the borrowable part is stricter prompt separation between the skill catalogue and full skill body.

Hybrid recall plus graph traversal. Spacebot combines vector, lexical, typed, importance, and graph retrieval. Commonplace should borrow that only with a concrete query layer, because its current repo-first navigation benefits from inspectability and validation more than from an always-on memory service.

Change-driven synthesis cache. A compact generated knowledge context that refreshes only when underlying memory changes could help large workshops. It would need lineage and review status before becoming library authority.

Write side

Write agency: manual automatic — Users and agents can manually save, delete, install, create, edit, and configure memories, skills, tasks, wiki pages, projects, cron jobs, and settings through tools/API. Automatic paths ingest files, spawn silent memory-persistence branches, save extracted memories/events, regenerate knowledge synthesis, roll up working-memory events, run memory maintenance, decay/prune/merge memories, and refresh embeddings/search structures.

Curation operations: consolidate dedup decay promote — Working-memory intraday/daily synthesis and knowledge synthesis consolidate events/memories/tasks into compact prose. Maintenance merges near-duplicate memories, rewires associations, and marks losers forgotten. Maintenance decays old or unaccessed memory importance and prunes low-importance old memories. Recent access can boost importance during decay calculations, making access history a promotion signal (src/memory/maintenance.rs, src/memory/store.rs, src/agent/maintenance.rs). I did not find a built-in semantic truth-maintenance loop that automatically invalidates contradicted memories while retaining an explicit stale history beyond updates/contradicts edges and the forgotten flag.

Trace-derived learning

Trace source: session-logs tool-traces event-streams trajectories — Conversation messages, branch/worker outputs, memory-saved events, working-memory events, process runs, worker transcripts/tool-call counts, and prompt snapshots can all feed retained context or later synthesis (migrations/20260211000002_conversations.sql, migrations/20260213000003_process_runs.sql, src/agent/prompt_snapshot.rs).

Learning scope: per-project cross-task — Memory is agent/workspace scoped with channel ids, tasks, projects, skills, and cross-channel activity surfaces. The same agent can carry lessons across conversations and tasks; project context and worker project links narrow parts of that memory to a workspace/repository.

Learning timing: online staged — Channels record conversations and working-memory events online; memory-persistence branches fire after message/time/event-density thresholds; cortex synthesis and maintenance run as background staged loops (src/agent/channel.rs, src/agent/cortex.rs).

Distilled form: prose symbolic — Distilled outputs include prose memories, knowledge synthesis, bulletins, intraday summaries, daily summaries, wiki pages, and skill bodies, plus symbolic memory types, associations, importance scores, tasks, event types, versions, ids, and status fields.

Extraction. The automatic conversation-memory extractor is an LLM branch with the channel's history. Its prompt requires recall first, selective saving, graph associations, event extraction, and terminal completion. The oracle is the branch model plus a narrow tool contract: memory_save records actual ids, and memory_persistence_complete validates that the terminal outcome names exactly those ids before extracted events are written (prompts/en/memory_persistence.md.j2, src/tools/memory_persistence_complete.rs).

Scope and timing. Spacebot splits raw traces from distilled behavior-shaping artifacts. Raw conversation and process records remain queryable as history; extracted typed memories and working-memory events shape future prompts and recall. The code validates operation structure and saved-id provenance, but I did not find a built-in semantic audit that checks whether an extracted memory is faithful to the source conversation.

Survey fit. Spacebot is a strong trace-derived chat-agent memory system: it turns ongoing interaction traces into typed memories, temporal events, summaries, and skills. It strengthens the survey point that read-back and learning are separate axes: Spacebot has both trace-derived writes and pushed read-back, but the quality of the pushed context is not proven merely by storing and injecting it.

Read-back

Read-back: both — Spacebot pushes retained memory into channel prompts through working memory, channel activity, participant context, knowledge synthesis, and memory context, while branches/direct-mode channels and tools can also pull specific memories through memory_recall.

Read-back signal: coarse identifier inferred / lexical inferred / embedding — Knowledge synthesis and memory context are coarse prompt sections assembled for every memory-enabled channel. Working memory, channel activity, participant context, channel settings, task lists, project context, and skill suggestions use identifiers such as channel id, user id, memory type, task status, project/worktree id, and skill name. Explicit recall supports lexical FTS and embedding similarity, with graph expansion and RRF ranking (src/memory/search.rs, src/memory/working.rs, src/agent/channel.rs).

Faithfulness tested: no — I found structural tests and contracts for tool behavior, saved-id bookkeeping, prompt rendering, ranking helpers, and memory maintenance, but not an end-to-end ablation, perturbation test, or post-action audit proving that injected memory changes future behavior faithfully.

The injected context is pre-invocation: build_system_prompt renders memory layers before the channel model call. The push is mostly advisory context, although skills and role prompts can become instruction authority when included. Full skill instructions are served on demand to workers via read_skill, so Spacebot avoids always injecting all skill content, but it still always exposes a skill catalogue when skills exist.

The main scope control is sectioning and budgeted rendering rather than strict proof of relevance. render_working_memory divides token budget across today, yesterday, and earlier-week sections; knowledge synthesis selects typed and important memory sections and active tasks; recall has max result limits; branches compact on context overflow; channel prompt snapshots can record what was sent for later inspection (src/memory/working.rs, src/agent/branch.rs, src/agent/prompt_snapshot.rs).

Other consumers include the human user through channel replies and UI/API surfaces, the cortex chat, branch and worker processes, cron/autonomy channels, wiki readers, task schedulers, and external tools connected through messaging/MCP/API routes.

Curiosity Pass

Spacebot is closer to an operating system for agents than to a memory library. Memory behavior emerges from channels, branches, workers, tools, prompts, tasks, cron, runtime config, and databases. That integration is powerful, but it makes any single "memory system" claim dependent on many process contracts.

The graph is typed, but relation quality is still LLM-mediated. The schema supports updates, contradicts, and part_of; memory_save checks target ids before creating edges. It does not prove the edge is semantically correct.

Ambient context is convenient and risky. The pushed Knowledge Context/Working Memory path solves the "stored but never activated" problem, but it can also inject stale, over-broad, or overconfident summaries into ordinary conversation unless freshness and faithfulness are monitored.

Skills are a second memory system. They are not memories in the memories table, but they are retained system-definition artifacts that can change worker behavior more directly than a fact memory.

The README promises autonomous skill capture, but the most clearly grounded automatic extraction path I found is memory/event persistence. Skill installation and worker prompt injection are implemented; truly autonomous "write a new skill from experience" may exist through agent tool use and filesystem/wiki capabilities, but I did not find a narrow, contract-enforced skill-capture loop comparable to memory persistence.

What to Watch

  • Whether Spacebot adds semantic verification for memory-persistence outputs, such as quote/source spans from the triggering conversation or contradiction checks before high-importance memories are injected.
  • Whether skill capture from experience becomes a dedicated, contract-checked loop rather than a general worker/tool capability; that would make skills a trace-derived system-definition artifact with stronger lineage.
  • Whether knowledge synthesis gains per-claim provenance back to memory ids, tasks, or conversation spans; without it, pushed summaries are hard to audit.
  • Whether memory maintenance adds explicit invalidation history for contradictions, not just merge/forget/decay operations.
  • Whether prompt snapshots are used for read-back faithfulness tests; they provide the substrate for WITH/WITHOUT comparisons but the reviewed code does not show that evaluation loop.

Relevant Notes: