Your context dies
between tabs.
The backlog lives in one tool, the conversation in another, what the team knows in a third, and the code somewhere else. Nobody holds the whole picture and the new hire holds none of it. Beespace puts the work, the conversation, the knowledge and the code in one place — self-hosted, where your repository already is.
Everything a team needs to
build, in one place.
Not a chat tool with a wiki bolted on, and not a wiki with a chat bolted on. One workspace where the thing you are building, the discussion about it and what the team already knows sit next to each other — and none of it leaves your infrastructure.
Boards per team, features with their own thread, subtasks, documents and diagrams. The discussion lives next to the work, not in a channel where it scrolls away.
A knowledge base of articles, repo files kept in sync, and outside sources. Search runs on a local model with no API call — and every business rule a traced flow uncovers is published into it automatically.
Architecture and flows: what the system is made of, and the route one operation takes through it. The map is the home screen, not a folder listing.
Explorer with a real editor, language server, git status and diffs. A terminal, a SQL console, builds and your GitHub pull requests. Without leaving the tab.
Draw it once as a graph and run it whenever. Agent steps, shell steps, and approval gates that stop the run until a person decides. On a schedule, or on demand.
Because the work and the context are already here, an agent can be handed a subtask — and it runs in its own worktree, under approval. A surface of the workspace, not the reason it exists.
The six controls you'll be
asked about in review.
Stated with their real status, including the two that aren't finished. Everything below is checked against the source — and if a control matters to your decision, it is cheaper for both of us that you read it here than that you find it in a trial.
Nothing is open by default: a query no grant mentions is denied. 71 named actions, and the check is enforced by the type system — a command without an authenticated context does not compile.
Each agent job runs in its own git worktree, on its own branch. The trunk never receives an unreviewed change. Plugins run as WebAssembly components with only the capabilities an administrator granted.
Indexing and semantic search run on a local ONNX model. Paired with a local model, the platform operates with no outbound connection at all.
The agent proposes, a person approves, each task produces a readable diff. The per-tool-call gate runs on the claude backend; opencode currently runs without it.
Every endpoint authorizes inside a command, and that path records actor, action and payload. Administrative actions are covered, and retention is configurable.
Per-plugin configuration is encrypted at rest. API tokens and project secrets are not: they are stored in plaintext, and the listing endpoint returns the full value rather than a masked one. This is the next item on the hardening list, and it is stated here rather than left to be discovered.
# at rest plugin_config AES-256-GCM api_tokens plaintext ← next project_secrets plaintext ← next
A plugin gets a capability set, not a process. What it can reach is the intersection of what it asks for and what you grant. No policy file means everything is denied.
# manifest ∩ policy db true ∩ true → true secret […] ∩ [] → denied
It is free for one person.
It is paid from the second.
There is no crippled free tier here. A developer alone gets the whole product, forever. What costs money is the part that costs us: shared identity, a shared knowledge base, roles, and the record. No figures yet — there is nothing solid enough to hold one up, and a price we couldn't defend would be worse than none.
What we haven't
built yet.
This is the section your security team opens first, so it is here rather than buried. The items marked partial work with a real limitation, stated in the same sentence as the claim. The ones marked roadmap do not exist.
Version 0.1.0. This is early software and the hardening list is real work in front of us, not a formality. If one of these is a dealbreaker for you, tell us before you commit — we would rather lose the deal than be caught overselling.
Bring it to your security team
before you bring it to your developers.
If it clears review, adoption is easy — your engineers already want it. That order saves everyone a pilot that dies in procurement.