Spacebot: a Rust agent harness that keeps state out of the LLM's context window

The single-loop problem Spacebot is built around

The README states the problem directly: most agent frameworks run conversation, thinking, tool execution, memory retrieval and context compaction in one LLM thread. The stated consequences are that the agent cannot talk while it works, goes dark during compaction, and pollutes its context with raw memory search results. Spacebot's answer is to split that monolith into specialized processes that delegate rather than do everything themselves. The target user is not a solo developer with a terminal assistant. It is a Discord community with hundreds of members, a Slack workspace running parallel threads, or a Telegram group spread across time zones, where one person's long task must not block another person's question. The README also claims solo users get the same infrastructure, which is a positioning statement rather than a demonstrated benefit: nothing in the material shows what a single user gains from process-level concurrency they never exercise.

Five process types and the message path between them

Channels are the user-facing LLM process, one per conversation, carrying soul, identity and personality. A channel never executes tasks or searches memory directly. It branches to think and spawns workers to act. Branches fork from the channel's context, run concurrently with the full conversation history, and return only a conclusion; the channel does not see the working, and the branch is deleted afterward. Workers are independent processes that execute real work, and the README is specific about what they inherit: a worker begins as a full fork of the channel that delegated to it, carrying the conversation context behind the task rather than a one-line description, so it acts on intent instead of guessing. Workers are fire-and-forget for one-shot tasks or interactive for longer sessions, where follow-up routes to the active worker. The Compactor is explicitly not an LLM. It is a programmatic monitor that watches context size per channel and triggers compaction before the channel fills, with compaction workers running alongside without blocking. The Cortex is the supervisor: it sees across all channels, workers and branches, detects hung workers and stale branches, enforces timeout policy, and runs periodic memory-graph maintenance (decay, pruning, merging near-duplicates). The README notes the Cortex stays out of the token budget because when there is no work to do, nothing runs.

Chronicles, and why the compaction mode is the real architectural fork

The README describes two modes selected by the config key compaction.mode. In rolling mode, one summary sits at the head of history and is rewritten under pressure. In chronicle mode, compaction cuts append-only checkpoints over contiguous ranges of the transcript, and each checkpoint summarizes only the span since the last one. The live prompt carries a bounded window of recent checkpoints, with older ones rolling up. The stated motivation is that a single rolling summary, rewritten repeatedly over a long session, blurs details away. This is the most interesting design decision in the repository and also the least documented. The README does not say how large a checkpoint span is, how many checkpoints the live prompt retains, or what the roll-up threshold is. It presents both modes as available and gives no guidance on which session lengths suit which. If you are evaluating Spacebot for a bot that runs for weeks, that gap matters more than any of the process-type descriptions, because it determines what your agent can still recall on day thirty.

Skill capture and the idle background process

The README claims the agent gets smarter with use: after complex tasks it captures what it learned as reusable skills, and after conversations go idle a background process saves skills and memories worth keeping, with no user action required. Treat this as the least verifiable claim in the material. There is no described mechanism for how a skill is represented, how it is retrieved on a later task, how the system decides something is worth keeping, or how you would inspect or delete a skill the agent stored incorrectly. The memory side is more concrete: memory lives in a typed graph in SQLite, and the README's framing is that state belongs in structured storage rather than in markdown files the LLM manages. That is a real architectural position with a real cost, since a typed graph needs a schema and schema changes need migrations, and nothing in the material describes a migration story.

Getting it running: what the README actually specifies

The quickest path is the hosted one. The README states you can deploy with one click at spacebot.sh, connect Discord, Slack, Telegram or Twitch, configure the agent, and go, with no self-hosting required. That is the only deployment route the README spells out. For self-hosting, the README points to docs.spacebot.sh and to the architecture document at docs/content/docs/(core)/architecture.mdx for process capabilities, tool access by type, memory internals and multi-agent isolation. What the README does not contain is a self-host build command, a Docker invocation, a binary download link, or a sample config file. The one config key it names is compaction.mode, with the values rolling and chronicle. If you intend to run this yourself, the honest position is that the README alone is not enough to get you there, and the docs site is where you would have to start. The repository is written in Rust, and the README describes running multiple agents on one instance (a community bot on Discord, a dev assistant on Slack, a research agent on background tasks, each with its own identity, memory and security permissions) as one binary and one deploy.

What the message coalescing claim leaves open

For Discord specifically, the README says a message coalescing system detects rapid-fire bursts, batches them into a single turn, and lets the agent read the room, and that fifty people can interact simultaneously. The coalescing idea is sound for chat: without it, five quick messages from one person become five separate agent turns and five sets of tokens. But the README gives no batch window, no maximum batch size, and no statement about what happens when a burst exceeds whatever limit exists. Nor does it define what reading the room means operationally. The concurrency claim is likewise unsupported by any described mechanism beyond the process split itself, which is a plausible basis but not a measurement. This is the pattern across the README: the architectural vocabulary is precise and the operational parameters are absent.

Where Spacebot is the wrong tool

Two cases stand out. The first is licensing. The badge in the README points to FSL-1.1-ALv2, the Functional Source License, while the repository metadata reports the licence as NOASSERTION. Those may be consistent (the metadata may simply not recognize the identifier) or they may indicate the LICENSE file differs from the badge. Either way, FSL is not an OSI-approved permissive licence, and the ALv2 suffix indicates a conversion to Apache 2.0 after a stated period. If your organization requires a permissive licence at the time of adoption, this needs checking against the actual file before you write any code against it. The second case is workload shape. If you are building a single-user assistant that answers one question at a time, the five-process split, the Cortex supervisor and the SQLite memory graph are overhead with no corresponding benefit, and a simpler single-loop framework will be easier to debug. Spacebot's design pays off specifically when concurrent users would otherwise queue behind each other.

The alternative, and the actual difference in approach

The obvious comparison is an in-process agent framework where one loop handles chat, tools and memory, with state written to files the model edits itself. The difference is not feature count, it is who holds state. In the file-based approach, the LLM is the memory manager: it writes notes, reads them back, and decides what to keep. That is simple to inspect, since you can open the file, and it degrades in a specific way, because the model's own summarization is the only thing standing between a long session and lost detail. Spacebot inverts this. The README's position is that the LLM reasons and the system holds state, with memory in a typed SQLite graph and history in append-only chronicle checkpoints. The trade is legibility for durability. You cannot cat a graph, and you cannot hand-edit a checkpoint. In exchange, compaction is triggered by a programmatic monitor watching context size rather than by the model noticing it is running out of room, and the Cortex can prune and merge memories on a schedule instead of hoping the model tidies up. Whether that trade is worth it depends on whether your sessions outlive a single context window, which is exactly the case the README is built around.

Maintenance cost and release cadence

The release history in the material shows v0.4.0 and v0.4.1 in April 2026, roughly a month apart, and v0.5.0 in May 2026, with the last push to main in August 2026. That is a project moving at a pace where minor versions land monthly, which means you should expect the config surface to change between upgrades. Since the README names only compaction.mode explicitly and defers the rest to docs.spacebot.sh, an upgrade that renames or adds keys is something you would discover from the docs rather than from a stable config reference in the repository. Budget for reading release notes before each version bump rather than pinning and forgetting. On the licence side, the FSL-1.1-ALv2 badge and the NOASSERTION metadata are a discrepancy you should resolve by reading the LICENSE file in the repository directly; this is a factual check, not legal advice, and if the terms matter to your organization, that is a question for your own counsel.

Editorial conclusion

Adopt Spacebot if you are running an agent in a Discord server, Slack workspace or Telegram group where several people talk at once and you want conversation state to survive restarts. Do not adopt it if you need a permissive OSI licence today, or if your workload is a single-user CLI assistant where the five-process split buys you nothing. Before deploying, verify two things yourself: the exact FSL-1.1-ALv2 terms in the repository's LICENSE file (the GitHub API reports the licence as NOASSERTION, so the badge text and the file may not agree), and whether chronicle mode's append-only checkpoints are what your session length actually needs, since the README presents rolling and chronicle as a config choice with different trade-offs and gives no guidance on picking between them.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. spacedriveapp/spacebot on GitHub