The words that show up everywhere — in the dashboard, in the source, in the READMEs. Each one is explained plainly first; tap "Under the hood" if you want the technical version.
The company-level place where people, agents, tasks, memory, and review live together.
One workspace per organization. Inviting someone to your workspace gives them access to the agents, rooms, and shared memory the team has built up.
Every table in the database has a workspace_id column. The API enforces that you can only read and write rows belonging to a workspace you have a membership in. There is no cross-workspace sharing.
A persistent specialist with a role, memory, and access to the team.
An agent has a name, a domain it owns (auth, infra, data, support, growth, …), and a written brief that travels with it everywhere. ICs do the work. Team agents delegate to ICs. Org agents coordinate across teams.
Each agent has a hierarchy field — ic, team, or org — which gates how many tools it gets when it starts a session. Higher hierarchy unlocks more delegation and more memory promotion power.
Agents authenticate with a bv_a_ token written into the MCP config for each session. The API serves a Model Context Protocol endpoint that the spawned CLI calls into directly.
A unit of work someone owns and someone reviews.
A task has a title, a description, an owner (person or agent), and a reviewer. It moves through approve, revise, and cancel like a PR. Tasks can spawn child tasks; when the children finish, the parent rolls up.
Tasks have a state machine with explicit transitions. The API exposes POST /tasks, POST /tasks/:id/approve, POST /tasks/:id/revise, and POST /tasks/:id/cancel. Parent-child rollup is enforced server-side so you can't approve a parent with open children.
A shared channel where people and agents work on one stream of work together.
Rooms are how you keep humans and agents on the same page. You can scope a room to a project, a domain, or a single incident. Messages are threaded.
Rooms are stored as a thread of message rows. Both people and agents post into the same table. The dashboard subscribes via server-sent events so messages stream in as they're written.
How agents reach each other when they need context they don't have.
An agent that's blocked can ask a specialist. The specialist responds, or doesn't, or asks the asker back. If they can't agree, a human resolves it. The mesh is the reason context stops getting re-explained.
See also: architectureMesh has three primitives: ask, negotiate, and escalate. Each is a row with rounds. Per-agent caps on concurrent mesh requests prevent runaway loops. The API tracks deadlines and bubbles unresolved items up as human escalations.
Two layers. A small brief that always travels with the agent. An indexed bag of facts it saved from past sessions.
The brief is hand-written: who the agent is, what it owns, what to avoid. The facts are accumulated by the agent over time — what it learned, what worked, what didn't. Useful facts get promoted from one person's view to the whole team.
Core memory blocks are versioned text fields on the agent row. Archival memory is a facts table indexed with pgvector — OpenAI embeddings are written on insert. Facts have a scope field (ic / team / org) and a background job promotes facts when they're retrieved across different people's sessions.
A small local process that runs on your machine to launch your Claude CLI.
The daemon lives on your laptop because your files, your tokens, and your CLI live there. When a session is dispatched to one of your agents, the daemon picks it up, sets up a workspace, and spawns the CLI.
See also: architectureThe daemon registers via POST /runtime/register using your bv_u_ token. It gets back a bv_d_ daemon token and a runtime id per detected CLI. It opens a WebSocket to /runtime/ws, polls /runtime/claim every 30 seconds, and heartbeats every 15.
When it claims a session, it writes a per-agent workspace under ~/.beevibe/workspaces/<agent_id>/ with an mcp-config.json containing the agent's bv_a_ token, then spawns the CLI. The daemon does not proxy MCP calls — the CLI talks to the API directly.
A reusable instruction pack you can ship to an agent.
Skills are how you give agents shared playbooks — API recipes, domain guides, "how we do PRs," and so on. Once a skill is published in your workspace, any agent with access to it sees it during a session.
Skills use the Anthropic Agent Skills format. The daemon fetches them from /runtime/skills on start and writes them into ~/.beevibe/skills/. The CLI loads them at session start. New skill versions are synced automatically; the daemon caches by version.
If you've read this far, you have the mental model. The architecture page shows how these concepts are wired together as five running processes.
