Bumblebee is built so you own the entity’s definition and can grow capabilities without forking core cognition. This page maps the main hooks; the companion guides go deeper on social surfaces and portable inference.Documentation Index
Fetch the complete documentation index at: https://docs.bumbleagi.com/llms.txt
Use this file to discover all available pages before exploring further.
Configuration-first entities
- Entity YAML: personality, voice, cognition overrides, presence platforms, automations, knowledge paths.
- Harness YAML (
configs/default.yaml+ overlays): models, timeouts, tool defaults, deployment mode, soma knobs, execution policy.
Tools and MCP
- Built-in tools (web, filesystem, shell, code, knowledge, …) register from harness + entity config. Both reflex and deliberate profiles use the same tool registry.
- MCP extends reach: external processes expose tools to the entity without editing Bumblebee’s Python tree.
Presence / social adapters
Telegram, Discord, and CLI implement the same platform contract: connect, receive messages, call intoEntity.perceive, send replies and typing/tool activity. Adding a new surface means implementing that interface and registering it — the cognition stack stays unchanged.
See Presence & social surfaces.
Inference portability
The entity talks to inference through a provider abstraction:- Local: default Ollama on your machine.
- Remote gateway: same OpenAI-compatible
/v1/chat/completionsand/v1/embeddingsshape, tunneled to your home GPU.
Deployment modes
- All-local:
bumblebee run, SQLite (or your choice of DB URL), tools on the host. - Hybrid: worker in cloud + gateway at home (or another private host you control).
- Execution RPC: optional redirect of shell/code tools to a machine you designate (common when the worker should not touch the Railway filesystem for risky operations).