Core Concepts

Understanding the BeeSystem model: how agents, tools, memory, and runtime fit together.

Agents

An agent in BeeSystem is a defined unit of capability. It has a name, a set of capabilities it can exercise, the tools it can call, the memory it has access to, and the runtime parameters that govern how it executes.

An agent is not an opaque black box. Every agent in BeeSystem is defined by an open agent specification — a structured, version-controllable configuration that you can read, audit, and extend.

Agents are component actors. Each agent owns one responsibility and communicates through typed channels. No shared mutable state between agents.

The Agent Lifecycle

Every BeeSystem agent follows the same lifecycle:

init — Allocate resources, configure tools, subscribe to memory
run — Core execution: receive task → reason → act → emit result
pause — Hold state, stop accepting new work
stop — Flush state, release resources, unsubscribe
reload — Hot-swap configuration without a full restart

Tools

Tools are the external capabilities available to an agent. A tool has a defined input schema, output schema, and error behavior. Tools are first-class in BeeSystem — they are not prompt injections or informal descriptions, but typed contracts.

BeeSystem includes a built-in tool library and the Bee SDK allows you to build custom tool connectors for any external API, database, or service.

BeeSystem enforces no mocks. All tool calls must call real APIs. If a dependency is unavailable, return a structured error — never simulate the result.

Memory and Context

Agents in BeeSystem can be configured with different memory types:

Session memory — Context maintained within a single agent run. Cleared on completion.
Persistent memory — State retained across runs. Stored in the configured memory backend.
Retrieval-augmented — Agents that query an external knowledge store for relevant context at runtime.

Memory configuration is part of the agent specification. It is auditable and not hidden.

Runtime: Bee Worker

Bee Worker is the runtime container that executes agents. Each agent run is isolated — there is no shared state between concurrent agent executions. Bee Worker handles tool invocations, memory access, structured error propagation, and observability hooks.

Bee Worker produces the same behavior locally as it does in production. There is no environment drift between development and deployment.

Orchestration: Bee Hive

Bee Hive is the distributed coordination server. It manages Bee Worker instances, routes tasks to agents, coordinates multi-agent workflows, and scales execution across infrastructure.

Bee Hive is the orchestration layer. It does not execute agent logic itself — execution always happens inside Bee Worker. The inside of an agent is execution; the graph is orchestration. These two concerns never mix.

The Open Agent Specification

Every BeeSystem agent is defined by an open agent specification. The spec is a structured YAML (or JSON) document that defines everything about an agent: its capabilities, tools, memory configuration, runtime parameters, and behavioral constraints.

The spec is designed to be:

Version-controllable in git
Human-readable and auditable
Composable with other specs
Deployable to any BeeSystem-compatible runtime

Vertical Agents

BeeSystem is domain-agnostic. The same infrastructure runs market intelligence agents, trading automation agents, movie builder agents, research agents, and enterprise workflow agents. Each vertical is a configuration of capabilities, tools, and memory on top of the same runtime foundation.

Adding a new vertical means writing an agent spec and the necessary tool connectors — not modifying the infrastructure itself.