Beevibe is a shared workspace where a team's people and AI agents work side by side. Agents hold lasting roles, build bounded domain memory, ask the right teammate when their context runs out, and escalate blockers back to humans.
It's the missing layer between your AI tools and your team. Slack, Notion, and Linear are how humans coordinate. Beevibe is the same surface for the AI side of the team — so the same context isn't re-explained dozens of times a week and the same answer isn't learned and forgotten across different engineers.
Beevibe is self-hosted. You own the Postgres database, the Node services, the local daemon processes, and the CLI binaries doing the work.
Every engineer now works with AI all day: Claude Code, Cursor, Codex, and whatever comes next. Individually, they're faster than ever. Then the team gets in a room together and coordination is still stuck at 2019 speed.
The problem isn't that the agents are too weak. The problem is that each person's AI work lives in a private bubble, and no shared intelligence compounds.
- Shared AI workspace. People and agents work in the same team graph with tasks, ownership, review, handoffs, and escalation.
- Persistent specialists. Each agent has an identity, domain, hierarchy level, and bounded memory that deepens across sessions.
- Agent-to-agent coordination. When an agent leaves its domain, it can ask another specialist for context or negotiate toward a solution.
- Human-in-the-loop control. Humans review, redirect, revise, cancel, and resolve blockers from the dashboard.
- BYO CLI. Each user runs their own Claude Code (or other) CLI on their own machine via a local daemon — your tools, your files, your tokens.
Humans Agents
────── ──────
┌──────────────────────────┐ ┌──────────────────────────┐
│ Web dashboard │ │ Claude Code CLI │
│ (Next.js) │ │ (one per agent run) │
└────────────┬─────────────┘ └────────────┬─────────────┘
│ REST + SSE │ MCP tools
│ │ (HTTPS)
▼ ▼
┌─────────────────────────────────────────────────┐
│ @beevibe/api │
│ control plane: REST · SSE · MCP · /runtime · WSS │
└─────────┬─────────────────────────┬─────────────┘
│ │
│ SQL │ WS push +
│ │ HTTP claim
▼ ▼
┌──────────────────────┐ ┌─────────────────────┐
│ Postgres + pgvector │ │ beevibe-daemon │
│ shared state, mesh, │ │ (your laptop) │
│ memory, sessions │ │ │
└──────────┬───────────┘ │ spawns the local │
│ poll for │ Claude CLI for │
│ fallback claim │ every session │
▼ │ pinned to this │
┌──────────────────────┐ │ machine │
│ @beevibe/scheduler │ └─────────────────────┘
│ server-side spawn │
│ (offline daemons) │
│ + orphan reaping │
└──────────────────────┘
The api is the control plane. Postgres is the shared coordination and memory layer. Local daemons run the actual CLI sessions where each user's tools and files live. The scheduler is a server-side fallback for mesh asks targeting agents whose daemon is offline, plus the orphan reaper for crashed sessions.
For a deeper version of any layer, see the package READMEs:
- packages/api — MCP tools, REST, SSE, MeshServer, daemon control plane
- packages/core — domain types, ports, services, adapters
- packages/daemon — local CLI claimer + spawner
- packages/scheduler — server-side fallback claimant
- packages/web — Next.js dashboard
| Concept | Meaning |
|---|---|
| Workspace | The company-level place where people, agents, tasks, memory, and review live together. |
| Agent | A persistent domain expert with a role, hierarchy level, memory, API key, and preferred runtime. |
| Task | A unit of team work assigned to a person or agent. Tasks can spawn child tasks and move through review. |
| Mesh | The agent-to-agent layer for asking the right teammate, negotiating, responding, and escalating. |
| Memory | Durable per-agent core memory blocks plus vector-searchable facts that compound across team work. |
| Runtime | A registered (daemon, CLI) pair, such as a user's local claude, codex, or opencode binary. |
| Daemon | A local process that claims sessions and spawns CLI runs on a user's machine. |
Two paths — pick whichever matches what you're trying to do.
Spins up Postgres + api + scheduler + web on Railway. Each user still
installs beevibe-daemon on their own machine to actually run agent CLI
sessions; the hosted api doesn't spawn local CLIs.
After the template finishes provisioning, set ANTHROPIC_API_KEY +
OPENAI_API_KEY on the api and scheduler services, then point
BEEVIBE_CORS_ORIGINS (api) and NEXT_PUBLIC_BV_API_URL (web build arg)
at the public URLs Railway assigned. Full notes in
DEPLOYMENT.md.
Brings up the whole stack — Postgres + api + scheduler + web — in containers from the repo root. No Node, no pnpm, no migrations to run by hand.
git clone https://github.com/beevibe-ai/beevibe.git && cd beevibe
ANTHROPIC_API_KEY=sk-ant-… \
OPENAI_API_KEY=sk-… \
docker compose -f docker-compose.quickstart.yml up -d --buildThen open http://localhost:3030.
The compose file builds the three Node images from infra/railway/, runs
migrations as a one-shot, and starts the stack. To shut it down:
docker compose -f docker-compose.quickstart.yml down -vTo actually dispatch agent work after the stack is up, install the daemon on the machine where Claude Code lives and point it at the api:
brew install beevibe-ai/tap/beevibe-daemon
beevibe-daemon setup --api http://localhost:3000 --user-token <bv_u_…>
beevibe-daemon startThe bv_u_ token is created by pnpm provision-user (see
CONTRIBUTING.md).
Issues and PRs are welcome. For larger changes, open an issue first so the direction is clear before implementation. See CONTRIBUTING.md for local development setup, the DCO sign-off requirement, and the contribution license terms.
The Beevibe source code is licensed under the Apache License 2.0.
The Beevibe name and logo are project trademarks. Apache 2.0 grants rights to the source code; it does not grant rights to use the project's name or marks. Forks and derivative works are welcome under names that are not "Beevibe."