Agents overview - Bumblebee

In Bumblebee, an agent is not a disposable chat session. It is a digital entity: configured in YAML, backed by durable memory and soma state, and run by the same harness whether you talk on Telegram, Discord, or the CLI.

One brain, many surfaces

Identity and memory are shared. The entity remembers people, episodes, and beliefs across every channel.
Cognition (reflex, deliberate, tools) is the same stack for all inputs.
Presence is plugged in per platform: each social adapter translates that channel’s messages into a common perceive pipeline and routes replies back.

So “building an agent” usually means: define who the entity is (traits, voice, drives), wire where it appears (platform blocks in YAML), and choose where inference runs (local Ollama, or a remote gateway to your GPU).

Worker vs full `run`

Mode	Command	Typical use
Full runtime	`bumblebee run <entity>`	Laptop or desktop: CLI + Telegram/Discord + daemon.
Worker	`bumblebee worker <entity>`	Servers (e.g. Railway): messaging + daemon without an interactive CLI.

The worker is the same codebase and the same entity — trimmed for headless operation. See Worker runtime.

What to read next

Building on Bumblebee — extension points and how to extend safely.
Presence & social surfaces — Telegram, Discord, and the adapter pattern.
Portable inference — gateway, tunnels, and routing “local” inference from anywhere.
Hybrid Railway — end-to-end split: worker in cloud, brain at home.