Skip to content

Orgabot is in private alpha. Request access, or join our Discord.

← All documentation
Start here

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 log

Two 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

SurfaceWhat it isWhen to use it
DashboardThe localhost ops UI at http://127.0.0.1:4317Day to day. The intended primary surface.
Mission terminalThe interactive session inside the dashboardLaunching, watching, redirecting, and interrupting a mission
`orgabot` CLIThe full command surface in framework/Scripting, recovery, anything the dashboard does not expose yet
Claude Code skills/orgabot-mission, /orgabot-register, /triageDriving Orgabot from an assistant session
Voice app (app/)A macOS menu-bar push-to-talk captureOptional. 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 planned are 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 gh login; 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