# Spacebot: a Rust agent harness for multi-user Discord, Slack and Telegram

> Spacebot splits an AI agent into five process types so one deployment can serve concurrent conversations across channels. It is written in Rust, ships as a single binary, and stores memory in SQLite rather than in markdown files the model edits.

**spacedriveapp/spacebot** — An AI agent for teams, communities, and multi-user environments.

- Repository: https://github.com/spacedriveapp/spacebot
- Website: https://spacebot.sh
- Stars: 2,400 · Forks: 365
- Language: Rust
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/spacedriveapp-spacebot

## The single-loop agent problem Spacebot is built around

The README states the design target plainly: most agent frameworks run conversation, thinking, tool execution, memory retrieval and context compaction in one LLM thread. When that thread is working, it cannot answer. When it compacts, it goes dark. Retrieved memories land in the same context window as everything else.

Spacebot's answer is process separation. The README describes five process types, each with one job, and says a channel never executes tasks or searches memories directly. That is a real architectural commitment rather than a prompt convention, and it is the reason the project targets multi-user environments instead of a single chat session.

The intended users are named in the README: a Discord community with hundreds of members, a Slack workspace with parallel workstreams, a Telegram group spread across time zones. Solo users are addressed too, on the argument that the same infrastructure gives better memory and concurrency for one person. Whether that trade is worth the operational weight of a daemon plus a database is a judgement each reader has to make.

## Channels, branches, workers, the Compactor and the Cortex

The README gives a data flow rather than an API reference. A message arrives at a channel, which holds soul, identity and personality. The channel branches to think: the branch inherits the full conversation history and runs concurrently, and the channel sees only the conclusion. A branch may spawn a worker for heavy tasks. Workers begin as full forks of the channel that delegated to them, carrying the conversation context behind the task instead of a one-line description, so the worker acts on intent. Fire-and-forget workers handle one-shot tasks; interactive workers keep a session open and route follow-ups to the active worker.

Two processes sit outside the conversation. The Compactor is described as programmatic, not an LLM, and watches context size per channel, triggering compaction before the channel fills. Its mode comes from the compaction.mode key: rolling keeps one summary at the head of history and rewrites it under pressure, while chronicle cuts append-only checkpoints over contiguous transcript ranges, each summarizing only the span since the last checkpoint. The live prompt carries a bounded window of recent checkpoints, and older ones roll up.

The Cortex is the supervisor. It watches across 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 it stays out of the token budget because nothing runs when there is no work.

Memory itself is a typed graph in SQLite, with the README insisting that state belongs in structured storage rather than markdown files the LLM manages. The Cargo.toml backs that up: sqlx with the sqlite feature, plus lancedb, lance-index, redb and fastembed for vector and embedding work. That is a heavier dependency surface than a markdown-and-embeddings setup, and it is the price of the typed graph.

## Installing Spacebot and getting a first agent running

The README does not print a self-hosting command sequence. Its only installation instruction is a pointer: one-click deploy at spacebot.sh, where you connect Discord, Slack, Telegram or Twitch, configure the agent, and go, with no self-hosting required. If that is your path, stop reading here and use the hosted flow, because the repository files describe a developer build rather than a guided install.

For source builds, the justfile is the entry point. The dev recipe runs the daemon from source and passes extra arguments through, so a foreground run looks like this:

```bash
just dev --foreground
```

That invokes cargo run -- start with your arguments appended. You should see the daemon start in the foreground rather than detaching.

Before a pull request the repository expects a preflight pass. The justfile exposes both a local and a CI variant:

```bash
just preflight
just preflight-ci
```

Both call scripts/preflight.sh. The CI variant passes --ci. There is also a gate-pr recipe that runs preflight first and then scripts/gate-pr.sh, which is the closest thing to a definition of a healthy checkout.

If you prefer containers, the Dockerfile is a multi-stage build. It compiles the React frontend and embeds it in the Rust binary, installing protobuf-compiler, libprotobuf-dev, cmake, libssl-dev and pkg-config in the builder stage, then bun and Node 22 or newer. The Node requirement is explicit in a comment: Node 22+ is required for the OpenCode embed Vite build. The build also runs scripts/build-opencode-embed.sh before the frontend build so the embed assets land in interface/public/opencode-embed/.

The repository ships fly.toml and fly.staging.toml, and a docker-entrypoint.sh, so a Fly.io deployment is the deployment shape the files anticipate. A Nix flake is present too, with flake.nix and flake.lock, alongside an .envrc for direnv users. The README does not document rollback, migration downgrades, or what happens to the SQLite graph across version upgrades.

## Where Spacebot is the wrong tool

The licence is the first constraint. The README badge points to FSL-1.1-ALv2, the Functional Source License with an Apache 2.0 future licence, while the repository metadata reports NOASSERTION because GitHub's classifier does not recognise the identifier. FSL is source-available, not OSI-approved open source at the time of use. The README links to fsl.software. Anyone whose policy forbids non-OSI licences should read LICENSE before writing a line of integration code. The project's own framing, opinionated agent infrastructure, is honest about this being a product with a company behind it, not a community-governed library.

Second, the architecture assumes you want a daemon. If your use case is one user talking to one model in one terminal, the five-process split, the SQLite graph, the LanceDB and fastembed dependencies and the Cortex's maintenance loop are overhead you will pay for and not use. The README argues solo users still benefit; that is a claim about memory quality, not a claim that the footprint is small.

Third, the README is a design document more than an operations manual. It does not document rollback, it does not document a migration path for the memory graph, and it does not list provider configuration for the LLM backends. Cargo.toml shows rig-core and reqwest, and the Dockerfile shows an OpenAPI spec binary and a typegen recipe, so an HTTP surface exists, but the README does not enumerate it. Expect to read docs/ and interface/ rather than the front page.

Finally, the last push to the default branch was on 2026-08-18, and the most recent release listed is v0.5.0 from 2026-05-07. That is a gap of roughly three months between the last tagged release and the last commit, which is normal for a project of this size but worth knowing if you depend on tagged artifacts rather than main.

## How Spacebot differs from a single-session agent framework

The obvious comparison is a conventional agent framework where one loop owns the conversation, the tools and the memory. In that model, concurrency is achieved by running more copies of the loop, and each copy has its own context. Spacebot's README rejects that: it argues that no other agent harness handles concurrent multi-user conversations, shared memory across channels, and process-level concurrency together.

The difference in approach is where state lives. A single-session framework typically keeps memory as files the model writes and reads, which means the model is both the writer and the reader of its own state, and correctness depends on the prompt. Spacebot moves state into a typed graph in SQLite and a checkpoint chain in chronicle mode, so the system holds state and the LLM only reasons. That makes memory inspectable and compactable by code, at the cost of a schema you have to migrate and a database you have to back up.

The second difference is the compaction strategy. A rolling summary is the common default, and the README describes its failure mode directly: rewritten under pressure until details blur. Chronicle mode trades a single summary for append-only checkpoints over contiguous ranges, which is better suited to sessions that run for weeks. If your sessions are short, rolling is simpler and the checkpoint machinery buys you little.

The third difference is multi-agent isolation. The README states you can run multiple agents on one instance, each with its own identity, memory and security permissions, from one binary and one deploy. A framework that assumes one agent per process would need separate deployments and separate state stores to match that.

## Maintenance, releases and what the licence means for upgrades

Release cadence visible in the repository is modest. v0.4.0 and v0.4.1 landed in April 2026, and v0.5.0 in May 2026. The default branch saw a push on 2026-08-18, so work continued after the last tag, but anyone pinning to releases should expect to wait between them.

Upgrade cost is dominated by two things the README does not cover. The first is the SQLite memory graph: migrations/ exists at the top level, and sqlx is built with the migrate feature, so schema changes are handled in code, but the README does not describe a downgrade path or a backup procedure. The second is compaction.mode. Switching a long-running installation from rolling to chronicle changes the shape of stored history, and the README does not state whether the two modes can coexist over the same transcript.

On licensing, the badge and the README link point to FSL-1.1-ALv2, which grants source availability with a conversion to Apache 2.0 after a stated period. The repository metadata says NOASSERTION, so automated licence scanners may flag the project or miss it entirely. That mismatch is worth resolving with your own legal review before you ship a product that embeds the binary, because the terms you are accepting are the ones in LICENSE, not the ones in a badge image. This is a description of what the files say, not legal advice.

## Conclusion

Spacebot fits teams and communities that need one agent serving many concurrent conversations with shared memory, and Rust developers who want to read the source. It does not fit anyone who needs a permissive OSI licence today, since the badge and repository metadata point to FSL-1.1-ALv2, or anyone unwilling to run a daemon with its own SQLite graph and compaction policy. Before adopting it, check the LICENSE file against the FSL terms, confirm compaction.mode suits sessions of your length, and run the preflight script to see what the project itself considers a healthy checkout.

## FAQ

### What is Spacebot and who is it for?

Spacebot is an AI agent harness for teams, communities and multi-user environments, written in Rust. The README targets Discord servers, Slack workspaces and Telegram groups, and says solo users get the same infrastructure.

### How do I install Spacebot?

The README points to one-click deploy at spacebot.sh with no self-hosting required. For source builds, the justfile's dev recipe runs the daemon via cargo run -- start, and the Dockerfile builds a single image with the frontend embedded.

### What licence does Spacebot use?

The README badge links to FSL-1.1-ALv2, the Functional Source License, while the repository metadata reports NOASSERTION. The LICENSE file is the authoritative text.

### How does Spacebot handle memory differently from markdown-based agents?

The README states that state belongs in structured storage rather than markdown files the LLM manages, and that memory lives in a typed graph in SQLite. Conversation history compacts into chronicles, which in chronicle mode are append-only checkpoints over contiguous transcript ranges.

### Can Spacebot run more than one agent on a single instance?

Yes. The README describes running multiple agents on one instance, such as a community bot on Discord and a dev assistant on Slack, each with its own identity, memory and security permissions, from one binary and one deploy.

## Sources

- [Issues](https://github.com/spacedriveapp/spacebot/issues)
- [Project website](https://spacebot.sh)
- [README](https://github.com/spacedriveapp/spacebot/blob/main/README.md)
- [Releases](https://github.com/spacedriveapp/spacebot/releases)
- [spacedriveapp/spacebot on GitHub](https://github.com/spacedriveapp/spacebot)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spacedriveapp-spacebot