What is Orgabot
Orgabot is a local-first control plane for an organization of AI and human workers. One instruction becomes a governed, verified, delivered mission.
Orgabot is a local-first control plane for directing an organization of AI coding workers across multiple projects. You type (eventually, speak) an instruction. Orgabot turns it into a structured mission, routes it to a role in your org chart, runs it in an isolated real git worktree, independently verifies and reviews the result, and delivers it as a pull request under explicit authority with a full audit trail.
Local-only remains the zero-configuration default: your control plane, state, workers, and repositories can all stay on your machine. Orgabot also supports isolated hosted tenant deployments and hybrid topologies when you deliberately select them. The resolved topology shows where every capability runs, whose account holds its data, and every custody boundary you must acknowledge; nothing moves to a hosted provider implicitly.
The one-paragraph model
Your organization should be something you staff, not software you configure. You create the roles a real company has (CTO, engineer, QA, CISO, Head of Marketing) and hire a human or an AI agent into each one. You sit at the top. Each role is equipped like a real hire: capability packs give it the knowledge and procedures of its job, and connectors give it governed access to the services you already use. Work is delegated to roles, not to a chatbot.
The mission control loop
Every piece of work follows the same path, whichever surface starts it:
instruction → transcript (immutable) → parse intent → resolve project
→ mission (state clamped to the project's autonomy)
→ plan → task DAG → for each ready task:
implement (worker edits files in an isolated worktree; Orgabot commits)
verify (the project's own test command; gate on the exit code)
review (an independent agent that did NOT write the code)
→ open a draft PR (approval gate)
→ mission outcome + append-only audit logTwo properties of that loop matter more than any feature built on top of it:
- Evidence over confidence. A verification gate passes only with command exit-code evidence. A worker saying it is done is not evidence.
- The reviewer is never the producer. The agent that reviews a change is never the agent that wrote it.
Read Core concepts for the vocabulary, and Invariants for the full list of properties that must never be weakened.
What you actually interact with
| Surface | What it is | When to use it |
|---|---|---|
| Dashboard | The localhost ops UI at http://127.0.0.1:4317 | Day to day. The intended primary surface. |
| Mission terminal | The interactive session inside the dashboard | Launching, watching, redirecting, and interrupting a mission |
| `orgabot` CLI | The full command surface in framework/ | Scripting, recovery, anything the dashboard does not expose yet |
| Claude Code skills | /orgabot-mission, /orgabot-register, /triage | Driving Orgabot from an assistant session |
Voice app (app/) | A macOS menu-bar push-to-talk capture | Optional. Voice follows the text foundation. |
What Orgabot is not
- Not a mandatory shared SaaS. Local-only needs no Orgabot account or hosted tenant. Optional isolated hosted control planes and the published shared GitHub App are supported; cloud sandbox execution and the other providers still marked
plannedare not implied by that foundation. - Not an autonomous agent with your credentials. A role reaches GitHub through its own scoped GitHub App token. A role with no grant cannot fall back to your personal
ghlogin; its mission holds instead. See Governance and approvals. - Not a code generator you trust on faith. Work ships only after an independent verify and an independent review, and PRs open as drafts by intent.
Where to go next
- Never installed it: Install and setup.
- Installed, want a PR: Your first mission.
- Confused by a term: Core concepts.
- Wondering what is built and what is next: Roadmap and current state.