| summary | Agent runtime (embedded pi-mono), workspace contract, and session bootstrap | |
|---|---|---|
| read_when |
|
|
| title | Agent Runtime |
Bitterbot runs a single embedded agent runtime derived from pi-mono.
Bitterbot uses a single agent workspace directory (agents.defaults.workspace) as the agent’s only working directory (cwd) for tools and context.
Recommended: use bitterbot setup to create ~/.bitterbot/bitterbot.json if missing and initialize the workspace files.
Full workspace layout + backup guide: Agent workspace
If agents.defaults.sandbox is enabled, non-main sessions can override this with
per-session workspaces under agents.defaults.sandbox.workspaceRoot (see
Gateway configuration).
Inside agents.defaults.workspace, Bitterbot expects these user-editable files:
GENOME.md— immutable identity blueprint (safety axioms, hormonal homeostasis, phenotype constraints, core values)MEMORY.md— living working memory (Phenotype, Bond, Niche, active context), rewritten by the Dream EnginePROTOCOLS.md— operating instructions + behavioral protocolsTOOLS.md— user-maintained tool notes (camera names, SSH hosts, voice preferences)HEARTBEAT.md— optional tiny checklist for heartbeat runs
On the first turn of a new session, Bitterbot injects the contents of these files directly into the agent context.
Blank files are skipped. Large files are trimmed and truncated with a marker so prompts stay lean (read the file for full content).
If a file is missing, Bitterbot injects a single “missing file” marker line (and bitterbot setup will create a safe default template).
To disable bootstrap file creation entirely (for pre-seeded workspaces), set:
{ agent: { skipBootstrap: true } }Core tools (read/exec/edit/write and related system tools) are always available,
subject to tool policy. apply_patch is optional and gated by
tools.exec.applyPatch. TOOLS.md does not control which tools exist; it’s
guidance for how you want them used.
Bitterbot loads skills from three locations (workspace wins on name conflict):
- Bundled (shipped with the install)
- Managed/local:
~/.bitterbot/skills - Workspace:
<workspace>/skills
Skills can be gated by config/env (see skills in Gateway configuration).
Bitterbot's channel routing and base agent runner build on the pi-mono framework. Session management, multi-agent orchestration, tool wiring, the biological memory system, economic layer, P2P network, and identity architecture are all Bitterbot-original.
Session transcripts are stored as JSONL at:
~/.bitterbot/agents/<agentId>/sessions/<SessionId>.jsonl
The session ID is stable and chosen by Bitterbot.
When queue mode is steer, inbound messages are injected into the current run.
The queue is checked after each tool call; if a queued message is present,
remaining tool calls from the current assistant message are skipped (error tool
results with "Skipped due to queued user message."), then the queued user
message is injected before the next assistant response.
When queue mode is followup or collect, inbound messages are held until the
current turn ends, then a new agent turn starts with the queued payloads. See
Queue for mode + debounce/cap behavior.
Block streaming sends completed assistant blocks as soon as they finish; it is
off by default (agents.defaults.blockStreamingDefault: "off").
Tune the boundary via agents.defaults.blockStreamingBreak (text_end vs message_end; defaults to text_end).
Control soft block chunking with agents.defaults.blockStreamingChunk (defaults to
800–1200 chars; prefers paragraph breaks, then newlines; sentences last).
Coalesce streamed chunks with agents.defaults.blockStreamingCoalesce to reduce
single-line spam (idle-based merging before send). Non-Telegram channels require
explicit *.blockStreaming: true to enable block replies.
Verbose tool summaries are emitted at tool start (no debounce); Control UI
streams tool output via agent events when available.
More details: Streaming + chunking.
Model refs in config (for example agents.defaults.model and agents.defaults.models) are parsed by splitting on the first /.
- Use
provider/modelwhen configuring models. - If the model ID itself contains
/(OpenRouter-style), include the provider prefix (example:openrouter/moonshotai/kimi-k2). - If you omit the provider, Bitterbot treats the input as an alias or a model for the default provider (only works when there is no
/in the model ID).
At minimum, set:
agents.defaults.workspacechannels.whatsapp.allowFrom(strongly recommended)