01 · The runtime
The harness owns the loop. RivetOS owns everything around it.
RivetOS doesn't compete with your coding tools. It adapts them through per-harness drivers and takes on the parts no single tool does well on its own.
Harness
Coding loop: tools, model turns, approvals inside the TUI, interrupt, its native session store.
- claude-code
- codex
- grok-build
- kimi-code
- hermes
Also in the source tree, not yet in the installer: opencode, pi, qwen-code.
RivetOS · this node
Session identity, capture and memory, mesh, tasks, and the gateway HTTP + WS contract that Hub, desktop and Android all speak.
session id<harness-id>:<native-session-id>
One canonical id everywhere — capture, hub, tasks, gateway. No dual key schemes.
Runs where you put it: the local one-liner on Linux and macOS, Docker on a laptop, or LXC on Proxmox. Architecture →
02 · Memory
Local-first memory. The record is yours.
The memory plane lives on the hub you run: PGlite on one machine, or Postgres on a datahub you enroll nodes into. Exposed over MCP, so any connected agent can search it before it answers.
capture
Every turn lands in the record.
Prompts, tool calls and results are written as the session runs, keyed by the canonical session id. Nothing to remember to save.
compact
Long history folds into summaries.
The compaction worker rolls messages up into leaf and branch summaries, so a month of work stays searchable without re-reading every transcript.
recall
Any agent asks; hybrid search answers.
Full-text, trigram and vector search fused together, with hits that expand back to their source messages. Ask what you decided three weeks ago.
capture claude-code:7f3a2c…
+ user why does the mesh CA rotate?
+ tool_call shell rg -n "rotate" packages/
+ result 4 matches
+ assistant Rotation runs through update --mesh…
→ ros_messages 4 rows · embedding queuedcompaction-worker 2026-06-12
leaf 42 msgs → one root CA, per-node certs
leaf 31 msgs → rotation via update --mesh
branch 6 leaves → mesh trust model, week of 06-09
→ summaries link back to their source messagesrivet> memory_search "mesh CA decision?"
● 3 hits · hybrid fts+vector · 48ms
1. 06-12 one root CA, per-node certs
2. 06-13 rotation via update --mesh
3. 06-27 roster fix deployed fleet-wideIllustrative output. Memory design →
03 · Mesh
A mesh you enroll. Not one you join.
One machine is enough. When you want more, put a datahub on a server and enroll agent nodes into it. Every node shares one memory and can hand tasks to its peers. There is no Rivet-operated mesh.
- A datahub at the center
- Postgres with pgvector, the memory schema, and the certificate authority. No agents run on it.
- Nodes enroll over SSH
node.sh --hubruns the enrollment on the datahub. The node gets its certificate, the CA chain andmesh.jsonin one pass. The root CA key never leaves the datahub.- Peers delegate over mTLS
- A node finds its peers in
mesh.jsonand hands them tasks on port 3000. Every connection is mutual TLS; there is no plaintext fallback.
04 · Plugins
A small stable core. Everything else is a plugin.
Dependencies point inward: the core knows nothing about Anthropic or Postgres. Providers, tools, memory and transports adapt the outside world — cloud APIs or fully local models, your keys, your GPUs.
plugins/
├─ providers/ 14
anthropicxaigoogleollamavllmllama-serverclaude-clicodex-cligrok-clihermes-clikimi-codeopencode-clipi-cliqwen-code
├─ tools/ 6
shellfilesearchweb-searchmcp-clientinteraction
├─ memory/ 1
postgres
├─ transports/ 1
mcp-server
├─ channels/ 1
agent