Beevibe Team Workspace
Give a team’s agents shared tasks, specialist memory, and coordination workflows.
- Source repo
- beevibe-ai/beevibe
- Stars
- ★ 346
- Last updated
- today
- License
- Apache-2.0
- Primary language
- TypeScript
- FA score
- 54/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changesClaude CodeCodex (Partial support)
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A software team connecting individual AI coding work can track tasks, owners, reviews, and handoffs in one workspace shared by people and agents.
- Not a fit if
- Teams seeking a vendor-hosted SaaS with no self-managed services
- Teams unwilling to configure model API keys or run a local CLI
- Source review
- 54/100 · Major gaps
What does this agent do, and when should you use it?
Beevibe is a self-hosted workspace where people and AI agents share tasks, ownership, review, handoffs, and escalation. Each agent has an identity, domain, hierarchy level, and bounded memory, and can ask another specialist when its context runs out. The Next.js dashboard communicates with @beevibe/api over REST and SSE, while agents connect to the API through MCP tools. Postgres with pgvector stores shared state, the mesh, and memory; a local beevibe-daemon starts Claude Code CLI sessions on a user’s machine. The @beevibe/scheduler provides server-side fallback handling for mesh asks when a target daemon is offline and reaps orphaned sessions.
Teams use the web dashboard to manage workspaces, people, agents, and tasks. Tasks can be assigned to a person or agent, spawn child tasks, and move through review; agents work within their domains and retain memory, and can use the Mesh to ask another specialist for context or negotiate when they are outside their domain. @beevibe/api exposes REST, SSE, MCP, /runtime, and WSS interfaces. The local beevibe-daemon claims sessions and starts CLI runs on the user’s machine. Postgres with pgvector stores shared data and vector-searchable facts; the scheduler handles mesh asks for offline target daemons and reaps orphaned sessions after crashes.
- A software team connecting individual AI coding work can track tasks, owners, reviews, and handoffs in one workspace shared by people and agents.
- A team using Claude Code can run beevibe-daemon on each user’s machine so the CLI uses that machine’s tools, files, and tokens.
- A team with specialists in multiple domains can let an agent ask another specialist through the Mesh when its own context is insufficient.
- An engineering team seeking knowledge that accumulates across sessions can use agents’ core memory blocks and vector-searchable facts.
- A team that needs human oversight can review, redirect, revise, or cancel work and resolve blockers from the dashboard.
How do you install or deploy this agent?
The README documents Railway deployment and a local Docker Compose stack. Railway provisions Postgres, api, scheduler, and web; users still install the daemon on the machine that runs CLI sessions. Configure ANTHROPIC_API_KEY and OPENAI_API_KEY on api and scheduler, and set the API CORS origins and the web build-time API URL.
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 --buildAfter startup, open http://localhost:3030. To dispatch CLI work, install and start the daemon on the machine where Claude Code runs:
brew install beevibe-ai/tap/beevibe-daemon
beevibe-daemon setup --api http://localhost:3000 --user-token <bv_u_…>
beevibe-daemon startHow do you use this agent?
Once the stack is deployed and the local daemon is running, use the web dashboard to create a workspace, people, agents, and tasks; assign work and review it there. The daemon uses the configured API URL and user token to claim sessions and start a CLI on the local machine. The README says the bv_u_ user token is created with pnpm provision-user.
beevibe-daemon setup --api http://localhost:3000 --user-token <bv_u_…>
beevibe-daemon startWhat are this agent's strengths and limitations?
- People and agents share a workspace with task ownership, review, handoffs, and escalation.
- Agents have persistent identities and bounded domain memory that can compound across sessions.
- A local daemon runs the CLI on the user’s machine, using that user’s tools, files, and tokens.
- Mesh coordination includes scheduler fallback for requests targeting offline daemons.
- You must self-host services including Postgres, api, scheduler, and web.
- The Quick Start requires Anthropic and OpenAI API keys; the README does not state model API costs.
- Actual CLI execution requires installing and running a daemon on a user machine and configuring a user token.
- The README’s CLI setup example focuses on Claude Code; it mentions codex and opencode runtimes but gives no corresponding setup steps.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Beevibe Team Workspace This agent | 54 · Major gaps | Self-hosted serviceFree + model costs | ★ 346 | today | TypeScript | Claude Code |
| OpenHuman | 51 · Major gaps | Desktop appFreemium | ★ 42k | today | Rust | — |
| Bitterbot Desktop | 39 · Major gaps | CLIFree + model costs | ★ 2.5k | today | TypeScript | OpenAI API · Claude API |
| Rho | Insufficient evidence | CLIFree + model costs | ★ 373 | 12d ago | TypeScript | — |
How does FollowAgents rate this agent?
Why each dimension lost points
The README says the local daemon uses each user's own CLI, tools, files, and tokens, and that humans can review, redirect, revise, cancel, and resolve blockers. Its architecture also describes the API, Postgres, and daemon data and control paths. Permission granularity, secret protection, dependency vulnerability handling, and safeguards around external actions are not documented. Cancellation is mentioned, but rollback or recovery procedures are not. The README, package metadata, and DCO workflow provide limited attribution evidence, but maintainer identity and update responsibility remain unclear, so these scores are not higher.
The README's division of work among the API, database, daemon, and scheduler is consistent. The CI file specifies build, typecheck, lint, and test workflows and lists Postgres and API-key dependencies. No execution results are provided; the CLI smoke test is explicitly excluded from CI. Documentation and dependency scores are therefore moderate, while failure messages and recovery behavior lack supporting evidence.
The materials target engineering teams that need shared tasks, memory, and agent coordination, and describe bounded memory, cross-domain requests, human escalation, and local and hosted deployment paths. The intended audience and component boundaries are reasonably clear, but triggers for agent coordination and the operating conditions and limits of those capabilities are not specified in detail.
The README has a clear architecture diagram, a core-concepts table, and links to package documentation. It includes Quick Start instructions, a deployment guide link, concrete commands, and some stated limitations. The complete LICENSE file and Apache-2.0 labels agree. There is no changelog or clear release policy; package.json shows only 0.0.1. Contribution and DCO instructions exist, but maintainer responsibility and support commitments are unclear, which limits those scores.
Shared workspace, persistent specialists, task coordination, and human review give the product an understandable team use case, and the README provides startup and dispatch examples. Static evidence does not establish output quality or incremental benefit over existing tools. Deployment requires Postgres, Node services, a local daemon and CLI, plus Anthropic and OpenAI API keys; setup and ongoing costs are not adequately discussed.
The README links key architecture and concepts to package documentation, while the CI file specifies automated quality and test steps. It states that live integration tests require secrets and that the CLI smoke test is run manually. The major components and deployment model broadly agree across the supplied files. Product capabilities are primarily asserted in the README, with no implementation or output evidence supplied here to independently corroborate them, so those descriptions should not be treated as demonstrated performance.
- This is a static review of the supplied files; no code was run, and CI, tests, and product behavior were not independently verified.
- Deployment requires a self-hosted database and services, a local daemon/CLI, and Anthropic and OpenAI API keys; consult deployment documentation and implementation for deployment and credential-protection details.
- The README's human-review and cancellation capabilities are not supported by implementation evidence here; do not infer that every external action requires confirmation or can be rolled back.