AI agent orchestration use cases

You press Fix on an issue in the dashboard, or type an instruction that names it, such as "fix #1884". Naming the issue links the mission to it, however the mission was launched.

On a project an organization maps, routing reads the roles and the capabilities the work needs and picks one owner, usually an engineering role. If no role qualifies, the mission holds and asks you to choose rather than falling back to a generic worker.

The worker edits code in its own worktree on its own branch. Orgabot then runs the project's verify command itself and judges it on the exit code. A reviewer that is not the producer reads the diff, and each finding becomes a fix round that is verified and reviewed again.

The pull request opens as a draft. Its description links the mission, restates the problem from the issue, and says what changed; verification and review output lands in the comments. The footer writes Closes only when the issue's own acceptance criteria were met, and Refs otherwise, with a comment naming what was and was not delivered.

An objective that reads as a release, such as "tag premail v1.0.0 and push the tag", resolves to the release workflow. The mission holds and names the release steps instead of opening a version-bump pull request and calling it done.

You run orgabot release plan to see the next hop on the environment chain and which operations need approval. The approval routes to the role that must sign off, and its class comes from the target environment's registered spec; an unregistered environment is treated as the strictest.

orgabot release promote needs a resolved approval minted for those exact operations, the expected 40-character commit SHA, and the release title. An approval for one promotion cannot authorize another, and without one nothing is performed.

After the operations run, Orgabot reads the world back: the tag must exist at the expected SHA and the release must exist. The decision records which approval it stood on, and a refused promotion is recorded as a gap in the compliance timeline.

One instruction fanned out with orgabot mission-all "..." --only web,api,docs, or an organization mission that routing turns into a multi-role plan whose sub-missions run supervised and roll up.

Each piece is owned by the role whose capabilities match it, and it delivers with that role's scoped GitHub App token. Authority is held per role, not granted once across every repository the organization touches.

Workflows resolve organization, then project, then mission, so each repository runs its own verify command and review policy. A gate the organization marked required cannot be dropped by any one project.

One draft pull request per repository, each with its own verification and review record. When the missions share a correlation id, every description links the same correlation trace in the dashboard.